Stop Writing Overdone Test Plans

jo2sn Softwaretesting, , , , , ,

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.

You have to deliver a Dev Plan in a written prose format detailing the roles, processes, acceptance criteria and deliverables.

Said Noone ever

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.

Everything and the kitchen sink
Everything and the kitchen sink

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)

14 thoughts on “Stop Writing Overdone Test Plans”

  1. In a previous job developing billing systems, I was unusual in that I gave my team a list of development priorities. I don’t remember seeing that before or since. It was a fully ordered (i.e. one thing per line, no ties) list of general qualities that we agreed cut across everything. E.g.:
    1. Correctness
    2. Speed
    3. Ease of changing the code
    etc.

    I did it because I thought it was helpful – if someone has to decide between approach X or Y, which one does better by our priorities?

    Our customers worked in regulated industries, so correctness (or its lack) could put them out of business. Also, this was at big scale, so we had to get through work quickly.

    It was the closest I’ve seen to dev-plan-written-in-prose, but it was a list of 8 or so short items and certainly not War and Peace.

    Liked by 1 person

    Reply

  6. […] What most people delivering effectively software are using is 1) modern test automation and 2) modern test case management tools to lead and manage the test activities. And there is clear research on what 24 factors correlates to high-performing teams. It seems to me the templates have been frozen stale since 2012 – and are hindering us more than helping. […]

    Like

    Reply

  7. […] One of the usual arguments is that it enables hard-over from person to another. While handover can be relevant to consider if the team members changes often. It seems to me just to create redundant information based on requirements and other oracles. I mean where does it it end, why should we add every project information into the test cases and into the test plan. Stop it already. […]

    Like

    Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.