Skip to content

Bug Battle is not JUST about finding bugs & reporting them

I have been participated in 3 Bug Battles as of now. Here, I am publishing my experience report of my Q2 Bug Battle that was held for a period starting from May 15th to May 24th of 2010. And also I want to share a good news which is I was awarded Best Bug #1 award for uTest Q2 2010 Bug Battle. Here I go with my experience report.

Results can be viewed here

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. But, most of them do not understand what Bug Battle is about and 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 an uTester. So, Project Managers add them to their list to invite that cool tester to the project(s).

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 uTester & Project Manager both 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 an uTester would have helped Project Manager understand about the Risk by doing analysis of the issue then Project Manager would have stopped the release and asked the development team to fix it as soon as possible as it is a high risk issue which falls under security quality criteria.

So, you might include the following things in your bug report [ The list below is not mandatory but context-dependent ]

  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 many steps then or difficult to write proper steps you might want to consider attaching a video report which would be easy for reader to understand ]

Winning Best Bug strategy

I think about how do I win Best Bug award? How different bug it would be from other uTesters? Without having this thinking 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 bug which they would have reported. I attack the depth of that bug and I find a BIG bug which was hiding under the small bug safely. 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 assess 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 few questions to yourself that why you should be 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 ( Awaiting results ) in Q2 Bug Battle, 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

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

  1. Feedback are 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 next time what is your strategy? I hope you would like to share your strategies of Bug Battle through your blog or uTest forums or through uTest blog post. Thanks for your time in reading this blog post which I assume that it would help you to rock in next Bug Battle.

SanthoshTuppad

I have been as a software tester for over 5 years. I am a hands-on tester and I've been winning bug battles & testing competitions across the world. I am a testing enthusiast, who conducts free workshops on security testing across India (Covered locations: Bengaluru, Pune, Hyderabad & Chennai. Invite him to come to your location), and monthly meets for testers in Bengaluru. I am also an avid testing blogger.

My interests include traveling, driving my SUV, health & fitness and many others. I mentor budding entrepreneurs, testers, teams in any profession.

Latest posts by SanthoshTuppad (see all)

Share/Bookmark

13 Comments

  1. Congrats for “Best Bug” Award I see there!

    Saturday, June 19, 2010 at 1:20 pm | Permalink
  2. Selim Mia wrote:

    @Santhosh,
    Congratz for your great achievement. And thanks for sharing your experiences with us.

    -Selim

    Sunday, June 20, 2010 at 7:34 am | Permalink
  3. @Selim Mia,
    Thank you for your comments :)

    @Eusebiu Blindu,
    Thank you.

    Sunday, June 20, 2010 at 9:19 am | Permalink
  4. Mohit wrote:

    Hi Santhosh,

    Congrats and keep it up :) and thanks for sharing your bug battle experience with us.

    With Regards
    Mohit Verma

    Sunday, June 20, 2010 at 8:42 pm | Permalink
  5. @Santhosh,

    Great post ! I really learned a lot and can now have a idea about how to proceed in a Bug Battle.

    Thanks a lot and again congrats. Good luck for next feedback contest. :)

    Regards
    Ashik

    Sunday, June 20, 2010 at 9:24 pm | Permalink
  6. @Mohit,
    Thank you :)

    @Ashik,
    Good luck to you and thanks :)

    Monday, June 21, 2010 at 12:45 am | Permalink
  7. Parasuram wrote:

    Santhosh,

    Congrats on winning :), ‘Winning Best Bug strategy’ explanation was good. Bug Reporting was good to understand to all the levels.

    Regards
    Parasuram

    Monday, June 21, 2010 at 5:53 am | Permalink
  8. Peter Shih wrote:

    Congrats again, Santhosh. If I may add a few words here to highlight another key difference between your bugs and the majority of bugs submitted:

    You don’t simply scratch the surface of a bug; you perform an investigation to get to the root of every high-impact defect. Upon successful investigation (zooming in), you are able to wrap things up (zooming out) by providing clear evidence and understanding of the defect: impact to stakeholders, clear writing (although I would suggest more concise bug reports going forward), and relevant attachments.

    You’ve got a great mindset applied to software testing. IMO, it’s the approach you utilize as opposed to the artifacts that makes you stand out. Keep up the great work!

    Monday, June 21, 2010 at 9:05 am | Permalink
  9. @Peter Shih,
    Thanks Peter for your comment and I would concentrate on the point you talked about *concise bug reports*.

    Cheers,
    Santhosh Shivanand Tuppad

    Tuesday, June 22, 2010 at 2:12 am | Permalink
  10. @Parasuram,
    Thank you.

    Tuesday, June 22, 2010 at 2:13 am | Permalink
  11. Awesome post Santosh

    Tuesday, June 29, 2010 at 4:27 am | Permalink
  12. Thanks Nitin.

    Tuesday, June 29, 2010 at 9:42 pm | Permalink
  13. sujatha wrote:

    Congrats santosh .
    Thanks for sharing your experience,it really helps all testers.

    Thursday, March 15, 2012 at 3:17 am | Permalink

One Trackback/Pingback

  1. […] This post was mentioned on Twitter by Santhosh Tuppad, Santhosh Tuppad. Santhosh Tuppad said: Bug Battle is not JUST about finding bugs & reporting them – http://tinyurl.com/23vxpbc – Experience report #utest […]

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*