Skip to content

Bug reports … beyond the bugs …

November 25, 2014


MARCELLUS: Something is rotten in the state of Denmark.

HORATIO: Heaven will direct it.

MARCELLUS: Nay, let’s follow him.

Hamlet, by William Shakespeare


The dialog about, the powerful exchange of opinions between Marcellus and Horatio at the end of the scene 4 in Hamlet, resumes what testers should be doing right after we encounter a nasty bug. Say it clear and loud “Something is rotten …”, and now, not just describe it, but follow it very tight, nobody else will do it for you … not even Heaven.

I have been watching some youtube videos about bug reports, with the spirit of trying to find information other than that recommended in the study materials; and It has come to my attention that the subject of bug reporting is underrated and  misunderstood. It seems like everyone follows blindly the golden words of the Great Master: RIMGEA.

For those who doesn’t know what RIMGEA stands for, it is just a mnemonic that assists a tester to assure the quality of a bug report, namely: Replicate it, Isolate it, Maximise it, Generalise it, Externalise it … And, say it clearly and dispassionately.

We have to remember that testing is a tough job, exciting and badly paid. You would never make it just as a test engineer, you would need to do some other things on the side, meaning that you need to have extra skills if you want to hold your position in an organisation.

And what makes testing tough is not just the persistency of the hunting for bugs and the constant suspicion that something will go wrong; but also how you canalise and express the findings. It is not enough knowing that hmmm … something is wrong … we also need  to see what it is and then clearly report it.

RIMGEA is quite a good resource … for the lazy, and just a start point for the tougher. A software development process, where testing is highly regarded, works like a closed-loop control system, where a feedback is used in order to adjust the reference value.  A feedback is to a control system what a bug report is to software development; moreover, a reference value is to a control system what requirement specification is to the whole process of development.

The problem with this analogy to control systems is that these never keep statistics about performance; this is the reason why they are enhanced with, for instance, machine learning capabilities. The same capability is missing from the RIMGEA schema: a routine to search and analyse the bug tracking system.

Nay, let’s follow him. Managers, testers and developers that keep an eye on what is going on in the bug tracking system, would make sure the following happens:

For testers

  • It is indeed a source for testing ideas. Bugs around given functionalities bring about new areas and ideas for testing
  • It gives bug localisation. A bug in an area can be the cause of bugs close to this area. Just look at the statistics, numbers don’t lie.
  • It spots potential spec misunderstandings. Repeated bugs on some functions could be the consequence of overlooking the requirement specification

For developers

  • A well organised report with severities, priorities and status associated, puts developers into perspective concerning the status of the whole project
  • It helps to organise the job for the next sprint or the next week.
  • It somehow tells them “It is gonna be alright” … yet, this is a feeling and can not be explained.

For managers

  • It gives an overview of the advancement of the development
  • It gives an indicator for the quality of the process. A recurring bug on certain functionality would raise a flag
  • It is a source of decision making. A bug tracking system is in fact a database with events organised in time, following some classification; and this could be subjected to complex event analysis for which a plethora of tools exists out there. Here you have business and operational intelligence at their bests.

… and for everyone is a non-disruptive protocol of communication, where boundaries are established and respected.

If we now add BI visualisation techniques, then we can exploit the preemptive mechanism of our brain to discover patterns in large data sets, like those coming from bug reports. And use the finding to convey peace of mind across the team.

So  “Nay, let’s follow him”. Lets follow the pattern, not just a bug …. because something might be rotten in the process.


From → Philosophy

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: