...
BFQ4-18 ACTION ITEMS STATUS :
Action Item | Status | Add to Playbook |
---|---|---|
Consider to use TestRail for subsequent Bug Fest runs | Will be used in BF Q2 2019 | |
Not all the areas of FOLIO were covered. Do next BF soon to cover them. | DONE Coverage over 99% in BF Q1 2019 | |
Better scope definition is needed to avoid testing incomplete features. | DONE | |
Always use real customer data. | DONE | |
Original reference data must be migrated to the BF environment. | DONE | |
Must have a planning meeting for every BF run: Define scope; Assign tasks to make sure that participants have time to complete them. | DONE | |
Test cases for each module need to be reviewed with respective POs | DONE | |
Discussion is needed about how long BF environment is staying up after test run is over. | TBD | |
Discuss what should be bug workflow for the future BF runs. | TBD |
ACTION ITEMS
Action items were aggregated from the retrospective board:
Make sure that performance issues are reported separately
Use TestRail instead of the Google Spreadsheet
Transfer test cases into TestRail
Provide TestRail training
PO to improve test case descriptions
Post module/PO mapping before BF start for testers to post direct questions to the right person.
Call separate meeting on the bug triage and handling workflow.
PO should NOT test a module that they are working on
Start BF on Tuesday
Q&A:
Q: When planning future areas/features to test, are we planning to continue to test old features or to shift focus?
A: Yes, all existing features need to be retested (both old and new). Bug Fest is a regression test by its nature.
Q: When a feature has unresolved bugs from last BugFest, do we test it anyway (to see if there are new bugs) or leave it untested (because we know it will fail)?
A: PO should list known unresolved bugs prior to BF. A feature should be retested anyway. If bug is still there tester should add current bug fest label. If new bug has been found they should be logged as well.