Everything about a Bug

What is Software Bug?
software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. 


Picture below depicts the Entire Life Cycle of a Software Bug.







Things to Remember while Reporting a bug?

A bug is typically some kind of glitch, flaw, or error in the code that causes an outcome that is different than what is intended by the software design. This basically just means that something is not working the way it was designed to.

If a bug is found, it should be reported then and there, otherwise it might cause huge loses.

Now, there are things that need to keep in mind while reporting a bug, 

1.Severity
2.Priority
3.Detailed information.
4.Enviroment Used.
5.Release version of Software application.
6.Check out release not to see if it is mentioned as Limitation or not.
7.Work Around if any.
8.Phase in which it is reported.


Severity:
       Severity is nature of the problem,

Severity classes could be:
   
• Critical: defects will cause downstream damage; the scope and impact of the defect is beyond the document under inspection.
• Major, defects could cause a downstream effect (e.g. a fault in a design can result in an error in the implementation).
• Minor, defects are not likely to cause downstream damage (e.g. non-compli ance with the standards and templates).


Priority:
       Priority is Urgeny of fixing a bug.
       It is of four types(P1,P2,P3,P4,) where P1 being high priority and P4 being the lowest.
or it can be High,Medium,Low.
     
Very often you might be asked for an example of High Severity and Low Priority or vice versa.
  
For high Severity and Low priority,
 Assume you are testing a Game application and pressing a particular key 100 times will crash the application sometimes,in this scenario, under ideal conditions User might not press a key 100 times continously without stopping.
In this case severity will be High as the nature of Bug is a crash but priority is low as this is happening sometimes.

For Low Severity and High Priority,
while testing a webpage, you clicked on  “Terms and Conditions” but there is no text to be displayed or may be copyright information is not correct , so in this case your severity will be low as its mere cosmetic bug, since Terms and Conditions  is critical information it has to be fixed at the earliest possible, so high priority.

Detailed Information: 
            Detailed steps to reproduce the bug, Under what conditions its happening,

Environment: 
           If it is tested on Windows,Mac or Solaris or someother OS and other things like Browser used etc..

Release version:
           Release number in which it is found.

Release Notes:
          Some times some bugs are mentioned as Limitation for current release, Tester should check before reporting it as bug.

Work Around:  
          If there is some work around available,incase of show stopper,if yes, that has to be mentioned.

Phase:
         Should mention if it is found in unit test phase or integration test phase or system test phase.







Comments

  1. What should you do when you log a bug that is in violation of an implicit requirement (not mentioned anywhere in the FRD/Usecases etc) but everyone knows it as a universal fact (eg. you can not have more than 29 days in the month of February whether or not it's mentioned in the FRDs or any related documents) and it comes back to you as works as design?

    -Pankaj

    ReplyDelete
  2. Hi Pankaj,

    In this scenario, the bug should be re-assigned to Business Analyst and Root Cause classification can be changed to Requirements.

    ReplyDelete

Post a Comment

Popular Posts