Software Testing Blog

Wondering how you can stand out from the crowd in this quarter’s Bug Battle? Santhosh Tuppad – a “Gold” tester and three-time Bug Battle winner – has some tips to help you claim your share of the prize money, including advice on logging bugs, bug-hunting strategies, submitting positive feedback and more.

For more on Santhosh, read his Tester Spotlight or his recent guest blog post. For more on the current Bug Battle, start here.

*******

I have participated in three uTest Bug Battles so far. In this blog post, I will share with you my experiences from the Q2 competition this past May, and how I was able to win first place. This will include the types of things I concentrated on, my strategy, and how others can give themselves a better chance to succeed in the Bug Battle, as well as in the greater uTest community. Let’s get started!

Different quality criteria bugs

Bug Battles are organized to help uTest understand who is skilled and to whom they can assign more projects or invite to the projects. So, this is a good opportunity for those testers who are new, as well as who are old. Unfortunately, most of them do not understand what the Bug Battle is about – they just understand that “Hunting bugs and reporting them would make them win.”

So, in Bug Battles I report bugs on different quality criteria like:

1. Usability
2. Functionality
3. Severity
4. Performance [ Out of scope for Bug Battle ]

The above list goes on. I do not report 20 usability issues but 20 issues across different quality criteria. By doing this, it gives a good visibility to the Project Managers of uTest and helps them in understanding the credibility of a uTester. So, Project Managers add them to their list to invite these testers to projects.

Bug Reporting

uTester says: I found a bug

Project Manager: What is it?

uTester: There is a ‘Password’ tab after logging in, but there is no current password that is being asked for but only new password to set is being asked for.

Project Manager: Ah, we will fix that in the next release or next version

uTester: Cool

From the above conversation, both the ‘uTester’ and ‘Project Manager’ do not understand the impact of not having “Current password” field in the password tab while changing the password or setting a new password. If a uTester would have helped the Project Manager understand the risk by doing analysis of the issue, then the Project Manager would have stopped the release and asked the development team to fix it as soon as possible, since it is a high risk issue which falls under security quality criteria.

So, you might include the following things in your Bug Battle bug report:

1. Overview
2. Story (this helps in understanding the issue in a better way)
3. Investigation report
4. Impact on end-user
5. Impact on product owner or his / her business
6. Steps to reproduce
7. Expected result
8. Actual result
9. Screenshots
10. Video report (If reproducing the bug will take many steps or is difficult to write properly, you might want to consider attaching a video report which would be easy for reader to understand)

Strategy for Winning Best Bug

How do I win the Best Bug award? How do I find a bug that is more unique than that submitted by other uTesters? Without having this type of mindset, it is hard to get Best Bug award. It’s like traveling in a bus without knowing your destination.

I have a habit of going through other bugs reported by other uTesters. I do this because I get test ideas from the bugs which they would have reported. I attack the depth of that bug and I find a BIG bug which was hiding safely under the small bug. When I say BIG bug what I mean is,

1. Very high risk impact on end-user
2. Money loss involved
3. Threat to product – feature block, server crash, dDoS attack vulnerability, Botnet attack vulnerability and many more things
4. Access to confidential data

Again, the above list goes on. I do analyze the bug reports submitted by other uTesters before I log the bug which would be a nomination for Best Bug award. If the bug is already logged then I see how good the bug report is. If the bug report just has steps to reproduce then I showcase the same bug with detailed information which would help the customer or Project Manager in understanding the risk factor.

Winning Top Tester strategy

19 non-important bugs versus 9 important bugs = 9 important bugs is the winner.

But, you can still report 19 important bugs and be the Top Tester. You might want to ask yourself why you should be the top tester?

1. Have you reported more bugs ( Not crossing 20 ) which are important?
2. Have you followed the guidelines provided in the instructions?
3. Has any other uTester reported more important bugs?

There might be many questions you want to ask yourself before you get into the battle to win Top Tester award.

I reported 18 issues in the Q2 Bug Battle (Best Bug), in Q1 I had reported 16 ( Top Tester ) and in the Q4 2009 I had reported 6 (Honorable Mention) out of 10.

Winning Best Feedback Award

Until now, I haven’t won a best feedback award. However, I suspect that a few points would help you. These points have been consolidated on the experiment I did in the past 3 Bug Battles for Best Feedback award.

1. Feedback is not always negative – they are POSITIVE too. You find bugs on all the products in Bug Battle but doesn’t mean you should critique everything in feedback.
2. Go through the past reports published by uTest and you can find feedback showcased of a winner in PDF document. You can learn something from it.
3. Be honest in answering the multiple choice questions. You might have not tested something or not aware of something. Be honest in choosing appropriate answer. They are not mandatory which would force you to lie

So what is your strategy for the upcoming Bug Battle? I would be happy to read your answers, either in this comments section of this post, or in the uTest Forums. Thanks for taking the time to read this blog post – I hope it helps you to rock in next Bug Battle!