Is There Room for Test Strategy in Agile? (#PNSQC2021 Live Blog)

Suffice it to say, today is going by quickly. We are already up to the lunchtime keynote and immediately following, it's go-time for me! However, before that, we get to hear Mirjana Kolarov talk about "Is there Room for Test Strategy in Agile? It's funny to hear how Mirjana, like so many people in software testing, came to it from an oblique angle. Are there any testers that actually chose it as a first career ;)?

So let's start with the base question... what do I think when  I hear the words "Test Strategy"? 

Honestly, I think of pre-year 2000 testing projects with the need for large documents that nobody actually reads to sign off on testing in test pans that no one actually does to meet standards that no one actually checks. 

Sounds cynical, huh? 

Well, that heavy-duty documentation by its very existence made testing more difficult than it needed to be Let's be clear, though, I'm complaining about the documentation and the heaviness of it by some arbitrary mandate. A test strategy on its own I'm actually very much in the "let's do this" camp.

 

So what is the actual benefit of having a test strategy? It's not to meet that arbitrary "fill in the template" need of middle managers. Instead, it should be looked at as:

• What will guide our testing? 
• Do we have a common understanding of our testing processes? 
• Do we know what our deliverables are? 
• What are the expectations of the given test strategy?

Like Mirjana, I would encourage limited test strategies for given projects and areas of influence. rather than have some overall encompassing test strategy for an organization or a project, how about we focus on a given project or instead have a strategy for a specific story? Mirjana points to a larger overall strategy, so if I were to gather multiple test strategies into one document, then yes, I could imagine them being the same size (or roughly the same). 

An Example Test Strategy outline 

Mirjana points out that writing a test strategy in isolation is a task doomed to failure. It needs to be informed by the needs and the goals of the group, the project, and the over-arching organization. Having a single test strategy for an organization may or may not make sense. In some cases, a large test strategy is irrelevant to incremental Agile development. That's not to say there is no need for a strategy but instead, having a modular test strategy that can be addressed for each area both as needed and as defined can come into play. Again, having twenty different test strategies for multiple areas of interest may be a little different compared to one large document in volume, time, and effort but if a test strategy for a particular area is one or two pages, it's much more likely that those pages will actually be read and reviewed. 

Additionally, there are other ways to represent a testing strategy beyond a standard document, table, or spreadsheet. Mirjana makes the case that simple mind maps may be able to communicate the same level of information that a more dense document would. 

Ultimately, the level of trust and understanding of the team will determine how these test strategies are both communicated and documented. Information Radiators can be as simple as a page in a wiki or post-it notes on a whiteboard. The key takeaway, at least to me, is not the formality of the document but the ability to communicate it effectively and quickly. The more closely knit and actively the team works, the less formal or voluminous the test strategy or any documentation needs to be. The more distributed the team, the more necessary those same strategies and guidelines be codified and visible (they still need not be overly long or arbitrarily wordy). Overall, are we trying to create an effective method for testing that we can communicate to the entire organization? If the goal is to have testing happening all the time, everywhere, in every aspect, the more people who understand and know the testing goals, the better :).