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

D. Richard Kuhn – Computer Scientist, National Institute of Standards & Technology LogiGear: How did you get into software testing? What did you find interesting about it? Mr. Kuhn: About 10 years ago Dolores Wallace and I were investigating the causes of software failures in medical devices, using 15 years of data from the FDA. ...
Reducing the pester of duplications in bug reporting. Both software Developers and Testers need to be able to clearly identify any ‘Bug’, via the ‘Title’ used for the ‘Bug Report’.
For mission-critical applications, it’s important to frequently develop, test, and deploy new features, while maintaining high quality. To guarantee top-notch quality, you must have the right testing approach, process, and tools in place.
When it is out of the question to delay delivery, the solution is a prioritization strategy in order to do the best possible job within the time constraints. The scenario is as follows: You are the test manager. You made a plan and a budget for testing. Your plans were, as far as you know, ...
LogiGear Magazine – July 2011 – The Test Methods & Strategies Issue
Differences in interpretation of requirements and specifications by programmers and testers is a common source of bugs. For many, perhaps most, development teams the terms requirement and specification are used interchangeably with no detrimental effect. In everyday development conversations the terms are used synonymously, one is as likely to mean the “spec” as the “requirements.”
Introduction Many companies have come to realize that software testing is much more than a task that happens at the end of a software development cycle. They have come to understand that software testing is a strategic imperative and a discipline that can have a substantial impact on the success of an organization that develops ...
Please note: This article was adapted from a blog posting in Karen N. Johnson’s blog on July 24, 2007. Introduction The password field is one data entry field that needs special attention when testing an application. The password field can be important (since accessing someone’s account can start a security leak), testers should spend more ...
March Issue 2020: Smarter Testing Strategies for The Modern SDLC
First, let me ask you a few questions. Are your bugs often rejected? Are your bugs often assigned back to you and discussed back and forth to clarify information? Do your leaders or managers often complain about your bugs?
I’ve been intending to write a book review of How We Test Software At Microsoft, by Alan Page, Ken Johnston, and Bj Rollison, but for whatever reason I just never found the time, until now. In general, I like this book a lot. It’s a nice blend of the tactical and the strategic, of the ...
Jeff Offutt – Professor of Software Engineering in the Volgenau School of Information Technology at George Mason University – homepage – and editor-in-chief of Wiley’s journal of Software Testing, Verification and Reliability, LogiGear: How did you get into software testing? What do you find interesting about it? Professor Offutt: When I started college I didn’t ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe