You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Quality Strategy Template Overview

Generally testing strategy answers the questions:

  1. what is being tested
  2. what is out of testing scope
  3. where and how the testing is performed
  4. who is responsible for testing activities

The testing strategy template above is designed to capture all of the elements above without going into too much details. Use the one page visual strategy as a snapshot for a team agreements on quality and testing. All detailed agreements should be documented in the notes section below. 

Copy this template and store it in the product confluence space.

The product quality is team responsibility, therefore each team is expected to work together to define, implement and improve the strategy.

Below you will find the comments on what is expected to be covered in each section. Please use your own judgement on what needs to be added onto one page visual strategy and which details are better to be detailed in the Leading Notes section.

Product. Add the product name which the strategy is intended for. In specific cases one strategy may serve several products, e.g. several libraries maintained by one team.

Objectives. This section should  define on what the team wants to achieve with testing. Be specific and consider including measures which helps the team to understand if the strategy agreements are working. Some examples (might be used in combination):

  • Identify and eliminate defects early in the development cycle to prevent escaped defects from occurring. 
  • Optimize quality measures to enable release on business demand reduce risk of failure in production
  • Maximize test efficiency to reduce the time of testing

In Scope. Should contain a clear definition of what is covered by testing activities, e.g. core product and integrations, product UI.

Out of Scope. Should clearly defined what is not covered by the strategy, e.g. detailed functional testing of integrated libraries.

Risks. This section is intended to describe short term and long term risks for the strategy defined, e.g. lack of competency in using testing tools, ambiguous requirements, legacy monolyth system...

Requirements. Add sources of requirements, e.g. links to confluence pages, Jira project, any standards the product needs to comply, operability requirements (e.g. supported devices, browsers, operating systems)

Testing Approach:

  • functional section is structured to cover the layered testing approach. Each layer should include:
    • What is being tested, e.g. integration testing covers all internal and external API endpoints.
    • How we test it automated or manual, what tools are we using.
    • When is it tested, e.g. unit tests are being run on each merge request while exploratory testing may be planned once per sprint
    • Where the testing is done, e.g. local environment, lab environment
    • Who is responsible for test development maintenance and execution
  • non functional testing section should include at least three test types: security, performance and accessibility. It might also include other product specific requirements, e.g. FedRAMP products might have specific requirements for operability. Each type should include information on:
    • What is being tested, e.g. integration testing covers all internal and external API endpoints.
    • How we test it automated or manual, what tools are we using.
    • When is it tested, e.g. unit tests are being run on each merge request while exploratory testing may be planned once per sprint
    • Where the testing is done, e.g. local environment, lab environment
    • Who is responsible for test development maintenance and execution

Testing Process. This section is intended to grasp key team agreements like:

  • In sprint testing process
  • Release process including location of release testing summaries, and release checklist
  • test location e.g. link to xray test repository, link to GitLab project (especially when tests are separated from the product), test run instructions if applicable.
  • use this section to list any additional quality measures the team has, e.g. code review practices, handoff to testing agreements, DoD, defect/bug handling approach, etc.

Monitoring section should include links to app monitoring dashboards.

Please note that if you have a gap between the actual state and the strategy you define, document the action steps and interim agreements

Quality Strategy

Leading Notes


  • No labels