Quality, enabled testers are essential

What elements contribute to an effective software test cycle? This is a challenging question often asked of test managers.

Each of the elements would generate voluminous write-ups on their own, so for the purpose of this piece, let's just say the goal of an effective test cycle is to identify the most critical defects that render a system unusable for the end-user in the shortest time possible.

The test team that achieves this will be able to minimise the cost of test cycles, without compromising the quality levels agreed with the customer. Testers who can do this are consequently worth their weight in gold.

It is not a simple task to define the elements contributing to an effective test cycle. For instance, Team A may do very well on Project A for Customer A, but achieve less success on a different project for the same customer. In the worst case, they may fail to achieve their mission of identifying the most critical defects that render a system unusable.

In an attempt to reach an understanding of which elements contribute to an effective cycle, I gave a group of experienced testers a list of elements and asked them to rank them in order of importance. The group was also given the freedom to add elements. My list of elements was as follows:

* IT maturity, or CMMI level, of the customer
* Quality of the test team or tester
* Conducting the testing within a defined test process
* Budget and/or time constraints
* Maturity level of the development team involved
* Extent to which the development team builds an application taking testing into account
* Maturity of the development process itself, ie development team at a certain CMMI maturity level

After a fair amount of debate and redefining the list of elements given, the group reached consensus that the most important two points were the quality of the tester and the enablement of the tester.

The best processes, tools or adequate budget are no replacement for the mind of a good tester.

Herman Thiart, Test manager, IBM SA

With proper training and a number of years of experience in the testing discipline, a tester should be able to negate the obstacles normally experienced by testers. In any event, an experienced tester knows the importance of identifying the context of the project. Within the context of the project, the approach the test cycle needs to take can then be defined. It is experience with the full development lifecycle that enables the tester to not only understand the pitfalls and consequences of short-circuiting the disciplines within the development lifecycle, but also to communicate this to the relevant stakeholders.

An experienced tester can typically communicate from the development level to the project management level on the challenges constantly faced by the testers. An experienced tester also understands the threat that developers face when independent people execute their code, which they so carefully worked on, with malice.

In a nutshell, the best processes, tools or adequate budget are no replacement for the mind of a good tester.

Initially the quality of the tester was the only considered fundamental of all elements that contribute to an effective test cycle. After some debate in the group, the conclusion was reached that the enablement of the tester was a prerequisite for an effective test cycle.

The enablement of the tester needs to happen in various forms. A test is enabled when:

* A project team provides adequate budget and timeline to conduct test activities.
* Testing is NOT considered as an afterthought or a buffer zone on the project plan when development overruns the budget.
* Software architects and designers take testability into account during the process of designing applications.
* A suitable environment, apart from development, is created in which to conduct the tests.
* Good quality assurance activities are adhered to before the system is passed to the test team.

There may well be nothing revolutionary about the assertions above. But one thing for certain is that, for effective test cycles, and ultimately better quality software delivered to the customer, quality testers are essential and they need to be enabled.

If these statements are not revolutionary and contain no surprise, then why do we still continually struggle with badly delivered software that causes unexpected behaviour once promoted into a production environment?

We have to be consistent about going back to the basics to avoid making silly mistakes.

In my next Industry Insight, I will explore further underlying difficulties that hinder the quality of the tester and the enablement of the tester.