Surviving the Top Ten Challenges of Software Testing: A People-Oriented Approach

Surviving the Top Ten Challenges of Software Testing: A People-Oriented Approach

Ashbacher, Charles


by William E. Perry and Randall W. Rice

Dorset House Publishing, New York, NY, 1997, 216 pp.

As software projects have grown in size and scope, the number of ways a single program can be used is huge. The combinatorial explosion of possible paths easily reaches the billions or higher, making it impossible to completely test all of them. Throw in the dynamic interactions between software modules, and there is the problem of what needs to be re-tested after modification. Furthermore, developers are often loath to perform testing, and every study leads to the solid conclusion that no one should test their own creation anyway. Hence, the development of independent testing teams.

Creating, motivating, and managing those teams is a formidable task. The testing team is in the middle between the rock of the developers and the hard place of demanding customers. They must be ruthless in their search for errors, yet not so exhaustive that the product is never completed. Managers must be satisfied that the testing effort is cost-effective and worth the delay.

The top ten list of challenges is described as follows: 10) Getting Trained in Testing

Placing someone down at a terminal and telling them to test a package is an enormous waste. Testing is a profession with strategies, competencies and a sense of pride. These qualities must be instilled, and that requires quality training.

9) Building Relationships With Developers

The relationship between testers and developers is by nature a strained one. It is easy to slip into the state of mutual dislike even though their goals are the same.

8) Testing Without Tools

While this can be done, it is to be avoided if possible. Manual testing is prone to error. The cost of most tools can be recovered by the discovery of even one serious bug.

7) Explaining Testing to Managers

Testing is not only the last step of the software cycle, it is often thought of as reserved for menials. This is commonly reflected in the amount of money budgeted for testing. Since a bug caught in-house costs a fraction of what one can cost in the hands of a user, this is very short-sighted.

6) Communicating With Customers – And Users

Testing is more than just finding bugs in the code. A significant part of testing is determining if what has been produced is what should have been produced. That means that there must be communication channels open for twoway traffic.

5) Making Tine For Testing

This probably is the most difficult challenge of all. In most cases, by the time the product goes to testing, it has been in the development process for a year or more. It has no doubt been advertised and, if it has any appeal, there are customers who are looking forward to the ship date and are eager to buy. Given these circumstances, wedging in adequate time for testing is very difficult.

4) Testing What’s Thrown Over The Wall

When the developers are done, they often throw the package “over the wall” to the testers, who test it and if it fails, throw it back. It is much better if they perform simple hand-overs with face-to-face, professional conversations.

3) Hitting a Moving Target

This is most likely the second most difficult challenge. Modifying one module can affect the behavior of others. Trying to interweave the continued testing and fixing of errors is the amalgamation of two complex tasks.

2) Fighting A Lose-Lose Situation

Since exhaustive testing is not possible and there are so many forces trying to pry the software out of the hands of the tester, there must come a time to let it go. Determining how much quality is enough is a real art.

1) Have To Say No

There are times when the testers just have to say that the software is not yet ready for shipping. This requires courage, conviction, dedication and a willingness to stand your ground.

The authors of this book deal with all of these challenges in great detail, both from the perspective of the tester and of the manager. This is a book that should be read by all computer science students. There are many jobs in the software industry, but most companies start many of their new employees as testers and are disappointed with their background and training in this area. One employer even approached the local community college about the possibility of starting a program to train testers. Reading this book will not make you a quality software tester, but it is the first step toward becoming one.

Reviewed by Charles Ashbacher Charles Ashbacher Technologies

Copyright Mathematics and Computer Education Winter 2000

Provided by ProQuest Information and Learning Company. All rights Reserved