Introduction
This article discusses the all-too-common occurrence of the time needed to perform Software Testing being short changed as specification, development, and unforeseen “issues” cause the phases prior to testing to expand. The result is that extreme pressure is placed upon the testing organization to perform the testing function within a reduced time frame. The article proposes 5 principals to help reduce the pressure on testing.
The Testing “Crunch” Zone
Most organizations typically view a software development effort as a series of discreet steps as shown in the following diagram.
This diagram shows the steps of a “typical” software development project:
- Specifications and requirements are drawn up
- Implementation takes place
- As the final step, the new system or system change is tested and released
This simplistic view of development allocates a set amount of time for specification, development, and testing. Unfortunately, unforeseen “issues” crop up that cause both the specification and development phases to use more than their allocated time eating into the time available for testing. Since 1994 when I proposed the Action-Based Testing method, I have presented this scenario with the following picture:
All projects have a deadline for release. The deadline is typically an external commitment and therefore difficult to change. The picture above shows the situation in which both specification and development have taken more time than expected. Since the deadline is difficult to change, the pressure is placed upon testing to test and meet the deadline. I call this testing under dead-line-driven time pressure the “crunch zone.”
Of course the picture is a simplification, not taking into account practices like Agile system development. However, in just about every presentation I give, I show this picture and ask the audience whether this applies to their own situation. The answer is always a clear “yes.” Regardless of the size, maturity, and geographical location of the organization, the picture almost always applies.
The Testing Crunch Zone Must be Addressed
The crunch zone can probably never be avoided completely. It seems to be human nature, or limitation. We have (1) a hard time anticipating the many issues a project will encounter, and (2) a tendency as an organization to “use up” what is perceived as “room” in a project schedule—room that eventually will not be available. Crunching testing into the available time prior to release is never a good recipe for an effective testing effort. Testing under pressure can cause mistakes. Mistakes get released to customers as bugs and defects—a situation that management wants to avoid.
From a management point of view, the conclusion is simple: regardless of whether you expect project phases to delay, you must anticipate pressure in the testing phase, and take sensible precautions. This line of thinking may also apply to other “last minute” activities, like documentation, marketing, and training, but for this article the focus is on testing.
The best way to alleviate pressure in the testing crunch zone is to prepare testing work in parallel with specification and development activities (as shown in the below diagram). While many organizations do some kind of test case preparation prior to testing, their efforts are typically limited and thus the effectiveness of the effort is limited.
The following are 5 principals to help an organization deal with the testing crunch zone and help to alleviate pressure on testing.
5 Principals to Reduce Testing Pressure
Here are the 5 principles that I apply to projects to help reduce pressure in the crunch zone:
- Be economical with test case descriptions. Too often I see verbose test plans, with elaborate texts for test cases and their expected outcomes. This takes time to write, but also time to read and execute.
- Do not repeat instructions. A common issue, in particular with manual test cases, is to see the same instruction, like “Click the OK button,” repeated hundreds or more times. Not only is this extra work in creating a test case, but it also makes the test case sensitive to changes in the system under test (assume for example that the “OK” button is re-named to “Process” button).
- Be explicit in values. A text like “apply valid values for all input fields” shifts the effort to the test execution phase. This happens to be in the crunch zone, and it means the same effort, thinking of valid values, has to be repeated every time the test is repeated.
- Use as much Automation as possible. Automating test execution means tests can be quickly executed when the crunch zone arrives, and can be repeated when new builds become necessary such as those resulting from earlier bug fixes.
- Make the Automation as adaptable to changes in the system under test as possible. If you cannot make Automation that adapts to changes quickly you are likely to spend more time on Automation maintenance than you gain from having the Automation in the first place. The principle is simple: better no Automation than bad Automation.
In our other articles and publications we talk about Action-Based Testing as a very good vehicle to achieve these 5 principles, and thus truly reduce the pressure in the crunch zone. In Action-Based Testing, tests are written using “actions,” which hide unneeded details like which buttons to push. If a test needs to be adapted to changed system behavior most of those modifications tend to involve single actions, not the (many) times those actions are used in the tests.
Conclusion
Regardless which method or tool gets used, anticipating the crunch zone as a reality is essential to achieve testing and project success. Performing test preparation in parallel with specification and development, and following the 5 principals outlined in this paper, will help any organization to effectively deal with the testing crunch zone.
