How QA Lead benefits from a Test Plan in terms of processes? I am interested in specifics. What practical usage QA Lead has from a test plan? Currently, I have only seen that it is required for the customer in terms of reporting but I am having a hard time seeing the practical benefits towards the actual testing. Types of testing and approach to testing in my opinion can be conveyed verbally and it is unlikely that a qualified tester will discover some new information on how he should test from a test plan.

  • Even historically, the idea was never to give new information to tester but to develop and share an implementation plan for & with the stakeholders to achieve the agreed upon testing goals. Jul 28 at 13:52
  • Written test plans for executing manual tests are largely pre-agile artifacts being produced by the same but now "agile" organizations. The quotes are imported. See Agile manifesto. Software over comprehensive documentation. Jul 28 at 14:41

This will likely change according to a context. You might find it unnecessary to even have such a document, because your organisation perhaps works in Agile where we generally prefer working software over comprehensive documents. Also the teams in an Agile environment tend to be small (seven plus minus two is a number that's usually mentioned as ideal), which it then easier and in many instances sufficient to use verbal communication.

I can, however, imagine some other environment where there's more need for formality, which then implies having such documents. Typically we can talk about:

  • projects where we're expected to create such documents because of law and regulations, something like critical safety industries come to mind, even though I have never worked in such an environment, so I don't speak from my own experience here
  • projects that involve many people who do not work in Agile
  • when a client asks for such a document, so it's a part of the solution the client pays for

it is unlikely that a qualified tester will discover some new information

Perhaps it's not about getting new information, but having a framework I can look into and see if I'm on the right track. A section of a test plan with a few bullet points can give you more ideas about what you might have forgotten. Having said that, perhaps it can be used more like a thought generation tool than an exact script of activities to do (since you likely know yourself how to test and use your skills to help the project).


I agree that test plans typically do not benefit QA Leads, they only serve the customer if the product uses mature tech stacks and processes. That's just not how it works when those things change.

Suppose your test team was testing RESTful APIs using the Postman GUI client on JSON. Then you adopt Kafka with its new data structure (avro) and need an avro compatible GUI client if you want the test team to test the same way. You find out that you can't use the GUI client. You then have this awkward situation where you can't access the code at different layers if all you know is using RESTful APIs. You can't test a huge chunk of what Kafka offers. You need a plan on how to manage these risks. You could make testers use the CLI to get the data, but that's slow. You could get a test harness made to speed it up. Who's going to make and maintain it? And these problems are only for manual testing.

The test plan can answer these risks. You also get a history of how effective your mitigations are. Databases only give you the ability to rollback state to before the release. That mitigation may work in test but it's slow in prod. You need to test the mitigations. Can you roll back to a state that's not a mess? Can you replay the changes in state anytime during the outage? (These are questions I've asked myself in Kafka).

Can we test earlier on our local machines? You might not have a test environment ready and the environments are never the same anyway. But now, tech's got environment provisioning, automated deployment, playbooks, that can make environments come up configured in source control which work on any host. You get to test much earlier, finding the environment dependencies like which version of the .NET runtime to have on the target environment and what other dependencies need to be there that weren't considered during design. You could have tests running in a build pipeline before you even get a machine for the TEST environment.

Tech is changing. Ways of getting things done need to change too. As a QA Lead, the Test Plan is be the snapshot of what was the best thinking at that time. A year from now your plan should be different. Your team's got different skills and they've grown. And you, QA Lead, get to serve your team by getting it what it needs.

  • A great answer but the term 'test plan' usually refers to a specific plan for a test of a specific feature. What you have described here has great detail but seems more suited to describing test planning at a much higher, architectural level Jul 28 at 14:39
  • 1
    +1 for the perspective of test plan as snapshot of thinking at that time. Aug 9 at 23:44

Strategy is vision, plan is its implementation.

I think in today's agile world, test plan does not have any relevance as testing is more integrated and dependent with dev activities as done in small sprints.

Although I think test strategy still has relevance as its more about guiding principles(in given context) than actual implementation like test plan.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.