Test strategy and Test plan

Determining the quality of a product or an application is one of the most important phases in STLC. This requires R & D on finalising the tools, resources, infra involved. The documentation post this initial R & D lays the foundation of quality assurance.

One such document is the test strategy document which is always confused with the test plan document.

Let’s clear out this confusion first.

Test strategy document is a one-time layout stating the testing approach for all the releases while

Test plan document needs to be prepared for every release.

Now let us look at each document individually to understand the basic attributes required.

Test strategy document

Template of the test strategy can have the below:

· document name, version, details of author, reviewer, approver,

· technology stack,

· environment,

· types of testing,

· tools used for each type of testing,

· resource responsibilities,

· risks and mitigations

Let’s get into the details of each parameter. The name of the document should call out the project name.

Format example:TestStrategy_ProjectName_version.

Provide the below information for audit purpose:

It is important to know the software and hardware specifications of the application in order to predict the best tools that can be used for manual, automation and performance tests. Define the technology used and all the tools involved clearly.

Specify the environments that will be used in each stage of testing. For example, it is a common practise to have one lower environment for testing both functional and regression and another production like environment to perform a quick test of sanity along with the priority 1 scenarios identified from the current release scope.

Finalise the types of testing that will be carried out. This will differ from application to application. For example, an application driven by APIs and events will require, manual exploratory testing, automation testing along with basic security and performance testing.

Once the types of testing are finalised it’s time to identity the tools that will be used for each of them. For the above scenario, it is suitable to use postman for manual exploratory testing, rest-assured with testNG for automation testing and Gatling for performance testing.

Pick your tools depending on the make of your application.

Now identify the number of resources that will be required for each type of testing. State their responsibilities. Some projects have different teams for manual, automation and performance testing while others have same team for manual + automation and different for performance. Decide this structure and number based on the billing involved, skillset and timelines.

At last, foresee any anticipated risks and come up with their mitigation plans. There is never a plan without risks. It is the way we handle them that describes the success.

The test strategy once reviewed and approved will remain same throughout the project tenure.

Test plan document

On the other hand, a test plan has to be designed from the scratch for every release of the project. Template of the test plan must state clearly the below:

· document name, version, details of author, reviewer, approver,

· in scope functionalities,

· out of scope functionalities,

· risks and mitigations,

· entry criteria,

· exit criteria.

How to fill up each of these sections?

Name of the document must be easy and focussed on identifying the specific release. Format example: TestPlan_ReleaseName_version.

It is a good practise to record the below information for audit purpose:

The next page must be about the user stories committed for the release. Place them in the “In scope” section. Listing the user stories with their description will suffice.

In case due to any reason a user story was moved out of the release mention it in the “Out of scope” section.

Every testing phase will have a set of defined activities. Timelines section is very important to know the start date, end date of every activity to monitor the deviation if any.

In case of deviation between the estimated start date and the actual start date a risk must be raised accordingly.

Be proactive in identify any risks anticipated for testing the release. Types of risks could be-

· a resource crunch,

· test data unavailability,

· environment instability,

· slippage of code delivery date, etc.

Any risk mentioned should also come with a mitigation which will be the backup plan for solving the risk. For example, in a resource crunch situation, either hire a new resource or borrow one from another team of the same project account or in worse case ask if the existing resources can extend their shift or log in during the weekends (which is a bad idea ).

If test data is not available in lower environment, think about refreshing the database of production with that of lower environment.

Work with the infra team to make the environment stable.

Be ready with a priority 1 and priority 2 suite of test cases if the code delivery date is slipped so that with the available time only the priority 1 test cases can be finished successfully.

Entry Criteria section must be strictly followed as an acceptance criteria to begin testing.

· Stable code without severity 1 and 2 defects,

· Demo of the functionality and code walkthrough by developer,

· presence of integration and unit tests at code level, etc. are a few to name.

Exit Criteria is very essential to understand if the code is of good quality and can be promoted to the higher levels. For example:

· successful execution of all designed test cases,

· absence of any severity 1 and 2 defects,

· severity 3 bugs if present must have a workaround,

· defects that might not hamper the existing code and can be taken in the next or subsequent releases must be deferred after review with stake holders,

· demo of a happy path to end user.

Now that we are clear with the difference between both the documents, it is left to respective teams to decide and incorporate this documentation process based on time/requirement constraints.

Originally published on Medium