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.
Adam Satterfield and Janna Loeffler are presenting the session The Who, What, Where, When, and How of Test Strategies at the STAREAST 2019 conference, April 28–May 3 in Orlando, Florida.
Adam Satterfield, Director of Testing and Quality Assurance at Anthem, has been in the software testing industry for nearly 20 years. He has a wide background in industries such as military, SaaS, telecom and healthcare. Adam enjoys leading and mentoring quality assurance teams as well as teaching testers how to find their inner testing star. He is currently responsible for creating quality standards and training teams on Risk Based Testing, ATDD, Unit Testing and Session Based Testing within Anthem.
The "what", the "who", and the "how" are really important elements in a test strategy document, and I appreciate the focus on being concise.
I'd like to offer the suggestion that why could be pretty important too. When strategies (and projects) go off the rails, it's often because we've lost track of why we're doing something.