7 wastes that have to be eliminated of the Software Testing

"Continuous improvement is not about the things you do well — that’s work. Continuous improvement is about removing the things that get in the way of your work. The headaches, the things that slow you down, that’s what continuous improvement is all about."

Bruce Hamilton

Software Testing requires effective resource management to prevent costly delays, budget overruns, and failed projects. In many software projects, more than 50 % of Software Development costs are attributed to Software Testing tasks. With Software Testing accounting for such a large portion of software development efforts, it is critical for software engineering teams to avoid and eliminate wasteful Software Testing tasks (Figure 1).

Figure 1 - Software Testing Effort versus
Software Development Effort

The basis of Lean Thinking (Video 1) is the 7 wastes that have to be eliminated.

Video 1 - Lean Thinking Introduction

Many of those can be related to Software Testing as well. They are:

Overproduction

Simply put, overproduction is to manufacture an item before it is actually required. Within Software Testing this might be what we want: before the start of the actual test execution the test cases, test data and test environment are prepared. On the other hand are we sure that we make a distinction between effort and depth of Software Testing based on the risks? Do we not have too much overlap between test levels? And what about the potential overkill of test plans? These can all be seen as overproduction within testing.

Unnecessary Stock

Work in Progress (WIP) is a direct result of overproduction and waiting. Instead of having good test cases ending up as shelf ware, good version control can make it possible to re-use test cases. Another example might be to look at the Software Testing teams and make them more flexible to work within various projects. This helps having the right number of people at the right moment in your projects. Another example is building more test cases than can be executed in the time available. Test cases that cannot be executed do not add value to the customer.

Inefficient Transporting

Inefficient Transporting a product between processes is a cost incursion which adds no value to the product. For Software Testing we can look at the way information gets to the tester or the amount of meetings there are with the Software Testing team.

Unnecessary Motion

This waste is related to ergonomics. As Software Testing is not so physical it might look difficult to relate this waste to testing. On the other hand we could translate this as the amount of releases to get to the required quality. The more (small) releases per period, the harder it might be to plan, prepare and execute the tests for these releases.

Waiting Times

Whenever goods are not moving or being processed, the waste of waiting occurs. Linking processes together so that one feeds directly into the next can dramatically reduce waiting. In Software Testing this is a very common and well known waste: waiting for designs, waiting for the right environment, waiting for support, etc.

Rejects & Defects

Having a direct impact to the bottom line quality, rejects and defects resulting in rework or scrap are a tremendous cost to organizations. Here a distinction between defects in the Software Testing process and defects in the software under test can be made. With Software Testing we help the organization to eliminate the waste of software defects. Every software defect a test team finds can be fixed before going into production. This is probably the most recognizable waste related to Software Testing. Defect in the Software Testing process itself is of course also a waste we have to be aware of. Improvement plans should also include our own Software Testing processes.

Inappropriate Processing

Often termed as “using a sledgehammer to crack a nut”, many organizations use expensive high precision equipment where simpler tools would be sufficient. We all might have examples of test automation tools or an expensive defect administration of which a big part of the functionality is not used. And we can even think of having too many test cases prepared for a small and simple functionality when we did not consider the product risks and their priority.

Adapted from "Lean Test Management – The future of testing?" written by Iris Pinkster-O’Riordain & Bob van de Burgt and published in the "The Magazine for Professional Testers".