Lessons to be Learned from the Bugs


In this post, I will be looking at Bugs  with an insight that helps testers to learn some new lessons on why the same might have occured. It’s quite common that the testers are  blammed  for  all  the  missed out  bugs  in the system as if they are super natural powers to over see all the issues that are there in the system.

Bugs are there every where. Not just software applications, look at any system for that matter & there are issues wrt End User needs and the same might need to evovle over a period of time with the changing needs / requirements from time to time.

What is a Bug ?

It’s tough to arrive at a generic defintion for the bug & people might have heated discussions on what is a bug & what is not. Mostly it’s based on the context in which people are working. We do come across many bugs in our daily life while working with the tools that are needed for the day to day operations.

So in my context, Bug is something  that’s unable (doesn’t allow me) to satisfy my needs with the system.  What do to do ?

Capture the story around the Bug and not just steps to reproduce. Talk to the reporter and discuss on the scenarios used with the system that lead to the bug.Let’s explore the possible options even though Tester validated the system early

New Test Scenarios for the Testers

  •  We mayn’t even think of that scenario while validating the system. Add the similar test scenarios to the Test Suites

  • The scenario may not be logical (though it seemed to be for testers) for the user though functionally correct. Add to the similar scenarios to Test Suites

  • Might have been a compatability issue with a new environment that doesn’t exist in Test Labs  

Reduce mistakes and improve test teams capability

  •  Might have been missed by a Tester. Check with the tester who performed the Test earlier and find out on why issue missed and the same marked as a pass even though it fails. Might happen through overlook also. Do more analysis here and try to reduce the same.

  • Might be over looked through regression tests. Might have failed and passed in the internal builds and finally breaked in the production system. Analyse the reasons here and improve upon on regression testing.

  • Make it a point to log the bug as soon as they discover the same. People might loose the same from their memory as time goes

Advertisements
Explore posts in the same categories: Bug Tracking, Software Testing, Technical Support, Test Management, Test Strategy, Thinking like a Tester

7 Comments on “Lessons to be Learned from the Bugs”

  1. Mallikarjun Says:

    Good Posting, In fact a good tester’s job is not to just find a bug but also to investigate and find all the similar bugs that may exist elsewhere in the system.

    Mallik,
    Testers need to work towards identifying the Bug Patterns along with bugs and apply the pattern to discover similar bugs in the system.
    Regards,
    Venkat.

  2. Mikey Says:

    I am interested in your definition of a Bug.

    What you have referred to as a Bug, I would probably refer to as a User Issue (I couldn’t think of anything better to call it).

    I would then further sub-divide User Issues into Defects and Enhancement Requests. The difficulty comes when trying to find definitions for these two terms. (Of course, some User Issues show a need for User Education – perhaps a third sub-category).

    The reason I distinguish between Defects and Enhancement Requests is that a system may not be able to satisfy an end user’s needs, but this may simply be because that particular need or requirement was outside the scope of the system.

    One can imagine all User Issues on a sliding scale with Defect at one end and Enhancement Request at the other. Some User Issues are plainly Defects, some User Issues are plainly Enhancements, but in the middle things sometimes get harder to distinguish. If only life was black and white.


  3. Mikey,

    Thanks for the feedback & it’s good.

    When it comes to the definition of Bug, there are plenty around the web towards to define and classify them.

    But when it comes to me, I will treat all the problems faced by the end users in using the product is a concern and we should try to address the same.

    User problems can be classified as Bugs, Improvements, New Features, How Do i do this, Info Request queries.

    But all these classifications are for the people who involved in the development of the product. But for the end user it doesn’t matter. The product need to provide a solution for his / her set of problems.

  4. swapna Says:

    hi

    Thanks for the clear defination of Bug

  5. vinaykumar Says:

    hi
    venkatareddy sir

    i have visited ur blog just now. it will be very useful for freshers and learners.we get some knowledge from ur blog. iam encouraging u to help the learners becoz they dont know about real time. so i request u “add some realtime things like testcases examples,testplan,example of tracibility matrix etc” it will make that more members visit ur site.

    thanks
    vinay
    vinay_nellore@yahoo.co.in

  6. dillibabu.j Says:

    hi i got a clear idea about bugs at its effect with related to application but i need more bug’s type which will be appeard in realtime testing so please clear it for me.

  7. Gaurav Sinha Says:

    Hi Venkat,

    I gone through you blog and really find it very useful in terms of understanding of Bugs and related concepts.

    I would like to know something about the Risk and Configuration Management and the role of these terms in Software Testing.

    Thanks,
    Gaurav


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: