Tracking time accurately for dev tickets and test case execution and reporting status
Step 1: Adding test cases for dev tickets: Identify incomplete test coverage per ticket, create test case stubs for missing test cases and link them in the ticket
This includes test cases for bugs. Bugs that are added to the sprint should have associated test cases as well.
Step 2: Create Test cycles for each sprint: one for the entire Sprint testing, and a separate test cycle for regression testing during the sprint
Assign the test cases to the test cycle
When should the test cycle start? Automatically at the beginning of the sprint, or once the first test case begins execution?
Pre-plan test cycles. Test cycles should be set up and scheduled for each sprint (regular and regression), where test cases can be added as the sprint grooming page is updated. This helps us identify if scenarios are missing for certain dev tickets.
Step 3: Generate Test Execution Burndown chart and post daily
Step 4: Top defect report as the sprint goes on (maybe use next sprint)
Which tickets need test cases added? List here
Communication
QA slack channel daily updates
Informal questions about processes, tasks, tickets, concerns
List tickets that have been reviewed with devs for test coverage
Weekly meetings every Monday
Showcase regression testing:
Review the test cycle and the associated test cases
Show Zephyr
Show if there were any defects
Action items
Sam Im (Deactivated) add discussion for next sprint's regression testing to meeting agenda for Friday
Move Meeting to Friday
Sprint 32 test cycle
OpenLMIS: the global initiative for powerful LMIS software