Rapid test planning is a process of cultivating test ideas within minutes, not days. Its opposed to rigorous test planning which strives to find every possible test. The trade-off is time vs. thoroughness because often were given tight constraints for testing. Management wants test results quickly and we can either freeze, get angry, or see what we can do.
I’ve experienced paralysis and anger many times in my 12 years of testing, but the more I stay in this business, the more I find myself seeing what I can do. These days, I consider it a challenge when a client says you have three days to test.
Enter rapid test planning. For me, it involves one or two exploratory testing “sessions” that result in a list of test ideas, issues, and risks. Exploratory testing is test design and execution happening at the same time, sometimes in the same second, as the tester gathers and analyzes data. The tester decides whats important, and the emphasis is on learning about the product.
A session could be 30 minutes or an hour or three hours, but the mission is the same what can we test?
At Quardev, clients usually don’t give us a lot of time to test, so our promise to them is to focus more on delivering information than creating written test cases. Thats why I often use rapid test planning.
Think of an American-style football game. You have 4 quarters, or roughly one hour of clock time to beat the other team by designing plays that advance the ball down 100 yeards of turf while the other team tries to stop you. Plays can involve throwing the ball or running with the ball until you reach the end of the field for a score. When the other team has the ball, it’s your turn to stop them from scoring, so each team has plans for offense and defense.
Let’s say my football team is the software were testing. Lets also pretend that I am a coach being interviewed. The sports reporter asks me a spontaneous question during the off-season to catch me off-guard to get a good sound bite for his story:
If you were playing the Seahawks today, what would be your game plan?
In answering rapidly to give them a great quote, I might think in terms of the following 5 elements:
- Structure: The team’s composition.
- Function: The team’s capabilities.
- Data: What the team might “process” – i.e. what we do with the ball.
- Platform: What the team depends upon.
- Operations: How Ill use my teams skills.
Using a mnemonic like SFDPO is considered a heuristic a fallible method for solving a problem. Its not meant to be thorough or foolproof, just enough to start you on the road quickly to a useful solution. Using this particular heuristic (remembered as SFDPO or San Francisco Depot), I might say something like:
Ive got a deep bench (STRUCTURE), so Im confident that our past performance on special teams against the Seahawks has been great (FUNCTION) when we pass the ball instead of run it (DATA). Given my star players arent that healthy right now (PLATFORM), Id start them in the third quarter, especially if that wind picks up out there (OPERATIONS).
This sound bite gives you an idea of how a coach might inventory their ideas on-the-fly. As coach, I might be wrong about the plan since its just a gut check, so Ill likely adapt it once the game starts and get more information.
For more heuristics like SFDPO to use in rapid test planning, click here.
Execution
Ok, so heres how I do it:
- The gauntlet is thrown down: Test this! You have 3 days.
- I ask questions to get more context for my mission or information to enhance my plan
- I start the session (setting the table for dinner, in effect), asking for anything I can get:
- the software
- specs or product docs
- project docs
- marketing literature
- names of knowledgeable project staff who can help me later
- a projector and a PC with a web connection (to do on-the-fly research)
- I think of things that trigger other ideas
- I end the session and go over it with as many stakeholders as possible
- go to step 2
OR
Declare that the plan is good enough for now to get testers engaged on their own exploratory testing sessions to find bugs with minimal supervision. Click here for ideas on how to tell if your plan is good enough.
For more on the mechanics of exploration and analysis, see this paper.
Other good sources:
- My brother James Bach at his testing consulting company Satisfice, most famous for offering the Rapid Software Testing course
- Michael Bolton, principal consultant at DevelopSense, who also gives the Rapid Software Testing course.
- Robert Sabourin, principal consultant at Amibug.
- James Lyndsay, principal consultant at Workroom Productions.
