QA Tasks

Throughout the project timeline, it is important to enter upcoming QA tasks into the project backlog in Jira, to be estimated and pulled into sprints during planning meetings. This practice is absolutely vital for deadline tracking and early risk identification. The purpose of this document is to provide some guidance on what types of tasks should be added to the timeline, and provide some details about dependencies, and when the tasks should be getting executed.

Tasks that do not need to be entered into the Jira backlog:

Project Setup

When beginning a new project, before the first sprint planning meeting, enter the following tasks into the backlog. If you can estimate them at the start of the project, please do so, but if there are too many open questions you can fill in the Story Point fields any time prior to the tasks getting added to a sprint.

Each task will be explained in greater detail below.

Project ramp-up

Overview:
Prior to beginning any work on a project, it is important to review who the client is, what the goal of the app is, who the target demographic is, and any additional background information that will provide much needed context during test plan creation and testing.

Execution Phase:
Ramp-up tasks should take place during the Requirement Synthesis and Test Plan Creation phase.

Dependencies:
Access to Business Development documentation, and the general project folder.

Estimation Tips:
The amount of time needed for ramp-up can vary greatly, depending on the size and complexity of the project. Don't estimate this task too high, keeping in mind that you can continue ramping up and learning the context of the project during test plan creation tasks, as well.

Deliverable:
None.

Create the QA Dashboard

Overview:
Towards the beginning of the project, the QA lead should take some time to create the QA Dashboard and associated search filters.

Execution Phase:
The QA Dashboard should be created during the Requirement Synthesis and Test Plan Creation.

Dependencies:
None.

Estimation Tips:
This task should not exceed 1 story point.

Deliverable:
Provide a link to the QA Dashboard in the ticket before setting it to Done.

Create test plan structure

Overview:
The first step in writing the test plan is inventorying the components/features of the app that need to be tested, and determining what tickets need to be created, ignoring test cases within those tickets at this point. Carefully consider what the scope of each test ticket should be. It's important to make test tickets broad enough to allow smaller pieces to link together within a ticket, but at the same time keeping them specific enough for it to be meaningful to fail a ticket if an individual test step fails. For smaller projects, it may make sense to create individual tickets for single pages or screens of the app. For larger projects, it will make more sense to break components/features apart more, keeping in mind that features will possibly evolve over time and new features will be introduced that will require new tickets. When creating test tickets for individual features/components, creating a ticket for general navigation elements and common tests for each screen may also be necessary to bridge elements that are spread across multiple tickets together. Be sure to use the organization of the project epics and developer user stories created by the product owner for guidance.

Execution Phase:
Test ticket creation is executed during the Requirement Synthesis and Test Plan Creation phase.

Dependencies:
Epics and developer user stories need to be created to execute this task, and any stories about creating them should be linked to the task ticket as a blocker. While exact interaction notes do not need to be completed, it is important to have a flow diagram and/or feature list of the app to understand all of the pieces that will go into it. Any UX/Interaction stories related to planning the contents of the app may also be linked as blockers, if there is not enough information to begin this step.

Estimation Tips:
Estimate very low for simple/small projects so more time can be spent developing test steps for the tickets, but don't be afraid to estimate a significant portion of a sprint to this task for large/complex projects. An organized foundation for the test plan to rest on will save time in the long run for projects with changing and growing requirements.

Deliverable:
Provide a link to the [project name] - Test Tickets search filter (created while making the QA Dashboard) in the ticket before setting it to Done.

Write test cases

Overview:
This is a seed story for use during initial project planning, that will eventually be replaced by several tasks to Write test cases for (test ticket name).

Execution Phase:
This task is created at the beginning of the project, and will eventually be replaced by other more specific tasks before being executed.

Dependencies:
None.

Estimation Tips:
This task should be estimated at 30% of the non-scrum QA budget, minus whatever time is estimated for Project ramp-up and Create test-plan structure.

Deliverable:
None.

Write test cases for [test ticket name]

Overview:
A task should be created for filling in the test steps for each test ticket. The primary source of this information should come from the interaction notes and wireframes provided by UX/Interaction, and can be supplemented by acceptance criteria in user stories. While writing the test steps, be sure to document any ambiguities and questions that you have. Getting answers to these questions and clearing up any confusion is why this phase of the project receives 30% of the QA budget, and will benefit the developers as much as it will benefit the testing efforts.

Execution Phase:
Test steps should be added to test tickets as the final primary task of the Requirement Synthesis and Test Plan Creation phase.

Dependencies:
Interaction notes or other technical documentation are required to write test steps. Link any related UX/Interaction tasks to these tickets as blockers and bring them up in standup meetings when appropriate.

Estimation Tips:
Base estimations on the complexity of the feature/screen, and the level of detail in the documentation. Allow for extra time if you anticipate having to dig to find answers to questions.

Deliverable:
Provide a link to the ticket that test steps were added to in the ticket before setting it to Done.

Update [test ticket name] to reflect changes

Overview:
As development progresses, it is almost inevitable that problems will come up that require solutions that change the planned app functionality slightly. It is important to treat these changes with the same scrutiny as the original documented requirements, call out an issues or ambiguity, and capture exactly how to test the updated version of the feature.

Execution Phase:
Changes can happen at any point in the project, but should typically only happen during the Requirement Synthesis and Test Plan Creation, and QC Testing phases.

Dependencies:
If at all possible, documentation should be updated to reflect the change in functionality. If necessary, link any UX/definition stories to the task as blockers.

Estimation Tips:
Base estimations on the complexity of the change, and the level of detail in the documentation. Allow for extra time if you anticipate having to dig to find answers to questions.

Deliverable:
Provide a link to the updated ticket(s) that test steps were modified in before setting the ticket to Done.

Test features in development

Overview:
This is a seed story for use during initial project planning, that will eventually be replaced by several tasks to Test (feature).

Execution Phase:
This task is created at the beginning of the project, and will eventually be replaced by other more specific tasks before being executed.

Dependencies:
None.

Estimation Tips:
This task should be estimated at 35% of the non-scrum QA budget.

Deliverable:
None.

Test [feature]

Overview:
During the QC Testing phase, the QA engineer's primary tasks will be to trail developers, testing features that they complete during mid-project sprints. These tasks should typically be mapped to individual or small collections of developer user stories. The tasks don't need to remain open until all bugs are fixed or every small part of the feature has been tested. If only 80% of the feature is developed, the task can be about testing that 80%. If the feature needs to be retested again later, a new task can be created for that in the appropriate sprint.

Execution Phase:
Feature testing should be completed during the QC Testing phase.

Dependencies:
Link the appropriate developer stories to the tickets as blockers, to add visibility to when features are being completed.

Estimation Tips:
Base estimations on the complexity of the feature, and the relative length of the associated test cases.

Deliverable:
Either include ticket numbers for tickets that were found during testing, or a link to the test case(s) within the test cycle if a "preliminary testing" cycle was created for the project.

NowSecure sweep on [platform]

Overview: At some point during a mobile app project, it should be run through NowSecure to test it for security issues.

Execution Phase:
NowSecure sweeps are typically run during the QC Testing phase or during the Deployment phase. While it's better to discover security issues earlier than later, in-progress features often cause false positives to appear on the report, making it useful to wait until a feature-complete non-debug version of the app is available.

Dependencies:
Work with the developer to determine the best time to run the NowSecure sweep. Upon making a decision, the developer needs to provide a suitable build before the sweep can be executed.

Estimation Tips:
NowSecure sweep estimations should be relatively low.

Deliverable:
Attach the report in PDF form to the ticket before setting the ticket to Done.

End-to-end sweep in [environment]

Overview:
Prior to a public-facing release, it is important to fully test the app from end to end in the primary environment to check for regression issues, and to make sure all near-complete features interact with each other properly.

Execution Phase:
The end-to-end sweep is the primary task that takes place during the Deployment phase.

Dependencies:
The closer to feature-complete the app is during the end-to-end sweep, the better. Towards the end of the QC Testing phase, review the list of unfinished developer stories, and link any that will compromise the integrity of the end-to-end sweep as blockers. It might be appropriate to work with the developer and product owner to determine this list.

Estimation Tips:
Having tested most (if not all) features during the QC Testing phase, it should be relatively easy to estimate the end-to-end sweep.

Deliverable:
Upon the completion of the sweep, include a link to the test cycle.

Smoke sweep in [environment]

Overview:
In addition to running an end-to-end sweep in the primary environment on each platform, smoke sweeps should also be run on all additional supported environments.

Execution Phase:
Smoke sweeps are executed during the Deployment phase.

Dependencies:
The end-to-end sweep should be completed before moving onto the smoke sweeps. While not necessary, the end-to-end task can be linked to the ticket as a blocker.

Estimation Tips:
Smoke sweep test tickets should be designed to take 1 - 2 hours.

Deliverable:
Link the execution of the smoke sweep test ticket before setting the task to Done.

Production smoke sweep

Overview:
After the app is pushed to production, a quick smoke sweep should be executed to make sure everything was correctly deployed and the production server has been configured correctly.

Execution Phase:
Production smoke sweeps are executed at the end of the Deployment phase.

Dependencies:
If there are developer stories to deploy the app to production, link them as blockers.

Estimation Tips:
Smoke sweep test tickets should be designed to take 1 - 2 hours.

Deliverable:
Link the execution of the smoke sweep test ticket before setting the task to Done.