Reviving the Master Test Plan in the Age of Agile
Retro is back: Vinyl is in, and clothing styles are a throwback to decades-old flares, fringe, and suede. Of course, Jimmy Buffett seems to have spanned generations, but I digress!
One of the more retro—or, in this case, I prefer “traditional”—software development and testing approaches is the master test plan. The idea is that there is an overarching plan describing all the testing activities for a project or product, with subplans focused on specific testing activities such as integration, system, and acceptance testing, called detailed test plans.
One key challenge with such an approach is that often, these documents are seldom read or adequately reviewed, and many are cut and pasted content from previously created plans, with little new critical thought put into them.
As organizations move to an agile culture, we have embraced the Agile Manifesto value of “working software over comprehensive documentation.” This has never meant no documentation, as noted by the manifesto. Nonetheless, in the competitive environment of delivering software more quickly, with just the right level of quality and functionality at reasonable costs, many teams have abandoned master test plans and detailed test plans.
The value of these test plans (or any plan, for that matter) is not in the thickness of the document or the size of the soft-copy file. It’s the thought processes, the questions asked and answered, the creative thinking, the decisions agreed upon, the risk assessments, and the resulting test designs and approaches that provide the benefits. How we document our thinking is secondary to the thinking itself—or, as President Dwight D. Eisenhower noted, “plans are useless, but planning is indispensable.”
Regardless of what specific software development and testing methodology our team employs (test-driven development, acceptance test-driven development, behavior-driven development, or others), it’s important to apply some intellectual horsepower before execution. We should employ the shared wisdom of the agile team to proactively think about how we will evaluate the software: What functional and nonfunctional characteristics are important to assess, and does the product support the key business needs? Some agile teams are finding that an overarching test plan for a release or multiple releases is beneficial, so they are reviving the master test plan approach for agile releases and sprints.
When it comes to the set of information to be included in a master test plan, items such as test tools, techniques, methods, metrics, testing types, responsibilities and tasks, test environments, and so forth may not change significantly from sprint to sprint or release to release. Items such as scope, test conditions, test charters, risks, assumptions, resources, and estimates tend to be more fluid. A lightweight master test plan might house the agreed-upon thinking of the team for those items that do not change frequently.
Again, I emphasize that we are employing these templates, either standard or customized, to help us have the conversation and do the critical thinking and planning required. We can choose whether we need to document these outcomes, and if so, where (in a document, user stories, use cases, workflows, Google sheets, mind maps, Gherkin, a test management system, the code, or many other forms).
Consider reviving the master test plan approach as a means for driving the conversation around test planning.
