| Table of Contents |
|---|
...
The sprint timeline is split into 70% development and 30% hardening. The development teams are prioritizing prioritize their coding activities until the second Wednesday of the sprint. Afterward, they redirect their attention toward testing and improving the features, hardening the code, and bringing all testing IN sprint.
...
POs will CLOSE stories after QA MQA complete their testing (we should never close untested stories!). For example, say the PO reviewed and approved the story in Snapshot, then they may want to look at it again in Sprint Test after QA is finished before closing it, OR they can review the results of QA testing and if no bugs have been reported the PO can go ahead and close the story. If bugs have been reported, then the PO needs to decide whether the found bugs need to be fixed before closing the story or the story can be released as is (so the PO then goes ahead and closes the story). In the latter case, the bugs found will be deferred to the next release.
Jira Workflow: Once the code review is complete, the developer moves the story to "In QA" status. QA tests these stories in Snapshot and Sprint Test environments and moves them to "In Review" status. POs accept and close these stories.
Suggested Guidelines to Accepting Stories:
...
When the Sprint environment is available, QA re-tests the story. If a bug is found that is story-specific, QA re-opens the story.
Accelerate Automation
This initiative is to improve our automated test coverage significantly. Increasing automation test coverage is crucial as it has been proven to be a reliable and efficient method for detecting bugs at an earlier stage of the testing process.
Starting: Sprint 170, automation work will be managed centrally.
To increase the AQA team’s focus on automation, the AQA engineers are organized in a separate team with all the scrum team’s ceremonies, Jira board, etc, and a dedicated scrum master. All AQA backlog will move from the Teams scrum board to the AQA board. Yogesh will lead the team. POs will provide test case priority, such as Smoke/Critical/Extended, for automation. Obviously, the AQA engineers are free to work with feature teams and individual developers/testers as they see fit. They can also participate in feature teams’ DSUs/refinements/reviews/demos as they see fit.
...
This initiative is to have developers take ownership of the existing test maintenance from the AQA team. This is a very effective and efficient approach for automated tests, as well as the industry standard. Since developers are very familiar with codebase and troubleshooting, they can quickly identify the root cause of failures by examining the code (or, better yet, adjusting the tests as they adjust the screens), allowing for faster resolution of test issues. When developers make changes to change the application code, they can maintain synchronization between code and tests, reducing the risk of outdated and ineffective tests. Developers can closely share insights and knowledge to improve the test suites with the automation testers.
...
This initiative is to improve our Pull Request Quality gate. Currently, PR Quality includes static analysis, code review, and unit tests. We will include running relevant integration and end-to-end tests along with modified code. Performing testing during PRs is essential to proactively detect and address issues before they penetrate the main codebase. The implementation of Implementing this PR quality gate is crucial to prevent regressions and ensure that developers receive timely feedback on the impact of their code changes. Furthermore, code reviewers can rely on the test results as an objective evaluation of code quality. This approach saves both time and effort while also guaranteeing early stability.
...