Software Testing Bug Life Cycle

To gratify the customer or client’s demand; one must perform complete software testing activities on the application before the deployment as its stated that “No Software Exists Without a BUG”; while performing those actions if any ambiguity found then the tester should report the bug and notify the developer.

Elimination of bug from the software needs to follow the proper steps formerly known as BUG LIFE CYCLE; the structure of it varies from organization to organization but the basic flow will remain the same. Every organization use different tools or software to report the bug.

software_testing_BugCycle

software_testing_BugCycle

1.1 Cataloguing new bug:

Following are the important things that should be kept in mind while reporting the bug

  1. Bug description should have the STR (Steps to reproduce) which should be specific and clear so that developer can easily understand. For ease in making understanding to the developer, tester can upload screen shot and mark the bug by the red color font so that it is clearly be visible immediately.
  2. Expected Result should be clearly visible
  3. Bug Priority should be correctly set (See description on 1.3)
  4. Bug Severity should be correctly set(See description on 1.4)
  5. Build No should be set accordingly (See description on 1.5)
  6. Bug should be assigned to the concerned person who is in charge of solving the bug(See description on 1.6)

1.2 Bug Life Cycle and Description:

  1. New: Default status of the bug should be as NEW.
  2. Checked In: As soon as the developer understood and resolved the bug; he will changed the NEW status as CHECKED IN before releasing the build.
  3. In Progress : Developer may change the status to IN PROGRESS if bug needs to be resolved in many days
  4. Fixed It Later: Usually Low Priority bugs marked as FIXED IT LATER by the developer
  5. Not a Bug: If lead/verifier/ developer consider the bug as Not a Bug then he may mark and change the status also providing healthy comments against it.
  6. Re-Opened: If bug still exists or QA not satisfied with the solution in the new build then tester should open the bug again by selecting the status as RE-OPENED.
  7. Closed: If bug is successfully resolved and verified by the tester then it status should be marked as CLOSED.
  8. Suggestion: Tester should has the enough knowledge about the quality principles and if he found any lack in the requirement or testing phase than he can report the SUGGESTION to make the application more efficient

Note: Status options can be changed according to the tools for the different organizations

1.3 Bug Priority:

Setting bug priorities is essential because magnitude of a bug impact on the company’s business

  1. P1- Critical:  All critical level bugs should be reported under this category; these include business logic, performance issues or if site is dead etc.
  2. P2 – Major: Major level bugs should be reported under this category; these includes too much delay in loading the page etc
  3. P3 –Moderate:  Moderate or average level of bugs that are bearable should be reported under this category; these include verification of TO and FROM date as TO date cannot be less than FROM date; Buttons not performing the functionality etc.
  4. P4 –Low: Cosmetic or Low level of bugs should be reported under this category; Problems with layout or the bugs that wont effect the performance should be included here.

1.4 Bug Severity:

Setting bug severity is essential because magnitude of a bug impact on the software.

  1. Blocker – When testing procedure is halted due to some issue
  2. Application Crash – When performing QA Activities and suddenly any page got crashed due to large input, entering invalid data in the field, or due to connectivity or integration issues
  3. Major- when bug severity is Major
  4. Minor - When bug severity is Minor
  5. Trivial - When bug severity is very low; mostly incase of GUI (Graphic User Interface) issues
  6. Enhancement –  When any bug is reported just to enrich the application

1.5 Build No:

It is the unique identifier which shows that how many versions of the software has been release for the testing; when any major change is implemented then the developer will change the value to 2.0 prior it was 1.9 say, but if any minor change is implemented then build No should be as 1.10.

1.6 Assigned To:

Tester should select the name of the person who is the current owner of the bug

One thought on “Software Testing Bug Life Cycle

  1. Jane Forrington

    “No software exists without a bug”. Not only that when you start testing and have given it a complete run over, and remove any bugs, in the second testing there will be new bugs.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>