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

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 ...
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?
Dr. Cem Kaner – Director, Center for Software Testing Education & Research, Florida Institute of Technology PC World Vietnam: What did you think of VISTACON 2010? Dr. Kaner: I am very impressed that the event was very professionally organized and happy to meet my old colleagues to share and exchange more about our area of ...
This is an adaptation of a presentation entitled Software Testing 3.0 given by Hung Nguyen, LogiGear CEO, President, and Founder. The presentation was given as the keynote at the Spring 2007 STPCON conference in San Mateo, California. Watch for an upcoming whitepaper based on this topic. Introduction This first article of this two article series ...
PWAs have the ability to transform the way people experience the web. There are a few things we can agree we have seen happen. The first being that we figured out the digital market from an application type perspective. Secondly, we have seen the rise of mobile, and lastly, the incredible transformation of web to ...
Test organizations continue to undergo rapid transformation as demands grow for testing efficiencies. Functional test automation is often seen as a way to increase the overall efficiency of functional and system tests. How can a test organization stage itself for functional test automation before an investment in test automation has even been made? Further, how ...
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 – July 2011 – The Test Methods & Strategies Issue
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.
Introduction Keyword-driven methodologies like Action Based Testing (ABT) are usually considered to be an Automation technique. They are commonly positioned as an advanced and practical alternative to other techniques like to “record & playback” or “scripting”.
Most have probably heard the expression ‘less is more‘, or know of the ‘keep it simple and stupid‘ principle. These are general and well-accepted principles for design and architecture in general, and something that any software architect should aspire to. Similarly, Richard P. Gabriel (a major figure in the world of Lisp programming language, accomplished poet, and currently ...
VISTACON 2010 – Keynote: The future of testing THE FUTURE OF TESTING BJ Rollison – Test Architect at Microsoft VISTACON 2010 – Keynote   BJ Rollison, Software Test Architect for Microsoft. Mr. Rollison started working for Microsoft in 1994, becoming one of the leading experts of test architecture and execution at Microsoft. He also teaches ...

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