Good software testers save money

Quality software doesn't happen on its own, so wherever there is software, there will be a swarm of bugs. The answer would seem to lie in testing, but testing faces major problems.

In SA, testers, too often seen as a necessary evil, get short shrift from CIOs and software development project heads, besides the development teams themselves.

Everyone in the software industry knows that testing can make or break a software development project. It seems, however, that software delivery deadlines are not often adjusted, which frequently results in systems of sub-optimal quality going into production. Project leads don't always know they need to test their software and test it early and often.

The problem is that testers face tough deadlines and projects have increasingly tight budgets.

With more experience and a few tricks up their sleeves, testers could reduce the time they require to do their jobs, save the project a good deal of cash and re-ingratiate themselves with IT management. Proper testing, conducted appropriately, can save them a lot of time and money later in the project. Like software development, software testing hinges on people, process and technology. People must have a combination of knowledge, skills and behaviour. Knowledge is gained through textbooks and other reading matter, training and peer groups. Skill develops from trying out what they have read, but behaviour comes from doing it time and again, consistently, without error.

With more experience and a few tricks up their sleeves, testers could reduce the time they require to do their jobs, save the project a good deal of cash and re-ingratiate themselves with IT management.

Walter Kruse is a software testing consultant at IndigoCube

There are multiple processes for testing software. Multiple methodologies. One is defined in Bret Pettichord's paper: Four Schools of Software Testing. It gives an overview of the different approaches to testing. Testers are often stuck in one of the schools of thought and do not have perspective outside that school. The four schools have become five in a republished version of the paper. They are:

* Analytic school: Based in academia, this school believes testing is scientific and mathematical. Often seen in testing of mission-critical software.
* Standard school: Measures progress. Plans costs and desires repeatable execution of effort (software assembly-line). Management is critical. Encourages standards, best practices and tester certification.
* Quality school: Emphasis on process and discipline. Police developers; protect users from bad code, gatekeepers.
* Agile school: Use testing as proof of completed deliverables. Early test automation, most often Unit tests and Test Driven Development.
* Context-driven school: Emphasis on people. Testing is multidisciplinary. Any creative process that finds a bug has value.

That is just a brief excerpt from the paper. It illustrates the concept, and it is up to testers and test managers to decide which school is right for them.

Those processes need to be applied in context to organisations and they must decide what works best for them. And testers must never forget to continuously improve their processes.

The better the process, and the more appropriate, the sooner in the development and feedback cycles that projects will pick up and be able to correct errors. That has a direct bearing on the cost associated with software development projects.

There is an ever-increasing divide between technical and non-technical testers. Just as a tester can broaden his understanding of testing by understanding the four schools, a tester should learn a bit of tech. The value in that is enormous. A tester will have more credibility with his technical counterparts, and can assume less of a supplicant's role.

A tester can find really intricate bugs, and a tester can probably find ways to do things faster and more effectively with some form of scripting. However, testers have much to learn when it comes to technology. Too often testers don't understand the coding environment developers have employed. Not knowing the type of code rules out a fair percentage of methods and processes that testers can employ.

Testers should continually strive to understand the code that developers employ, and write themselves a box of tools they can re-use as they progress from one project or phase to the next. Simple programs can save testers a great deal of time and once written, their cost is amortised across any number of projects.

Of course, not all testers are interested in technical matters, and that portion represents the other side of the divide. Those testers must become much closer aligned to business, and the ability to understand the business' needs better makes that tester a better asset to the business.

* Bibliography and references:
Four Schools of Testing - Bret Pettichord -