test strategy

A Test Strategy is a test document that outlines a testing approach within the software development life cycle (SDLC). Test documentation can be a high-level executive summary, written on an organizational level or very detailed on a practical level, like a test case for a specific function. Providing test documentation for any level can save time and cost, promote consistency, and deliver critical information to stakeholders

Test Documentation Hierarchy

When discussing a test strategy, many people confuse it with a test policy or a test plan. So let’s clarify by explaining the test documentation hierarchy of these three.

Test Policy

A test policy is a high-level document outlining the major objectives and principles of testing for an organization or company.

Built for the organization level
High-level and brief, often only a few sentences
Describes the value the company derives from testing
Unlikely to change unless the company undergoes significant organizational changes
Test Strategy

A test strategy is a document that supports a test policy by providing general testing requirements and basic details on carrying out testing within an organization or per project.

Organization or project level
Describes the organization’s general testing methods
Describes test reporting by the use of measurements and metrics
Explains defect management
It may change based on its use. An organization-level strategy will change less frequently, but at project level, the strategy could alter for each project.
Test Plan

A test plan is a document that describes project-specific objectives and uses the high-level information from the test policy and test strategy to make a plan that can accomplish those objectives.

Project level
Explains what will or will not be tested for a specific project
Describes how testers will implement the project’s test strategy
Includes test schedule, project risks, and execution cycle
Would change every with every project, sprint, or possibly mid-sprint
How to Write a Test Strategy

When writing a test strategy, the author should consider the organization and the intended project when deciding what to include. However, the following items are usually included in the test strategy document:

Test Levels?– Explain the document’s level of testing, which could be unit, integration, system, or acceptance testing.
Scope?– List the areas to test. Also, mention anything excluded from the scope or items not being tested.
Entry and Exit Conditions?– You should have specific conditions that define the start and end of testing. This information may come from a product manager or other stakeholder.
Environment?– Describe where the testing takes place. Is it in a development, test, staging, or production environment? If there is a database involved, towards which environment is it pointed? Make sure to list any URLs.
Team responsibilities?– Describe who is responsible for performing each task. The description may include people from outside the testing team. For example, developers may be responsible for unit testing, or stakeholders may be responsible for acceptance testing. A tester may execute scripts, and a test manager may be accountable for reporting.
Testing Tools?– This section should define any tools needed for testing and test case management.
Technique?– Explain conditions and test case defining. Is test case data creation needed? If so, explain what is required and when.
Defect Management?– Explain how bugs will be reported and tracked. You should outline bug criticality definitions and describe a process for addressing bugs.
Release Control?– Define who will be responsible for the release. Will it be in iterations orCI/CD? What approvals do you need before the release? If there is a review board process, be sure to include that information because it can affect the timing of the release.
Metrics and Reporting?– Describe the method for recording metrics and who is responsible for the reporting. You may need input from a product manager on acceptable values for each metric.
Risk and Mitigation?– You may already be aware of threats before testing. If possible, describe ways to mitigate risk.
Summary?– Include a basic overview of the testing and its work products.

Compile the document after you have gathered all this information. There are many templates online, or the author can create their own. If your organization is new to incorporating test strategy documents, know that it is common to need to tweak the template often until you design one that works for your organization or project. Eventually, a version will evolve to be more static and require less fine-tuning.

Test Strategy Types

The International Software Testing Qualification Board (ISTQB) lists seven test strategy types. There may be other types, but these are the most frequently used.

Analytical

Use this strategy when a specific factor is analyzed, like a requirement or risk. For example, risk-based testing uses an analytical approach because tests are written and prioritized according to the level of risk.

Directed

Often referred to as consultative, instructions or suggestions from stakeholders form the contents of this strategy. These stakeholders may be subject matter experts, technology experts, or product experts. If a project is fortunate enough to include someone who is an expert, it makes sense to take their advice or council when considering testing activities.

Methodical

A methodical test strategy utilizes an existing set of tests or test conditions. An excellent example of methodical testing is a checklist.

Model-based

This test strategy uses a model (mathematical, business process, etc.). Tests are designed and executed and then compared to the model.

Process-compliant

This strategy applies external directives or specifications to ensure the product is industry or legally compliant. Industry standards like ISO, for example, tests are designed to confirm that the software follows these guidelines.

Reactive

Reactive is the least structured approach because the tests are chosen based on the previous test’s reaction. A great example of a reactive strategy includes the use of exploratory testing.

Regression-averse

This strategy almost always involves automation because its objective is to perform regression tests to ensure existing code did not break or was adversely affected by new changes.

Tips for Writing a Test Strategy
Using a template is an excellent idea because it provides consistency across the organization. It can also save time because the author becomes familiar with the information required.
Often, a project will require a combination of test strategies, which is OK and acceptable. Including the data is the most necessary action.
While it is essential to list the items for testing, keeping a record of those not tested is also necessary. Doing this can help prevent scope creep.
An approach may need to change. Sometimes, new information or a significant defect emerges during the software and testing life cycles. The strategy should adjust to meet the needs of the project.
Test Strategy Example Document

Check out our example test strategy document, available in three formats:

Google doc
Word file
PDF file
Conclusion

A test strategy is a document that describes an organization’s or project’s intended approach. When written well, it can support consistency across the organization. It also helps create well-defined and focused test plans by providing guidance. There are several types of test strategies based on the test approach. The author will often need to use a combination of concepts to fit the need of their organization or project.