Testing Under Pressure: Relieving the “Crunch Zone”

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:

  1. Specifications and requirements are drawn up
  2. Implementation takes place
  3. 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:

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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.

Hans Buwalda

Hans leads LogiGear’s research and development of test automation solutions, and the delivery of advanced test automation consulting and engineering services. He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations.

Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.

Hans holds a Master of Science in Computer Science from Free University, Amsterdam.

Hans Buwalda
Hans Buwalda, CTO of LogiGear, is a pioneer of the Action Based and Soap Opera methodologies of testing and automation, and lead developer of TestArchitect, LogiGear’s keyword-based toolset for software test design, automation and management. He is co-author of Integrated Test Design and Automation, and a frequent speaker at test conferences.

The Related Post

  Explore It! is one of the very best software testing books ever written. It is packed with great ideas and Elisabeth Hendrickson’s writing style makes it very enjoyable to read. Hendrickson has a well-deserved reputation in the global software testing community as someone who has the enviable ability to clearly communicate highly-practical, well-thought-out ideas. ...
Internet-based per-use service models are turning things upside down in the software development industry, prompting rapid expansion in the development of some products and measurable reduction in others. (Gartner, August 2008) This global transition toward computing “in the Cloud” introduces a whole new level of challenge when it comes to software testing.
Last week I went to StarWest as a presenter and as a track chair to introduce speakers. Being a track chair is wonderful because you get to interface more closely with other speakers. Anyway…one of the speakers I introduced was Jon Bach. Jon is a good public speaker, and I was pleasantly surprised that he ...
Test design is the single biggest contributor to success in software testing. Not only can good test design result in good coverage, it is also a major contributor to efficiency. The principle of test design should be “lean and mean.” The tests should be of a manageable size and at the same time complete and ...
With this edition of LogiGear Magazine, we introduce a new feature, Mind Map. A mind map is a diagram, usually devoted to a single concept, used to visually organize related information, often in a hierarchical or interconnected, web-like fashion. This edition’s mind map, created by Sudhamshu Rao, focuses on tools that are available to help ...
This article was originally featured in the July/August 2009 issue of Better Software magazine. Read the entire issue or become a subscriber. People often quote Lord Kelvin: “I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express ...
Test plans have a bad reputation, and perhaps, they deserve it! There’s no beating around the bush. But times have changed. Systems are no longer “black boxes” where QA Teams are separated from design, input, and architecture. Test teams are much more technically savvy and knowledgeable about their systems, beyond domain knowledge. This was an old ...
I’ve been reviewing a lot of test plans recently. As I review them, I’ve compiled this list of things I look for in a well written test plan document. Here’s a brain dump of things I check for, in no particular order, of course, and it is by no means a complete list. That said, if you ...
“Combinatorial testing can detect hard-to-find software faults more efficiently than manual test case selection methods.” Developers of large data-intensive software often notice an interesting—though not surprising—phenomenon: When usage of an application jumps dramatically, components that have operated for months without trouble suddenly develop previously undetected errors. For example, newly added customers may have account records ...
LogiGear Magazine – July 2011 – The Test Methods & Strategies Issue
The 12 Do’s and Don’ts of Test Automation When I started my career as a Software Tester a decade ago, Test Automation was viewed with some skepticism.
Experience-based recommendations to test the brains that drive the devices In essentially every embedded system there is some sort of product testing. Typically there is a list of product-level requirements (what the product does), and a set of tests designed to make sure the product works correctly. For many products there is also a set ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe