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.
LogiGear Magazine – May 2011 – The Test Process Improvement Issue
Think you’re up for a challenge? Print this word search out! See if you can find all the words and learn a few new software testing terms in the process. To see how you’ve done, check your answers in the answer key below. *You can check the answer key here.
This article was adapted from a presentation titled “How to Turn Your Testing Team Into a High-Performance Organization” to be presented by Michael Hackett, LogiGear Vice President, Business Strategy and Operations, at the Software Test & Performance Conference 2006 at the Hyatt Regency Cambridge, Massachusetts (November 7 – 9, 2006). Introduction Testing is often looked ...
Regardless of the method you choose, simply spending some time thinking about good test design before writing the first test case will have a very high payback down the line, both in the quality and the efficiency of the tests. Test design is the single biggest contributor to success in software testing and its also ...
Karen N. Johnson began as a technical writer in 1985 and later switched to software testing in 1992. She maintains a blog at TestingReflections, a collaborative site where she is featured as a main contributor. In her latest entry, she discusses search testing with different languages. Here is an excerpt from her blog: “I started ...
This article was developed from concepts in the book Global Software Test Automation: Discussion of Software Testing for Executives. Quality cost is the sum of all costs a company invests into the release of a quality product. When developing a software product, there are 4 types of quality costs: prevention costs, appraisal costs, internal failure ...
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.
People who follow me on twitter or via my blog might be aware that I have a wide range of interests in areas outside my normal testing job. I like to research and learn different things, especially psychology and see if it may benefit and improve my skills and approaches during my normal testing job. ...
Are you looking for the best books on software testing methods? Here are 4 books that should be on your reading list! The Way of the Web Tester: A Beginner’s Guide to Automating Tests By Jonathan Rasmusson Whether you’re a traditional software tester, a developer, or a team lead, this is the book for you! It ...
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 ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe