QA Phases

Requirement Synthesis and Test Plan Development (REQ)

Summary:
QA's main task during the REQ phase is to review user stories, UX documents, and any other documents used to map app requirements and specifications, and translate them into a set of test cases to be used throughout the process and during end-to-end testing.

Impact:
While the REQ phase seems like a straightforward prerequisite to testing/later phases, it is actually a vital testing step of its own. While consolidating documents and interpreting requirements as user-level test cases, inconsistencies and unclear specifications can often be discovered that prevent future defects from occurring, before development has begun. Finding these issues early, before code has been developed around them, can reduce the cost and risk of fixing issues later on.

Effort:
30% of the QA budget should be expected to be used during the REQ phase.

Prerequisites:
User stories and wireframes/interaction notes from UX must be completed (subject to future changes) for features/epics before QA is able to write test cases for them. Not all features/epics need to be defined for QA to begin.

Deliverable:
By the end of this phase, QA should have a completed test plan. Additional revisions may need to be made throughout the project as requirements/specifications change.

QC Testing (QC)

Summary:
The QC phase is when functional testing begins. At this point, QA Engineers trail developers and test stand-alone features as they're developed, writing defect tickets for larger issues and areas where the implementation of features doesn't match the specifications.

Impact:
Finding issues earlier is always more beneficial than finding them later. When defects are identified early, less code is built on top of them, and there's less risk of impacting other working code while correcting them. It's also important to determine, early on, if some approaches are not going to work, and revise accordingly before building an entire working app based on a bad foundation.

Effort:
30% of the QA budget should be expected to be used during the QC phase.

Prerequisites:
User stories from developers (both systems, and client-side) must be completed for individual features within epics before QA is able to assess whether or not they meet the project specifications.

Deliverable:
Defect reports start to get generated during this phase.

Deployment (DEP)

Summary:
The Deployment phase occurs during the final sprint of the project, and includes a full end-to-end QA sweep of the feature complete app, as well as a faster smoke sweep of the app running in the final production environment.

Impact:
Whenever code changes are made, there's always a risk that they will impact other areas within the app. Before releasing the final version of the app to the public, it is vital to pull back a little bit, and examine a near-finished version of the full app, simulating the exact experience that end-users will have, and review how all components of the app work together. Finally, once the app is deployed to the production environment, it is important to quickly make sure everything is present and working.

Effort:
30% of the QA budget should be expected to be used during the Deployment phase.

Prerequisites:
The app should be feature-complete, and a code freeze should be issued on a staging server prior to beginning the DEP

Deliverable:
At the end of this phase, the app should be deployed and live.

Retests (RET)

Summary:
Throughout the QC and Deployment phases, whenever developers implement fixes for logged defect reports, QA Engineers review the changes, verify that the defective behavior no longer occurs, and test around the code changes to identify potential regression issues.

Impact:
All code changes introduce risk. While fixing defective behavior is a positive change, it is still a change. It is necessary to pay attention to areas that are known to have changed. It's also important to verify that the fixes successfully resolve the issue.

Effort:
10% of the QA budget should be expected to be used during the Retest phase (which overlaps both the QC and DEP phases).

Prerequisites:
Logged defect reports in Jira should be set to "Pushed to Staging", and the changes should be pushed to the QA/Staging environment. For mobile app defect reports, a build containing the fixes should be uploaded to Hockey.

Deliverable:
While not really a deliverable, defect reports should be closed or returned to developers upon the completion of ticket retest tasks.

Timeline