The What, Who, and How of Developing a Test Strategy

By Janna Loeffler

Conference Speaker

In the world of agile, when people think of a test strategy document, they think, “That’s outdated,” “It’s unnecessary documentation,” or “Why do we need a big strategy document if we’re delivering in two weeks?” The truth is, in the move from waterfall to agile, we have forgotten the reason we create a test strategy document. In the great rush to adopt a new way of delivery, we left a few good practices behind.

Let’s start by defining the purpose behind a test strategy. In fact, let’s start even before that by defining what the word strategy means: a plan of action or policy designed to achieve a major or overall aim. So, if we put test and strategy together, we see that the main purpose of a test strategy document is to have a defined plan of action for how we are going to test a system, application, or business function.

Understanding the purpose, we can now move on to define what is valuable. I am often asked, “How big should my test strategy be, and what should it contain?” The short answer is: “Have enough information to be valuable and short enough that someone can read it.” The long answer is probably why you are reading this, though, so let’s cover the main points of a test strategy.

I like to use the analogy of buying a used car. Typically, this is a big purchase and a lot can potentially go wrong, so you do your due diligence. Look into the makes and models of cars and research their reliability. Who owned the car, and did they do the required maintenance? Where was it driven? How many miles does it have?

Considering how we apply our critical thinking skills to buying a car, let’s use those same skills with building a test strategy.

The first part of a test strategy should talk about the “what.” What is being tested, what environment am I testing in, what test data do I need, what is the timeline? Documenting the “what” is critical because it can help cut down on unknowns that tend to creep up in the middle of projects.

The second part is the “who.” Who are my stakeholders, who are my developers, who is this functionality made for? Understanding the “who” can help you focus your testing efforts and understand the business risk.

The last part is the “how.” How are we going to approach our testing, how are we going to deliver the code to production, how are the users going to use this functionality? The “how” is the core of your strategy and details your overall testing approach to the “what” and “who.”

A strategy document does not have to be a fifty-page behemoth that is difficult to track and even harder to read. Understand the purpose of a test strategy and you will realize that no matter your delivery methodology, a test strategy still has a place in today's testing world.

 

This article was originally published March 27, 2019, on TechWellInsights.com.

Janna_Loeffler

Janna Loeffler has more than fifteen years of software quality experience. She holds a bachelor's degree in computer engineering and a master's degree in business administration. Working in a variety of software engineering roles, including development, testing, quality assurance, and DevOps, has provided her with a holistic view of software engineering. She has worked on a wide variety of products, such as industrial controls, embedded medical devices, websites, mobile applications, and theme park attractions. Janna has a passion for helping people build high-quality software more efficiently.