| 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 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 MQA is finished before closing it, OR they can review the results of MQA 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:
- The development team has demonstrated the story to POs. This should be done as soon as the feature is demo'able (no need to wait until it's fully tested). This can be done in Snapshot (or even Rancher). Basically, no changes to the exiting process. EXCEPT - the POs should not accept this story at this point.
- The POs perform business-level testing in Snapshot to ensure the story meets their criteria. QA will likely start their test cycle once the PO approves it, but they can also start sooner if they choose to
- Once QA has completed testing of the story, the PO can re-review the feature in Sprint Testing env OR review the QA test results to assess whether the story meets the expected level of quality.
- If there are no bugs, PO closes 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.
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.
...