Here I am not going to write a marketing article about how to sell a Bug (General term for any insect or similar creeping or crawling invertebrate)! So people who expected such an article please excuse me. Rather I am going to write something about a Software Bug. These are few ways in which people describe a Software Bug.
1. “A bug is a fault or defect in a system or machine” – Anonymous
2. “A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result)” – Wikipedia
3. “A bug is something that bugs somebody” – James Bach
I come across many testers who complain that even though they are able to catch a handsome number of bugs, still most of those bugs are not fixed by their developers. The few bugs, which are fixed, are fixed so late that by that time the testers get frustrated about the delay and tend to forget about the bug. Sounds like “Fixing delayed is Fixing denied”. Isn’t it?
This particular problem has got many interesting dimensions. I do not believe that it’s the job of the tester to get his bug fixed! After all we are not quality police. I think a tester’s duty is to report the problems with a piece of software. To get them corrected/fixed should be the duty of the management. But again, we (testers) are human beings and we have emotions. So it does hurt when we see the bugs reported by us are not taken seriously. Or the bugs start to stink in the bug tracker waiting for a fix. Or worst, the priorities of our bugs are changed from high to low and are dumped for later consideration.
I personally feel that a good tester should be equally good at selling his Bug! When I am talking about “selling his bug” you might argue that “how a bug could belong to a tester”. After all it’s the developer who introduced the bug into the software. So the bug should belong to the developer. Hmm yes. But as you have found/discovered the bug so now it belongs to you too. And the better you are at selling your bug to the developer; chances are more that it would be taken seriously.
Developers work under difficult time constraints. Most of the times, they have to deal with the pressure of unrealistic schedules, scary iteration plans, pressure of deadlines and of course the pile of bug reports submitted by testers. In such situations, if your bug reports were not enticing enough to drag his attention, then he would probably prefer to take another look at it after a while. And here begins the problem. As the developer is already in short supply of time, so you have to sell your bug to him if you want him to spend time to fix your bug. And your bug report should be good enough to work as a sales advertisement of your bug.
Creating a bug report is not only about writing preconditions/prerequisites, steps to reproduce, severity, priority etc. Your bug report should have some special qualities to attract the bug fixer! According to me, these are some important points that can make your bug report stand out in the crowd:
1. The bug report should be with clear and concise steps so as to reproduce the failure. If the developer is not able to reproduce the bug, then he can’t do much about it. So try to make it as simple and as straight forward as possible. Try to describe the bug in minimum number of steps. As a rule of thumb, if your 10-year-old cousin is able to reproduce the bug after following your bug report, then it’s a well-written bug report.
1. “A bug is a fault or defect in a system or machine” – Anonymous
2. “A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result)” – Wikipedia
3. “A bug is something that bugs somebody” – James Bach
I come across many testers who complain that even though they are able to catch a handsome number of bugs, still most of those bugs are not fixed by their developers. The few bugs, which are fixed, are fixed so late that by that time the testers get frustrated about the delay and tend to forget about the bug. Sounds like “Fixing delayed is Fixing denied”. Isn’t it?
This particular problem has got many interesting dimensions. I do not believe that it’s the job of the tester to get his bug fixed! After all we are not quality police. I think a tester’s duty is to report the problems with a piece of software. To get them corrected/fixed should be the duty of the management. But again, we (testers) are human beings and we have emotions. So it does hurt when we see the bugs reported by us are not taken seriously. Or the bugs start to stink in the bug tracker waiting for a fix. Or worst, the priorities of our bugs are changed from high to low and are dumped for later consideration.
The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed. – Cem Kaner
I personally feel that a good tester should be equally good at selling his Bug! When I am talking about “selling his bug” you might argue that “how a bug could belong to a tester”. After all it’s the developer who introduced the bug into the software. So the bug should belong to the developer. Hmm yes. But as you have found/discovered the bug so now it belongs to you too. And the better you are at selling your bug to the developer; chances are more that it would be taken seriously.
Developers work under difficult time constraints. Most of the times, they have to deal with the pressure of unrealistic schedules, scary iteration plans, pressure of deadlines and of course the pile of bug reports submitted by testers. In such situations, if your bug reports were not enticing enough to drag his attention, then he would probably prefer to take another look at it after a while. And here begins the problem. As the developer is already in short supply of time, so you have to sell your bug to him if you want him to spend time to fix your bug. And your bug report should be good enough to work as a sales advertisement of your bug.
Creating a bug report is not only about writing preconditions/prerequisites, steps to reproduce, severity, priority etc. Your bug report should have some special qualities to attract the bug fixer! According to me, these are some important points that can make your bug report stand out in the crowd:
1. The bug report should be with clear and concise steps so as to reproduce the failure. If the developer is not able to reproduce the bug, then he can’t do much about it. So try to make it as simple and as straight forward as possible. Try to describe the bug in minimum number of steps. As a rule of thumb, if your 10-year-old cousin is able to reproduce the bug after following your bug report, then it’s a well-written bug report.
2. The bug report should be realistic. If it’s about a bug that has 0.001% chance of being hit by an end user (corner cases), then probably the developer won’t be much interested to fix it quickly.
3. Try to include all the required setups, sample test files needed to reproduce the bug in your bug report (especially if the bug is configuration dependent).
4. Try to get to the root of the problem (here is where your Hours of testing experience may come in handy). Sometimes a single bug may have multiple symptoms. Try to find out the most severe symptom (data corruptions, system crashes, application hangs etc) and mention this in your bug report.
5. The bug report should be tempting enough to grab the bug fixer’s attention.
[Note: When I say, “It should be tempting enough”, I am not encouraging you to exaggerate your bug report. Exaggerating bug reports are almost always devastating for your credibility as a tester. Rather the bug report should be written in a way that best describes its importance and provides sufficient correct data about the possible repercussions of the bug.]
6. Your bug report should also tell how the bug might affect lots of people, how a similar bug had caused lot of distress in past, how a similar bug had caused a competitor to suffer. If you are sure that fixing this bug should be trivially easy, then mention that in your bug report too.
A well-written bug report serves as a sales advertisement for the bug. If you are good at creating an eye-catching sales advertisement, chances are more that you will be more successful at marketing your product (here you are trying to sell your “bug” to the developer). So try to create killer bug reports that have potential to be sold like hot cakes. Once you are successful in this, you will see more of your bugs getting fixed quickly than before.
Happy Testing …
Nice Post Debasis.
ReplyDeleteBut then,
1. It's not the Developer who take's a decision on weather an issue to be fixed / or not for the release. Give him the info needed
2. Capture the mission & user story around the Bug and not just steps to reproduce
3. Escalate this with the info on the Benifits offered over the application & it's integration with other features.
@ Venkat,
ReplyDeleteThanks Venkat for leaving your valuable comment on the post.
I do agree with you that it's not always the developer who takes the decision on whether to FIX a bug or not.
But in most cases, it's the developer who takes a look at your bug report for the first time. So writing an enticing bug report may result in a quicker response from the developer. [Because he is the one who is finally going to FIX your bug]
Moreover, this post is intended to point out the importance of a bug report in deciding the fate of the bug. If your bug report is well-written there is every possibilty that it may influence the person taking a decision on whether to FIX it or not.
Thanks again for your comment.
Regards,
-Debasis
Hi Debasis,
ReplyDeleteI am very much impressed by your blog "how to get started in testing". It's one of my favourites..
-Hima.
hi Debasis,
ReplyDeleteWhich definitions & methods should I follow in S/W Testing concepts? Everyone i know explains their own definition, the books i read also shows it's own definition...i'm confused a lott...
-Hima.
@ Hima,
ReplyDeleteAs far as definitions and terminologies goes, it's very hard to get a generalised definition for any particular term in testing. If you ask me, my definition for a particular term changes/evolves as my knowledge in a particular area of testing evolves. While dealing with others, it would be a safe approach to ask their definition of a term before giving your own definition. Otherwise that might create confusion.
Coming to methods of software testing, there is no readymade method that could be applied directly to a testing project. The methods may vary depending on the context and situation you are dealing with in your particular case. Remember! The value of any method depends on the context.
So next time, you come across some confusing definitions or methods, try to evaluate it and follow the ones that you think might help you in your context!
Regards,
Debasis.
Hi Debasis
ReplyDeleteAbout p.2 "the bug should be realistic"; What about suggestions from tester to improve functionality of application?
Personaly I hate , when i must find things which i need to enter, hidden in some odd place of developed app, i submit feature/tweak to move those to more handy place, and get answer "Yes, it's good idea, but User don't demand that. Post acknowledged/wont fix"
Hi Debasis,
ReplyDeleteI am a testing engineer in a software company.
The testing terms and the explanations you have mentioned in 'How To Sell a bug' were really very much understandable.
Well, at present am only a mannual tester.I want to learn some automation tools which is on demand now and also will be of demand in future.
Can you please recommend?
And is there any future for a mannual tester?
Sneha
@ Sneha,
ReplyDeleteThanks for leaving your comment. Before I could answer your questions, I am not sure if you have gone through these posts:
» Test Automation Traps!
» Programming skills and Testers!
Come back to me after going through these posts and I would be glad to answer your any remaining queries.
As for "Is there any future for a manual tester?", my answer is YES! Assuming that, by manual testing you actually wanted to mean "sapient testing", I don't think that there is no future of it! As I always try to point out, manual (sapient) testing and automation are NOT mutually exclusive, rather they should compliment each other! Context matters...
Happy Testing...
-Debasis
I on ur side,i vote for ur post. a good tester is one who is capabe to persent a crisp an self explanatory bug report.
ReplyDeleteraji
Hi Debasis,
ReplyDeletei am the third person who reads all your blogs after you yourself rajashri
any way the way you present is very professional,
i need to write an article on bug life cycle
which clearly defines the roles of tester , test lead deveoper as it simple describes complete role of Tester
Hope you post it soon!!!
Regards
Raj
raj.1402@yahoo.com