A different perspective can give you a whole new approach to work. Here, László Szegedi suggests that the next time you need to plan something, you think backward—visualize your goal, then reverse-plan to map the whole process that leads to that result. He gives examples for simple tasks and for higher-level test planning.
In productivity expert Steven Covey’s book The 7 Habits of Highly Effective People, the second habit is “Begin with the end in mind.” What he means is, to plan a process, think backward. Assume you have already reached your desired goal, then reverse-plan to map the whole process that leads to that result.
Arthur Gogatz and Reuben Mondejar, who call this method “the reversal procedure” in their book Business Creativity: Breaking the Invisible Barriers, suggest that you “start in the middle and jump backwards and forwards.” This concept has been applied in so many varying contexts that you’ll even find advice about experimenting with walking backward in order to ease your mind to be creative.
Here, we’ll explore using this process in software testing. I’ll try to explain it by using examples varying from simple daily tasks to ones that involve a higher level of planning, both in software testing and planning work in general.
Testing Use Cases
Most test plans (and lists of test cases) go from the simple use cases to the more difficult ones. Those later, complex use cases often include the simpler ones too.
To work this planning backward, start with the test ideas that cover the complex use cases. As you finish the more complex use cases (my rule of thumb is to go through the most complex 30 percent of them), go back to the beginning and check how many of the simpler ones you have already covered. You will be surprised how easily you get high coverage. First do good work, then see what boxes still need checking—instead of being driven by a checklist. The process is better, more fun, and even involves a little exploration.
Order of Test Execution
Let’s say you have a well-defined set of test ideas (charters, cases, etc.) that can be very handy for regression testing. You are performing these test cases regularly to discover possible problems with a maintenance change in the existing legacy functions. Furthermore, let’s suppose that because there is no priority defined among these particular test ideas, you just execute them one by one, in the order they are written in your test plan collection. Over time you’ve developed some confidence in this set of tests; it covers the major flows your customers use.
So, why would you change? Executing these tests in reverse order will wake you up. You’ll think differently, and likely see different categories of bugs, as explained in Lee Copeland’s A Practitioner’s Guide to Software Test Design. Does the change in the order of test execution automatically mean you will find a new bug in the system? Of course not. This approach, however, can provide the opportunity to develop a new, effective test process that explores an area of the system that was hidden or not covered with the previous tests. You also could get some ideas about how to change your test data to deliver new test results.
If you have a workweek full of scheduled meetings—say, four to five meetings a day—you simply will not have enough time to prepare for all of them. Planning backward can help save you some effort.
When you’re getting ready for the meetings at the beginning of the week, start with the last ones scheduled for Friday afternoon. Prepare for them a little, then move on to the ones scheduled for Thursday, prepping for those a bit more than the ones on Friday but still not taking the time to plan extensively. You’ll likely have some free hours during the week to finish your preparation for the meetings toward the end of the week and to align your material with any recent developments. Plus, some of your meetings will probably be canceled, so this way you won’t waste time preparing for them completely before you absolutely have to.
When you start planning testing for any project, there is usually an end date in mind. Instead of thinking about all the individual tests, ask, What are the major milestones, and what do I have to accomplish to reach them? What kind of hurdles and risks will occur during these time intervals? Planning for these steps will result in your having a better understanding of the cost and the time restraints you will meet during the testing period. With these considerations, you will have more insight into creating the test plan for your particular project.
Yearly Performance Review
Many companies use an annual performance review to measure and motivate their employees’ performance and development throughout the last year. It can also be connected to setting the employees’ personal and professional goals for the next year. Sadly, people often have grand visions at the beginning of a new year, then forget about the process entirely until it’s time for the next review.
Instead, put a little effort into it. Just as with test planning, you can set milestones and check what you need to do in order to learn or develop. Plan backward from the next year until you reach the present, and you will have a better understanding of what you need to do by what time periods to reach your goals.
Planning backward can also help you realize whether your goals are appropriate. You may decide that the goal is too high or that there’s not enough time to prepare to reach it. You may also plan to reach a particular goal earlier if it seems doable in a shorter timeframe.
Put It to Work
Of course, planning backward will not solve all your problems. It’s not realistic for every situation you’ll encounter. But this approach could help boost your creativity and efficiency, and these are some important skills for a software tester.
The next time you need to plan a process or an activity, think about planning it backward. Starting at the finish line is worth a try.