Test strategy
Last modified on Mon 28 Sep 2020

Walking on water and developing software from a specification are easy if both are frozen.

A test strategy is a document that serves as a basis detailing how quality processes are implemented on a certain project.

Since the domains, budgets, and architectures can vary a lot between projects, there is no single test strategy that would cover all grounds. This article briefly explains what such a document should elaborate on.

Use these guidelines if you are ever tasked to assemble a test strategy or when thinking about how to approach your next project.


Definition of ready

When should a task be moved from the backlog to the shortlist?

There is no one-size-fits-all solution here, but a good rule of thumb is:

A task missing some of the components mentioned above will be difficult or impossible to test properly. You should act upon this to get it specified.

Definition of done

When is a task done from the perspective of a software tester?

A simple way of looking at it: when all of the acceptance criteria are met.

A more complex way of looking at it: when all of the acceptance criteria are met, you have defined all of the test cases, and when there are no outstanding functional or non-functional issues pertaining to that task.

Sometimes there will be no acceptance criteria and the definition of done will be your gut feeling.

All of the above will vary from project to project and tester to tester.

Entry and exit criteria


Functional and non-functional requirements

Test cases are usually derived from acceptance criteria and expanded by using heuristics and experience.

If acceptance criteria are found in a user story or a task, they should be mapped to test cases in order to ensure traceability.

Here's a quick intro to acceptance criteria.

Acceptance criteria

Each work item that will be coded and integrated into the final product should have acceptance criteria. The implementation should satisy user-level criteria in order to be successful.

Acceptance criteria can be formally or informally written.

An example of a formal method is the "given-when-then" (GWT) format:

Some other best practices:

If your project doesn't come with any acceptance criteria, try to change that by discussing it with the team. Writing good documentation helps transparency and getting things right on the first attempt.

Severity and priority

Not all bugs are the same. You can attribute severity and priority to a bug in order to communicate to the team how important it really is and triage it appropriately.

Severity is related to how damaging it is to the product.

Priority is related to how soon should a fix mitigating it be deployed to production.

Sometimes a bug can have low severity, but high priority. E.g. imagine uploading a wrong logo on the website.

Here's one possible way of classifying them according to severity and priority:



Test cases

Test deliverables

Test environment

Test plans