While I have previously talked about writing down expectations and alignments – I would much prefer a more lean and up-to-date approach to test plan documents. Looking at what we know now, an separate test is more of a sign of missing trust between parties than a collaborative value add for the business needs.
If you have to write too much down, and debate the documents over and over – it might be organizational maturity issue, but it’s most likely a people problem and a trust issue.
To others, plans are activities – not prose.
Yet again today I had this conversation:
X: We need a test plan
Me: A Test Plan document or a plan for the test activity?
X: Is there a different thing besides an plan of the testing activity?2021 – looking like 2012
When we talk with project managers, scrum masters, delivery managers etc. they don’t know the difference. They see testing as an activity, not as some verbatim elaborations of definitions, terms and conditions.
We are making it unnecessary hard on ourselves
When you become the pointy cog in the wheel (or bottleneck in a lean vocabulary) you get all the bumps and heat. I can see how the test plan templates have evolved over the years. Written in project blood as check lists usually are. but now they are being used against the testers and test managers. We have simply been painted into a corner and have asked for everything and the kitchen sink.
It would surprise me if such a thing was in active use, so let me know in the comments. Notice, I don’t count a specification or design doc as the above. How the delivery team works is at best described in the company handbooks or in a contract.
A separate plan will not give you credit
Recently I was reading the evaluation of a two-digit million dollar tender reply. It was specifically mentioned that the customer valued it negatively that the tender reply wanted to provide both a project plan and a test plan.
Don’t position the testing work outside the delivery process and delivery timeline. Be included in the project managers elaborate GANTT chart, both for your own sake and for the others. If the delivery method (agile, waterfall) is changed – so should the test strategy and test approach.
So, what can you do?
First put the emphasis on the test strategy – map it out. The contract, strategy or company hand book will address what rarely changes: Roles, Acceptance Criteria, Defect priorities. Put it on a wiki or SharePoint site. Those places have built-in version control and audit logs, so if you have to make a PDF baseline every now and then.
The core of the test plan is really the scope (requirements of the release) and the related test coverage (tests that cover the scope). Perhaps group it into the engineered test effort and the people based effort, or other relevant groups for your context.
Draw the specific test activities to the sprint or release as a mind map – as suggested by Nishi in 4 Tips to Create a Simplified Test Plan for Your Agile Project.
Be smart about it and make exports from a relevant test case management system or peruse the one page test plan:
(One Page Test Plan by Claire Reckless, on the Ministry of Testing)