Is Your Test Strategy Just a Document?

July 06, 2021

From My Past Experience

Working as Software Tester in this IT Industry introduced me to Test Strategy very early in my career. In those early days, we used to work in Waterfall ways. By nature of collaboration practice, we used to document each thing that could be a risk if forgotten. During projects kick-off, we used to define our test strategy for Software that we would develop. We used to document this strategy so that any member newly joining QA gang can go through it and understand what Approach we are taking for Testing the Software.

Later on, Our Industry Started an Agile Way of doing things. We started valuing * Working Software over comprehensive documentation *. It never meant no documentation. Therefore we started doing Just Enough Documentation, which helped in filling collaboration gaps.

I remember an experience from those starting days of Agile Ways of Working on how that change affected my test strategy. Once, While working on one project, I was asked to prepare Test Strategy for the Software that we were building. Since I was only QA and was leading Testing in this project, I already had some Strategy for Testing in my mind. Yet I was unable to put it on paper comprehensively, the reason being so many things in our Ways of Working were changed. I did a quick google search for some templates, but most of the templates I was getting were irrelevant to the Strategy of Testing that I had in my mind.

It took much of my efforts to convince people about a different document that I was presenting that did not abide by those traditional templates.

Test Strategy In Todays Context

I still see, in many projects, Test Strategies Prepared remains just as that document which we don't use very often or which remains ignored.

• What has changed in testing these days?
• ** Is Test Strategy Just another document?**
• ** Is it helping you to convey Strategy for Testing actually?**
• ** Or are you preparing those only to Sell Testing or soothe someone's nerves?**
• ** Does It mean any Promise or Commitment about Testing Job todos? **
• ** Does it mean we still want to do some upfront planning about Testing?**

If any question above is not going to make you uncomfortable, then you are already doing proper justice to it, and the rest of the blog can be helpful on this journey, else keep reading to get those answers.

Challenges with upfront planning

We don't know requirements upfront

Agile ways of working have made The Software Industry more flexible for change. We know that most of the time, we don't know the requirements upfront. Requirements gathering is a continuous process. Also, We keep on discovering new requirements as and how we progress.

e.g., Let's assume today we know we are not yet taking any payments from customers. But in the future, we may charge them. And if our strategy is rigid that it can't test payment gateways properly, then we may struggle later on to adapt to changed requirements

Project dynamics related to tools, policies, people change

If our test strategy is rigid and can't consider environmental or people change, During those changes, Testing will be affected.

e.g., Let's assume, We are right now using a free version of a tool. It supports a basic amount of infrastructure for Testing. What if later we experience a load on tools infrastructure, and we find it difficult to use the same tool which was reliable.

We can't have Rigid Strategy

In short, we can strategize things only up to a certain extent, Known Unknows or Unknown Unknowns will always need us to keep vising Test Strategy.

Yet We need some strategy that can respond to change

A clarity on Approach to ingrain desired Quality into our Software is always better. Also, we want to ensure that everyone who joins the team newly or is part of the team understands this. We need to devise a strategy for sure. And we may or may not need to put it in a document depends on context. It also doesn't mean that we fixate on Approach all the time (It's not a promise or commitment). However, we keep on revisiting it on instances where change is inevitable.

Closing Thoughts

In the whole blog, we understood that Test Strategy should not turn into just another document, It also need not be so much Rigid that it cannot respond to change. At the same time, we need some Strategy For Testing for sure. In the upcoming blog, Let's try to explore how we can devise a good Test Strategy? which factors to consider?

Photo by Michelle Dennis from FreeImages