Investing in software testers

In my last Industry Insight, I discussed the two elements considered most important to enable effective test cycles: the quality of the tester and the enablement of testers.

In this piece, I look at what really makes up the 'quality of the tester' and why 'enabling the tester' is fundamental to creating the best product.

Depending on the context of a project, the test budget for corporate applications can account for between 15% and 30% of the development budget. If the non-conformance or failure cost of the software is very high, then the test budget can become substantially more in the region of between 50% and 90%.

An example of this type of software would be those used in airline systems.

For a discipline that consumes so much of the development budget, it is surprising how often the people involved in software testing are considered the orphans of software delivery.

In a recruitment process last year, one of 80-plus CVs caught my eye: a BSc Computer Science graduate who decided to make the test discipline a career. This was amazing since so little is offered in South African tertiary institutions on this discipline. Graduate students are at best exposed to it for one or two courses. Postgraduate study in software testing is almost unheard of.

So much time is spent studying how to write software that we completely forget to teach students not only how to test, but also the important role independent system testing plays in reducing the overall non-conformance cost of software.

Software or corporate companies that employ testers often do not identify a dedicated career path for individuals interested in becoming professional testers. Where such career paths exist, salaries are often not in line with the rest of the industry.

Too often, testing becomes a sideline for business analysts, software architects, developers or even project managers. There are, of course, test activities that can and must be performed by skilled individuals in the other disciplines, but this should not be a replacement for someone dedicated to software quality assurance.

These issues need to be resolved to attract quality people to this discipline. Serious education needs to be done at the tertiary and current practitioner level and companies need to start setting career paths for test professionals.

Too often, testing becomes a sideline for business analysts, software architects, developers or even project managers.

Herman Thiart, Test manager, IBM SA

The most common complaint of professional software testers is that they are continually inhibited from unlocking their talents as testers.

Testers can be enabled only if they are not the last consideration when a development budget is compiled. They need to give input into the budget upfront to help assess the potential impact of an application on the end-user. A small development project does not necessarily equate to a small test project.

The authority of a test team is another element that either inhibits or enables a team. One of the most powerful "weapons" that a software vendor can deploy would be to allow an experienced test team to communicate directly and openly with a customer. The team would then be enabled to report with integrity to the customer and the development team on issues or defects that could potentially derail the project.

Testers need to work in enabling environments. It is important for an independent test cycle to at least have an environment separate from the development environment. The difficulty in resolving issues between developers and testers working in the same environment during formal test cycles will always put the effectiveness of a test cycle at risk and is often a first sign of a product that will disappoint the end-user.

One of the most frustrating elements that disenable testers is when test time or test scope is cut in the last stretch of a project.

Projects often go against good practices of software development by cutting test time when a project is under time or budget constraints. It is better to cut functional scope earlier in the cycle rather than test scope at the end of a cycle. Have we not experienced too many times that the total failure cost of badly delivered software almost always outweighs the cost of testing it?

I refer to this tactic of cutting testing time as the "dinner-plate syndrome". A balanced diet must contain carbohydrates, proteins, fats, vitamins, mineral salts and fibre. It must also contain these elements in the correct proportions. Similarly, a balanced software project must contain the correct proportions of requirement management, analysis and design, testing, deployment, configuration management, environment management and project management.

Ignoring, or eliminating the elements we don't like or consider unimportant, will result in malnutrition that will ultimately yield a sick project or product. When we are under financial or time constraints, we should cut back a little on each of these elements and not just cut back completely on one. Doing this could jeopardise a test cycle and remove an important element that is needed to ensure a strong, healthy project or product.

In my next Industry Insight, I would like to explore the metaphor of the "dinner-plate syndrome".