It’s amazing how one person’s interpretation of a bug can differ so much from another person’s interpretation of the same defect. It’s all down to perspective. Of not only all of the individual people involved, but also from the testing objective point of view and also the business point of view.
I was recently performing a regression test of a web app system which was undergoing an upgrade in the oracle database from 10G to 11G. I found a bug where clicking on a button caused the system to throw an application error message which informed the user to contact customer support.
So off I went to log the bug. I set the bug severity to critical – the functionality is completely broken and the user does not even see a suitable error message. I was astounded to find that the developer tasked with fixing the bug had downgraded it to be “Minor”!!
As I was getting prepared to offload a rant about why I felt the bug should be a high priority to be fixed, but the developer quickly got in there first with the fact that this bug was not introduced from the 11G upgrade but in fact, it had previously existed on the 10G build.
As I obtained this information, I pondered on the developers perspective – “as this bug is not related to the 11G changes made, then it is not of a high priority to fix for the 11G release to take place”. It kind of makes sense… from that perspective!
I then challenged him that from the system perspective, it’s still a critical bug. The functionality is not working at all, therefore from the perspective of an operational system, it’s not doing what it’s supposed to do and the functionality of this button is required to perform an important function, therefore it’s of critical priority.
The developer looked to be conceding the point, but then pointed out that from the user’s perspective – “the function can’t be that important as the 10G system had been operating on the live environment for a few months now and the users have never reported the problem to the customer support team”.
This got me thinking about the different influences that various perspectives can have on our judgement. The moral of the story: It’s important to try to think conceptually about each different angle that a bug can be viewed from, before making a snap judgement on the criticality of it.
Dan Ashby 
So what was the outcome ? Did the bug get fixed ? What was it’s final status ?
You cant leave the readers hanging like this
Situations like this get even more fun when the project has strict exit/entrance criteria which end up with huge arguments about the status of a bug so that the project can move onto the next stage. An evil tester can mess with a project managers head by raising a severe bug ( it crashes the system ) with a very low priority status ( the situation it happens is so obscure it’s totally unlikely to happen outside a test lab )
LikeLike
Thats the exact way that this defect has turned out!
It has a high severity, but a low priority. The project manager took the same view as the developer – that the release to implement the 11G database was able to go ahead due to the bug being having previously existing and gone unnoticed on the 10G.
As of yet, the issue not been resolved, but hopefully it will be scoped into the next maintenance release – before the users do eventually click on the button and see the big red X!
LikeLike
At CAST, @can_test mentioned a similar scenario, except the bug had been in the system for 5 years. He took the opposite view, take the feature out. Bug happened pretty much as soon as the item was selected, hadn’t been noticed in 5 years, can’t be anybody using it, take it out.
I agree with the developer, doesn’t seem important, stick it on the back log. There are more important things to be focusing on.
LikeLike
Thanks for the mention, Tony. Yes, I agree.
Risks have two elements: (1) an undesirable event, and (2) a probability of occurrence. As testers we sometimes get excited about the first part and skip the second part. When these two elements are both high or both low, it is generally easy to know what to do with the bug report. When they are _both_ high and low, it is a bit trickier – i.e. a critical bug with zero/low probability of happening, or a low bug that is very likely to happen or be seen.
Gojko Adzic has a great presentation on Redefining Software Quality and you can read up on it in his blog post: http://gojko.net/2012/05/08/redefining-software-quality/ – I like the additions of ‘useful’ and ‘successful’ to the top of the Quality pyramid. How many of us know if the features we publish are actually used? How could you find out? What evidence is there that a feature is used?
How many of us have the courage to remove or hide features that customers don’t use? It might be easier to hide/disable an option than fix it in some cases. A mature team with a rapid development processes might fix it without question. Many teams have choices to make.
As testers we provide good information, and it seems to me that you have done a good job and raised awareness of this risk. The delivery of this fix is a business decision now.
LikeLike
Good post Dan!
I guess most of the times, the delivery dates are so tight that atleast the tester has no extra time to think about other “perspectives” 🙂 what most testers end up doing is increase the bug count 🙂 (ofcourse the high sev ones matter a lot to their profile!!)
Jokes apart, It would be so helpful for the devs, managers if we as testers would just give the bugs we log another thought or quick review before logging. It would save so much time, and relieve tensions seeing a critical bug just before the release :p
LikeLike
Hi Amibika! Thanks!
Thats a good point about tight timescales…
I’ve tried to get round this when giving testing time estimates by splitting my time into 3 categories:
1) Planning and preperation time (planning the testing and setting up environments, test data, etc),
2) Performing testing time (the time that it will take to actually perform the testing), and
3) bug logging and investigation time (people tend to forget this, bug logging bugs and investigating bugs further can actually take up alot of time).
I always make sure that the “bug logging and investigation” estimates are given, as this is the extra time that now allows me to think about teh bug from other angles and perpectives.
And I definitely agree: It does saves time in the long run and relieves the tension on the build up of teh product release! 🙂
LikeLike
Yea, thats valid.. Its also a fact that we cannot correctly estimate the bug logging and investigation time. But, yes, some extra time will definitely be a bonus!
LikeLike