4.1.1. Entry and Exit Criteria
The entry criteria refer to the desired conditions in order to start test execution; only the migration of the code and fixes need to be assessed at the end of each cycle.
The exit criteria are the desirable conditions that need to be met to proceed with the implementation.
Entry and exit criteria are flexible benchmarks. If they are not met, the QA team will assess the risk, identify mitigation actions and provide a recommendation. All this is input to the project manager for a final “go-no go” decision.
Entry Criteria |
---|
|
|
|
Exit Criteria | QA Team | Notes |
---|---|---|
100% Test Cases executed |
| |
|
| |
No open Critical and High severity defects |
| |
|
| |
All remaining defects are either cancelled or documented as Change Requests for a future release |
| |
All expected and actual results are captured and documented with the test cases |
| |
All test metrics collected based on reports from Test Cases |
| |
All defects logged in Jira |
| |
Test Closure Memo completed and signed off |
|
4.1.2. Test Cycles
There will be two cycles for functional testing. Each cycle will execute all the scripts.
The objective of the first cycle is to identify any blocking, critical defects, and most of the high defects. It is expected to use some workaround in order to proceed with the tests.
The objective of the second cycle is to identify remaining high and medium defects, remove the workaround from the first cycle, and correct gaps in the scripts.
4.1.3. Validation and Defect Management
It is expected that the testers execute all the scripts in each of the cycles. However, it is recognized that the testers could also do additional testing if they identify a possible gap in the scripts. This is especially relevant in the second cycle when the Product Team joins the QA team in the execution of the test since the Product Team has a deeper knowledge of the business processes. If a gap is identified, the scripts and traceability matrix will be updated and then a defect logged against the scripts.
The defects will be tracked through JIRA only. The Squad teams will gather information on a daily basis from JIRA, and request additional details regarding the defects. The Squad teams will work on fixes.
It is the responsibility of the tester to open the defects, link them to the corresponding test case, assign an initial severity and status, retest, and close the defect.
It is the responsibility of the Tech Lead to review the severity of the defects and facilitate with the Squad team the fix and its implementation, communicate with testers when the test can continue or should be halted, request the tester to retest, and modify the status as the defect progresses through the cycle.
It is the responsibility of the Squad teams to review the defects in JIRA on a daily basis, ask for details if necessary, fix the defect, communicate to Tech lead that the fix is done, and implement the solution.
It is the responsibility of the Project Manager to communicate with the Product Owner and Business Owner about all the NON-critical defects especially HIGH severity defects whether those bugs need to be fixed immediately or can wait for the next sprint.
Defects found during the Testing will be categorized according to the bug-reporting tool “JIRA” and the categories are:
Severity | Impact | Example |
---|---|---|
P1 - Critical |
|
|
P2 - High |
|
|
P3 - Medium |
|
|
P4 - Minor |
|
|
4.1.4. Defect Life Cycle
QA will create a bug ticket, select a component, and assign it to the Product Owner with their respective teams listed below:
Miroslav Pavelek (Accounts)
Maria D'Amato (Transactions)
Kristof Szep (Loans & Risk)
Viktor Humaj (Back Office)
Ilija Sovilj (Common)
Branislav Haukwitz (Customer & Onboarding)
Revazi Dzidziguri (Accounts & Subscription & Finance)
PO will decide whether the bug is valid, change request, or needs to be fixed immediately.
For change requests, PO will communicate with the Business Owners to validate and agree before the implementation.
For P1 ticket, it needs to be fixed immediately.
For P2 to P4 tickets, PO will decide whether the bug needs to be fixed immediately or not that important for EPFS license so it can wait for the next sprint.
PO will then assign the tickets to the development team that will fix the bugs.
Once fixed, the Dev team will assign the tickets to QA. Otherwise, re-assign to Dev team for rework.
QA will close the ticket.
4.1.5. Bug Report Template
Bug Title | UI | Mobile | Android | Onboarding - Cannot proceed to next step after document scanning |
Environment | Staging |
Platform / OS | Android |
Steps to Replicate |
|
Actual Result | After successful document scan it goes back to Proof of Identity screen |
Expected Result | Proceed to next Onboarding step Personal Information screen |
Screenshot |
|
Attachments:
Sprint Process - Deployment-20220930-035234.png (image/png)
image-20220927-070746.png (image/png)
image-20220927-070552.png (image/png)
image-20220916-025456.png (image/png)