One of the things which most of the Testers (me inclusive, many a times I have also not realized the importance of doing follow-up testing) don’t do when they get an error is - to do follow up testing. This mostly reduces the value of the Bug that you are reporting. The reason is you still have not identified the Bug in its worst form or not investigated the potential of that Bug. This would sometimes make the developers to defer the bug you have reported and the Bug may take its worst form in the field.
If a Tester wants the Bug reported by him to be fixed by the developer , then ensuring that he has investigated the Bug and reporting that Bug in its worst form, goes a long way in getting this done.
I was testing a text field in a web application which was not supposed to accept more than 1000 characters. I generated 1010 chars using PerlClip and pasted on this field. It just accepted 1000 characters and rejected the remaining 10 characters. I again tried appending more characters to the existing 1000 characters by trying to paste more characters, but it was also rejected. So I tried appending by giving keyboard input beyond 1000 characters and to my surprise the characters were getting appended. At this point, I could had logged a Bug saying that I am able to input more than 1000 characters to the text field which is an issue as per requirements. But I decided to do some follow up tests and tried to input as many characters as possible. I found that the field was allowing only 1000 characters to be pasted at a time, but if you give some keyboard input then again you can paste 1000 characters. So using this method I gave inputs of around 3 lakh characters. Then when I did further operation with the application where this data in the field had to be retained across couple of pages, the application initially slowed down when passing this data to the first page and then by the second page the application hung for around for 10mins before recovering.
Here if I had reported the Bug for the first error that I encountered i.e. “the text field accepting more than 1000 characters as input”, the severity of this Bug could not have been captured. But my follow-up test results, where I was able to input around 3 lakh characters to the text field and upon doing further operations the web application getting hanged showed the Bug in a more severe form. So the Bug report for the second case is more likely to catch the attention of the developer and has a better probability of getting fixed. The follow-up tests are sometimes simple and helps Testers in coming up with more credible and persuasive Bug Reports.
5 comments:
Hi Manoj,
I was just thinking how the developers would react to something like this. Though the bug is very severe in nature, the developers would only say 'Hey, this is a corner case. No customer would type in 3 lakh characters anyways'. Its unfortunate that a lot of developers think that customers are stupid and hence they would not use the product/feature in a particular context that gives rise to bugs. Unless, you would provide a strong usecase where customer is going to encounter this bug, the developer will not be convinced to fix this bug.
This said, I strongly agree that follow up testing is very important in uncovering defects that could become showstoppers in the near future of the product.
It takes a lot of practice and experience for the testers to not be emotionally bound to the bugs that have been reported.
Happy Testing,
Pari - http://curioustester.blogspot.com
Good Point Pari. This is exactly where BUG ADVOCY is required. When a Developer gives excuses like the corner case for not fixing the Bug, a Tester should try to figure out and come up with situations in which this Bug if not fixed could hamper the product image or the image of the company.
For example, in the case I mentioned if somebody finds out that there are ways in which my website’s response can be slowed down for certain period of time, and he puts that information on the Net. Now any of my Products competitors can use that information and create a automated program which would be giving such large strings as inputs in every 5-10 min duration. Now that could severely affect business done on my website and could drive users away from my website.
So according to me, if you can add similar Advocacy to your Bug Report then probably the Developers may think of fixing these Bugs and not provide excuses.
-Manoj
Very nice post and a good discussion followed.
I agree when you a bug discovered should be investigated further, but time required for investigation, might eat into testing time. Balancing this is sure a challenge.
-Sharath.B
http://testtotester.blogspot.com/
Hi Sharath,
Welcome to my Blog, buddy.
I do agree with your concern of Bug investigation time eating up your time of Testing the application. BUT here I believe what a Tester should consider, is the Cost Vs Value of time spent on investigation as compared to time spent on testing something else on the application. What is the 'Cost' of not investigating the Bug and not doing a good job of Bug Reporting as compared to the 'Value' of spending some time on investigating the Bug and doing a Good Bug Advocacy thus writing a powerful Bug report.
What do you say?
-Manoj
Hi Manoj, Good one. The comments/discussion was good because a tester need to have good bug advocacy skills. The cost of fixing the bug also matters. Sometimes renaming a file to many characters makes the file unusable. But as the discussion conveyed, developer might argue that "Why one will rename it to so many characters". Before reporting a bug we should see that how can we do bug advocacy.
Post a Comment