Thursday, April 9, 2009

What is Bug Life Cycle?


          Bug Life Cycle?


     New: when tester reports a defect


                                       Open: when developer accepts that it is a bug

                                       Fixed: when developers make the changes to the code to resolve to rectify the bug

                              Closed/Reopen: If the bug is fixed and expected result shown up, it is turned  into“Closed” and if the problem resists again, it’s “Reopen


There are three different life cycles that a bug can passes through:

Cycle I:


1) A tester finds a bug and reports it in test management tool.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is invalid and is marked with a status of ‘Pending Reject’ before passing it back to the testing team.
5) After getting a satisfactory reply from the development side, the test leader marks the bug as ‘Rejected’.

 Cycle II:


1) A tester finds a bug and reports it in test management tool.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and it is working fine, so the tester closes the bug and marks it as ‘Closed’.


 Cycle III:


1) A tester finds a bug and reports it in test management tool.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and the same problem persists, so the tester after confirmation from test leader reopens the bug and marks it with ‘Reopen’ status. And the bug is passed back to the development team for fixing.


This way, any bug that is found ends up with a status of Closed, Rejected, Deferred or Postponed.


What is deferred status in defect life cycle?
Deferred status means the developer accepted the bus, but it is scheduled to rectify in the next build

What tools are used in Manual testing for bug tracking and reporting?
For bug tracking and reporting there are many tools like
Testing the application whether it’s performing its basic functionality properly or not, so that the test team can go ahead with the application.

Rational clear quest.
PVCS
Bugzilla


In Testing 10 cases you found 20 bugs then how will you know which bug is for which test case?
Each Bug Will Have a Unique Bug-ID which would be related to that particular Test Case. We also make use of the Matrix to keep track of bugs and test cases.

What is mean by test suite?
Test suit is “set of test cases”
Group of test cases is nothing but functional (+ve & -ve) and GUI.


What the Nature of Software Defects?
Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. General processing tends to be well understood while special case processing tends to be prone to errors.
We often believe that a logical path is not likely to be executed when it may be executed on a regular basis. Our unconscious assumptions about control flow and data lead to design errors that can only be detected by path testing.
Typographical errors are random.


How to write a good bug report? Tips and Tricks?
If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it.
1) Reproducible:
If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix. 
2) Be Specific:
Do not write a essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.
Use following simple Bug report template:
This is a simple bug report format:
Reporter: Your name and email address.
Product: In which product you found this bug.
Version: The product version if any.
Component: These are the major sub modules of the product.
Platform: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.
Operating system: Mention all operating systems where you found the bug, like Windows xp, Linux, Unix...
Priority:
When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as ” Fix when time permits”.
Severity:
This describes the impact of the bug.
Types of Severity:
  • Blocker: No further testing work can be done.
  • Critical: Application crash, Loss of data.
  • Major: Major loss of function.
  • Minor: minor loss of function.
  • Trivial: Some UI enhancements.
  • Enhancement: Request for new feature or some enhancement in existing one.
Status:
When you are logging the bug in any bug tracking system then by default the bug status is ‘New’.
Assign To:
If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. 
Summary:
A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.
Description:
A detailed description of bug. Use following fields for description field:
  • Reproduce steps: Clearly mention the steps to reproduce the bug.
  • Expected result: How application should behave on above mentioned steps.
  • Actual result: What is the actual result on running above steps i.e. the bug behavior. 
These are the important steps in bug report.

Helping:
http://www.guru99.com/software-testing.html

Home page: 
http://testerjob.blogspot.com/


 

4 comments:

  1. reopen - I think we can explain it in a more detailed manner. What u have explained here is "Reject". If the expected result shows up, it moves to close status. If not, it moves to Reject status. And when the issue is closed, and if it appears again in some other scenario/ situation, then it is called as "reopen".
    I will go through the complete blog and will upload my comments/ suggestions.

    ReplyDelete
  2. I was looking for answers to Bug Life Cycle and I did get some but down the post you started talking about smoke testing, white box testing etc and I was confused. Anyways, do keep writing.

    ReplyDelete
  3. Hi vennila,
    The Concept differs from concern to concern. It is more common that, in re-test process if the bug still preceding, then the tester shall move it to the re-open status for the developers to correct the code again, so that they will fix the same. Otherwise it shall be Closed.

    If the same issue appears in some other scenarios, we can add the comment or raise as a new bug as per the application module.

    Note: Testers can raise many bugs for one scenarios, not one bug for many scenarios.


    Thanks,
    Bob

    ReplyDelete