KISS your test plans, but not goodbye

Problem: Long and boring test plan documents are never read, hence end up not being used.

On many of the larger programs I have been managing, test plans have been huge documents build around the IEEE829 standard – These documents could be as large as 50+ pages, and so detailed that most readers got bored to death, and skipped reading the plan.

I really like the structure of the IEEE test plans, but not the result, as it ends up with a result that is unwieldy and hard to use in practice. The test plan template holds a lot of valuable sections that provide the test team with just the right information, but communicating the plan across to other stakeholders without causing an information overload is very hard.

Solution: Apply KISS principle to the version of the plan you use for communication.

I have had great success replicating the plan in a digestible version I PowerPoint  - I usually use 14 slides, one for each section in the IEEE test plan.

• Introduction
• Test items
• Features to be tested
• Features not to be tested
• Approach
• Item pass/fail criteria
• Suspension criteria and resumption requirements
• Test deliverables
• Testing tasks
• Environmental needs
• Responsibilities
• Staffing and training needs
• Schedule
• Risks and contingencies

Each slide holds the very essence of what is in the test plan document – Like a management summary. Some of the slides holds items that some stakeholders needs to commit to, and these are the ones that you need to pay very close attention to.

Test items, Features to be tested & Features not to be tested – This is your delivery contact with the project, make sure that he Project Manager & Client understand this, especially the what and why we have test items that are not tested.
Item pass/fail criteria & Suspension criteria and resumption requirements – This is the consequences of poor deliveries, this requires buy in from the Steering Group and Project manager. When the fighting gets though and time is running out this will be challenged, and having had the discussion while people are not under pressure makes the arguments more constructive.

Test deliverables & Testing tasks – Focus on the dependencies to other project deliveries. Critical path in the test effort is very important to mitigate risk and give you a better chance of success later on.

Responsibilities, Staffing and training needs & Schedule – Most important of all, who will show up, doing what and when. Often test borrows, steals and fights for resources, especially stealing and fighting can be avoided with clear agreements with other stakeholders.

Risks and contingencies – I use to call this the CMA (Cover My Ass) clause of the plan. This is where you can rant about judgement day, but it really does not matter much. What matters is to have clear and formalized procedures for risk management, so use the time getting those in place instead of listing all the risks you can possible think of.

Most important of all – Remember that your plan is like reality, it changes. These changes must be reflected in the plan, so keep it up to date, and renegotiate agreements that are obsolete due to the changes. If you do not do this I can assure you that you will have to compensate for the lack of planning with hard work.

Have a nice day & Happy usability testing!

/Nicolai