What is an Agile Test Plan?

An Agile Test Plan is a very important document because it gives your Quality Assurance (QA) team the ability to have all high-level scenarios, business requirements and estimates in one place. Your QA Analyst or Agile Tester should fill out an Agile Test Plan during each sprint planning event. And just like the actual live document, it is always changing and evolving, depending on sprint requirements and overall timelines.

An Agile Test Plan should have a proper and clear structure containing business inputs and QA tasks.

Let’s see how it works.

1. Introduction

Agile Test Plans usually start with an introduction; this is a short description of the project containing general information on the sprint’s testing process. This part of the document should include two sub-parts:

1.1 Document Scope

This part specifies how the delivery of the future application will be tested. It defines the following areas:

• User stories
• QA environment
• Testing scope
• Testing process
• Risks and dependencies
• Estimates and Exit criteria

1.2. Feature Description

The Feature Description clarifies how the newly-created features or functionalities work within the application and how they can be tested. The features are explained in general terms, not in detail. For example: “A new geolocation feature is enabled when the user signs in to the web app and is automatically disabled after two hours of idling. User may disable geolocation manually in: Account → Settings → Geolocation settings → Location traffic.” That’s it.

2. User stories

This part of the Agile Test Plan includes any new feature that comes with an explanation or detailed user story. User stories are important because they show business requirements. If a new feature comes from the client without a user story, the QA and Project Managers must write the high-level scenarios together and create a new task for it in Jira.

3. QA Environment

This part usually details the list of all software or tools that are used in the testing process for the sprint, for both manual and automatic testing. This is dependent on the main project requirements and discussions and clarifications with the Product Owner or with client.

• For example: a software platform, an operating system, a device type;
• Which automation tool: Selenium WebDriver or UFT;
• Appium Framework or Express for Mobile Automation;
• jMeter or LoadRunner for Performance Testing.

4. Testing Scope

The testing scope is the list of all QA tickets and tasks that the tester must verify at any given Agile sprint. This part of the document contains an exhaustive list of Jira ticket numbers, ticket summaries, a log of QA task duration and an optional Hiptest link. Testing Scope must be written in coordination with the developers, team lead and product owner.

Here’s a sample for a task:

Ticket name: Jira ticket 876.
Summary: Geolocation should be tested on iPhone 7.
Build: app-staging-build-1.2.3.
OS: Android and iOS
Estimated time: 2.5 hours.
Hiptest link: https://app.hiptest.com/l/fo/765776.

5. Testing Process

An Agile Test Plan should state what kind of testing will be performed during an Agile sprint. Manual and automatic testing processes allow for different types of software testing, such as:

• Functional Testing: positive tests only for main software functionality; no negative tests during testing cycle.
• Security Testing: both positive and negative tests, which means checking how the application is working for Sign Up, Sign In and Forgot Password functionalities.
• UI Testing: testing the presence of particular UI elements on the web page or mobile build. UI testing usually checks for element display, size and location on a page/screen.
• Cross-Browsing Testing: testing on the most popular browsers, depending on business requirements and browser popularity in applicable country or countries.
• Regression Testing: the most important part of testing, since it checks full software functionality before release. There are two types of regression testing: pre-regression on release candidates before full release, and post-regression after release and smoke testing. Mobile Regression testing involves checking a previous build, then installing a current build and testing the release candidate.
• Smoke/Sanity Testing: simple and quick high-level testing. Does the application work after release or not? Smoke testing usually runs after release to check if it launches correctly.

6. Risks and Dependencies

Before starting an Agile testing process, the QA Analyst must decide if there are any blockers or potential risks for failed tests. If so, are the risks minor or major? For example, was there a “code freeze” day during the sprint? Has the previous build been successfully released? Has it been approved by the client? The QA Analyst should discuss all of this before developers start coding and building an app.

7. Estimates and Exit criteria

Estimates are general business schedules for completing sprints and heading to release. How many hours should QA spend on different testing types? When will the green light be given for web and/or mobile release? These questions should help focus on high-level results.

Finally, when completing all parts of the Agile Test Plan document, make sure that all high-level business scenarios have been created in Jira and Hiptest with a description, detailed steps, entry and exiting criteria, sprint name, original estimates and proper summary.

A detailed and structured Agile Test Plan helps QA ensure a complete QA process, have confidence in their work and avoid omissions. A very good habit is to always refer back to this document in which everything is indicated.