StickyMinds columnist James Bach has used this space to describe and discuss Exploratory Testing, a style of testing that emphasizes product exploration and fluid test design and execution. In this week's column, test consultant Lee Copeland adds his own twist to the exploratory premise.
Exploratory Testing as described by James Bach is a style of testing that emphasizes concurrent product exploration, test design, and test execution. In today's topsy-turvy world of incomplete, rapidly changing requirements and minimal time for testing, James suggests that the classical sequential approach of Test Analysis followed by Test Design followed by Test Execution is like playing the game of "20 Questions" by writing out all the questions in advance.
Recently, in an article for StickyMinds.com entitled "Exploratory Testing and the Planning Myth," James wrote, "Exploratory Testing, as I practice it, usually proceeds according to a conscious plan. But not a rigorous plan … it's not scripted in detail." He continues, "What if it [the plan] comes into existence only moments before the testing? … In football, when the quarterbacks find that their receivers are all covered, they may quickly make a new plan to run with the ball. An instant later, they execute their new plan."
As I read that sentence, the light bulb above my head began to brighten. It's not Exploratory Testing that should be our guiding principle-it's Exploratory Planning.
Planning has been defined simply as "figuring out what to do next." Most of us would admit that to be effective and efficient, planning is important. But when and how should that planning be done? Must it be done so very early in the project, when our knowledge is typically at its minimum?
I'd like to expand on the football analogy James uses in his article. When are football plays planned? Our first thought might be in the huddle, but the following table shows more possibilities:
| Before the game begins (the first ten plays are scripted and executed without regard to their success or failure) |
| Before each play (in the huddle, based on an overall game plan, field position, strengths and weaknesses, and player experience) |
| At the line of scrimmage (depending on the defensive setup) |
| Start of a play (play action-run or pass depending on the defense) |
| During the play (scramble when all else has failed) |
So here's the relationship between classical planning and exploratory planning in football:
| Classical Planning | Before the game begins (the first ten plays are scripted) |
| Exploratory Planning | Before each play (in the huddle) |
| At the line of scrimmage (depending on defensive setup) | |
| Start of a play (play action-run or pass) | |
| During the play (scramble when all else has failed) |
Let's now leave football and consider software test planning. (I know you'd rather stay with the NFL, but we've got software to test.)
| Classical Test Planning | As requirements, analysis, design, and coding are being done-long before the testing begins |
| Exploratory Test Planning | Before each screen/function/flow |
| Choosing a strategy (depending on our current knowledge) | |
| Start of a test (choose different options) | |
| During the test (scramble when all else has failed) |
So, there's the secret-Exploratory Planning. We plan as much as we can (based on the knowledge available), when we can (based on the time available), but not before. When we apply Exploratory Planning to Testing, we create Exploratory Testing. In what areas could you use Exploratory Planning where you now use classical planning? With what benefit?
