The 10-minute software test plan

If test plans have any value at all, then let's get to that value as quickly as possible.

Anything in software development that takes 10 minutes or less to perform is either trivial or is not worth doing in the first place. If you take this rule of thumb at face value, where do you place test planning? Certainly it takes more than 10 minutes. In my capacity as test director at Google, I presided over teams that wrote a large number of test plans, and every time I asked how long one would take, I was told "tomorrow" or "the end of the week" and a few times, early in the day, I was promised one "by the end of the day." So I'll establish the task of test planning to be of the hours-to-days duration.

As to whether it is worth doing, well, that is another story entirely. Every time I look at any of the dozens of test plans my teams have written, I see dead test plans—plans written, reviewed, referred to a few times, and then cast aside as the project moves in directions not documented in the plan. This begs the question: If a plan isn't worth bothering to update, is it worth creating in the first place?

Other times, a plan is discarded because it went into too much detail or too little; still, others because it provided value only in starting a test effort and not in the ongoing work. Again, if this is the case, was the plan worth the cost of creating it given its limited and diminishing value?

Some test plans document simple truths that likely didn't need to be documented at all or provide detailed information that isn't relevant to the day-to-day job of a software tester. In all these cases, we are wasting effort. Let's face facts here: There is a problem with the process and content of test plans.

To combat this, I came up with a simple task for my teams: write a test plan in 10 minutes. The idea is simple. If test plans have any value at all, then let's get to that value as quickly as possible.

Given 10 minutes, there is clearly no room for fluff. It is a time period so compressed that every second must be spent doing something useful, or any hope you have of actually finishing the task is gone. This was the entire intent behind the exercise from my point of view: Boil test planning down to only the essentials and cut all fat and fluff. Do only what is absolutely necessary and leave the details to the test executors as opposed to the test planners. If I wanted to end the practice of writing test plans that don't stand the test of time, this seemed a worthwhile exercise.

However, I didn't tell the people in the experiment any of this. I told them only: Here is an app, create a test plan in 10 minutes or less. Remember that these people work for me and are paid to do as I tell them. Technically, I am uniquely positioned to begin termination procedures with respect to their Google employment. On top of that, I am presuming they have some measure of respect for me, which means they were likely convinced I actually thought they could do it.

As preparation, they could spend some time with the app in question and familiarize themselves with it. However, because many of the apps we used (Google Docs, App Engine, Talk Video, and so on) were tools they used every week, this time was short.

In each case, the teams came up with methodologies similar to ACC. They chose to jot down lists and create grids over writing long paragraphs of prose. Sentences ... yes, paragraphs ... no. They wasted little time on formatting and explanations and chose instead to document capabilities. Indeed, capabilities, as described in this text, were the one commonality of all the plans. Capabilities were the one thing that all the teams gravitated toward as the most useful way to spend the little time they were given.

None of the teams finished the experiment in the 10 minutes allotted. However, in 10 minutes they were all able to get through both the attributes and components (or things that served a similar purpose) and begin documenting capabilities. At the end of an additional 20 minutes, most of the experiments had a large enough set of capabilities that it would have been a useful starting point for creating user stories or test cases.

This, at least to me, made the experiment a success. I gave them 10 minutes and hoped for an hour. They had 80% of the work complete in 30 minutes. And really, isn't 80% enough? We know full well that we are not going to test everything, so why document everything? We know full well that as we start testing, things (schedules, requirements, architecture, and so on) are going to change, so insisting on planning precision when nothing else obeys such a calling for completeness seems out of touch with reality.

80% complete in 30 minutes or less. Now that's what I call a 10-minute test plan!

How Google Tests Software
This excerpt is from the book, 'How Google Tests Software' authored by James Whittaker, Jason Arbon and Jeff Carollo, published by Pearson/Addison-Wesley Professional, March 2012, ISBN 0321803027, Copyright 2012 Pearson Education, Inc. For more info please visit the publisher site, or"

ITworld has 5 copies of 'How Google Tests Software' to give to some lucky readers. Complete the form below for your chance to win!

First name: 
Last name: 
Enter me in the drawing to win a copy of "How Google Tests Software" Yes, I'd like to receive ITworld's daily newsletter Yes, sign me up for the weekly ITwhirled newsletter covering the lighter side of IT

* All fields are required

By clicking submit you agree to the terms and conditions outlined in ITworld's privacy policy.
Read the official giveaway rules.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon