The lot of the Tester is not always a comfortable one. The ideal Tester is a pedant, meticulous beyond the point of being thorough. Not simply looking out for errors and inconsistencies, but wanting to find them, and wanting to make them happen again once they are discovered. The product of his labour is never happily received, it is, by its nature, rude, snobbish, critical of the efforts of others. The Tester is rarely required to give a report of what works well, instead, he is tasked with producing a list of what fails, what falls over, what looks rubbish, what is difficult to use.

The essence of reporting a bug is to communicate how it happened to a developer so that they can make the necessary changes to the code, so that it does not occur. The developer must be able to follow the process described in the bug and replicate undesired behaviour that the Tester originally discovered, so as to identify the elements that will need to be recoded. Tester and Developer may not be working physically side by side, so it is essential that the individual bug contains all the necessary information to recreate the bug. The Tester must ensure that the current state of all variable conditions are detailed when the bug is described.

“Well its not happening any more”

The Developer’s nightmare, and what should also be the Tester’s nightmare, is to go about implementing a bug fix, only to find that the bug that has been reported does not happen. The Developer can justifiably assume that this is due to a range of causes:

  • The Tester got it wrong – got confused as to his precise location within the system, as to which button he clicked, basically messed up the bug report.
  • Environmental issue – The bug is found on a parallel system set up for testing purposes. The Tester identified a valid issue, but the cause of the problem is not present on the development environment, and the Developer can not distinguish between an Environmental issue and the first cause.
  • The Tester has not made all the details of the bug explicit. An incomplete description of the conditions under which the bug occurred leaves the developer unable to replicate the error.

In all these situations, the Developer can send the bug back to the Tester and demand that it be reviewed. It is not the Developer’s responsibility to try to second guess the Tester, to try and infer what the Tester actually did to cause the fault. So the Tester should not be offended to find that a bug has been returned to him along with a note saying that this bug is not happening.

So what can the Tester do to avoid this faux-pas? The first problem is circumnavigated by pure, old-fashioned pedantry. He must apply the nit-picking, meticulous attention to detail that made him a software tester in the first place. Any bug found should be repeated to ensure that it is not a temporary or sporadic fault. Any error found should investigated further to identify other ways of causing similar failures. And finally, it is essential that the Tester re-reads the bug he reports to make a basic check that it makes sense.

Avoiding the second issue is a little more complex. The Tester needs to have an understanding of the Environment on which he is Testing. Testing is often carried out on a parallel environment for reasons of expediency, bureaucracy and generally keeping out of the Developer’s way. The Tester should be aware of the Environment on which he is testing, that he is perhaps using sample data that does not match that used by the Developer, that perhaps the specs of his local machine, or his default browser do not match that used by the Developer. The key here is somewhat Machiavellian, providing caveats and get-out clauses for when the bug is returned to them; pre-empting the Developer’s inability to replicate an issue, the Tester is, in effect, giving reasons why the bug may not occur for the Developer and covering themselves for when it doesn’t.

The application of these two skills will enable the Tester to avoid the third cause of the Developer’s inability to replicate. A bug may occur on the click of a particular button, but the lead up to this click can never be assumed. The Tester is at fault if he fails to provide all the variable conditions that lead up to the system failure. Any instance of an error will throw up several: ‘But what if…?’ questions that ideally are fully investigated. But if time constraints do not allow this, then it is just as important to detail what conditions were not applied to the faulty element, thus providing the afore mentioned get-out clauses. Detailing the Environment in which the bug was found is essential, providing the Developer with any details of the platform on which the bug was found will always be useful, however irrelevant they seem to the Tester. Testers are human and are liable to produce erroneous data. Parallel Testing Environments are just that, distinct Environments that are subject to unnoticed idiosyncrasies that can lead to inconsistent behaviour. But explicitly and comprehensively spelling out the precise conditions under which a bug is found is the key method for enabling Developers to concentrate their efforts on fixing bugs as they arise.

The final attribute required by the Tester is one of humility; an understanding that the cause of delivering quality software is a common goal of both the Tester and the Developer. Reporting bugs is inherently about constructive criticism, and not about pointing a finger of blame. Bugs will always be returned to the Tester, whether for clarification, or for retesting. Quality software is reliant on Testing, re-testing, and then testing it again.