What do we do when we get a bug in an application first? Explain it with the help of an example of Bug Life Cycle.

  • Interview Candidate
  • 16
  • 3834

Showing Answers 1 - 16 of 16 Answers

Dileep Kumar.G

  • Dec 21st, 2006
 

Hi Anupam,

When we found a bug while testing, We need to clarify whether it is bug or not? If u think that's a bug then we have to log the bug if u r using any bug tracking tool. If u r not using any bug tracking tool, U have to prepare the bug report in an excel sheet. Assume that u don't have any bug tracking tool.

We have to give a unique bug id to that bug. Give title of the bug then Description, Steps to reproduce, Expected Result, Actual Result, Priority, Severity, Build no., Test case id and Date, found by.

If u have bug tracking tool u'll find all these fields in that, u simply enter all these in those fields and automatically bug id will be generated.

When we log or enter a bug that should be in Active or New status. When it gets assigned to developer, he'll fix the bug and he'll change the status to fixed or resolved, After that u have to check or Verify the bug on the new build. If u didn't find any the same bug in the latest build u just close the bug. Otherwise u have to Reopen the bug. In this way bug life cycle goes on.

Cheers

Chaitanya.P

  • Dec 27th, 2006
 

After confirming it as a Bug, You have to post it in bug tracking tool. Then the status of the Bug will be "New". Your team lead or any senior person will review it and if it is really a bug, then he will change the status to "Open". If he confirms that it is not a bug, he will close the bug and change the status to "Closed".

All the Open status bugs will be mailed to the development team. Their team lead will assign the bugs to the corresponding developer. He will change the status to "Assign" and add the corresponding developer name. When the developer fixes that bug, he changes the bug status to "Test".

If the development team lead confirms that this is not a bug, then he rejects that bug with valid reasons. Then the status of that bug will be "Rejected".

If he confirms that this is not required for the current build, but may be useful for the future releases, then he changes the status of the bug as "Deferred". All the Deferred bugs will be considered for future releases

All the Test status bugs will be mailed to the testing team. The corresponding tester tests that bug in the new build or patch and change the status to "Closed" if it is fixed otherwise to "Re-Open" if it is not fixed.

All the Re-Open bugs will be mailed to the development team and then the above cycle repeats.

 

Balamuralikrishna.R

  • Jan 3rd, 2007
 

hi,

if you found any bugs, first of all you should verify any same bugs are exist in your defect traking tool before login your bug.

regrads,

Bala

  Was this answer useful?  Yes

Guest

  • Jan 4th, 2007
 

I would suggest you the following as soon as you find a defect...

1) Confirm whether the finding is actually a defect (refer to Req. Doc) and make sure it is not a duplicate.

2) Try to reproduce in another testing machine... (sometimes defect occur due to session issues, which might have been treated as a different defect)

3) Justify that it is a defect by refering to the Req. Doc. Screenshots & logs would be helpful to save the time in reproducing the defect.

And bug life cycle should be altogether a different question.

-- Danny

  Was this answer useful?  Yes

Santosh

  • Jan 4th, 2007
 

Scenario 1:When we encounter with a deviation with the behavior w.r.t functionality or GUI as specified in the FRS or GUI specs then we can directly report it as Bug in the Bug Tracking Tool.It is always a good practice to take the screenshot as a proof of evidence to show to the developers that the bug was there in the application when you were testing it if in case the bug is not repoducable at his end. Specify the steps to reproduce the bug if the bug is reproducable.

Scenario 2:When we are not sure whether it is a bug or not we can send it as an observation to the Test Lead he will review it and ask us to report it, when he finds that the observation can be reported as a bug in the Bug tracking tool after refering to the documents or communicating with the customer regarding the behavior of the bug and getting it clarified whether it is behaving as intended or is there any deviation in it if there is no proper documentation .

Sunitha

  • Feb 6th, 2007
 

Hi ALL, When we find a Bug, we have to check the same Bug in different Operating Systems if it supports. Sometimes you will get Bugs because of Softwares you loaded into your Machine. So before doing Testing ensure you dont have unwanted Softwares, i.e we call it as Ghost the machine and then test it. If it really a Bug then follow the Procedure as our above friends Discussed.

txs
Sunitha

  Was this answer useful?  Yes

Swapna Etikala

  • Feb 8th, 2007
 

Hi Dileep,your answer was excellent. Thanks.

  Was this answer useful?  Yes

srilatha

  • Feb 9th, 2007
 

If you get a defect first you have to conform whether the bug is really reproducable or not that's nothing but retesting testing the functionality of an application to check whether the defect is reproducable or not then track all the defects into a defect profile document or bug tracking tool to send it to project manager so that they can be assigned to the corresponding developers perform retesting on the area to check for the reproducability of the defect which is useful in triage meeting

  Was this answer useful?  Yes

Prakash

  • Mar 20th, 2007
 

What do you do once you find a defect?

Once you find a defect, this is what we need to do:

1.  Recreate the Defect:  Once you find a defect, we must try to recreate (meaning that we should be able to reproduce it) at least 3 times so that we are sure that it is a defect.  Some times, once we find it log it without recreating, may put us in a false situation (because sometimes the application does not behave in the same way).  Therefore, it is important to recreate the same defect several times.

2.  Attach the Screen Shot (supporting document):  Once we confirm that it is a defect, then it is a good idea to attach supporting documents when we log (write) a defect.  For example, screen shot, requirement document etc. For instance, let us say that instead of "Continue" button on a page, there is an typo "Contiinuee".  Now, we will make a screen shot of this page (To make screen shot, press "Print Screen" button on the keyboard, open a Word document, and Click Edit on the Word document and "Past" it.  You will see the screen now) Now, a tester needs to write defects in easy and clear language to make all the developers to understand easily.

2.  Log the Defect:  Now, the next step is, we need to log it.  Depending on the company what kind of tools they are using, for example, some companies use TestDirector to log defects, some companies use Rational ClearQuest, some use PVC Tracker and so on.  If the comapay is small and cannot afford these expensive tools, then they may simply use Excel sheet to log defects.  We log the defect.

Hope this helps.

  Was this answer useful?  Yes

shiva

  • Mar 23rd, 2007
 

Excellent Answer.
But if the team utilizing the tool like Bugzilla means The options will be somewhat differrent  from other

New
Assigned
Fixed
Invalid
WontFix
Later
Remind
WorksForMe
Reassign

The above options will be used.

But the process is same like previous answer.


  Was this answer useful?  Yes

munnu

  • Apr 29th, 2008
 

when we found a bug,we have to retest to know whether the bug found is valid or not,if it is a valid bug it will be posted.

  Was this answer useful?  Yes

Give your answer:

If you think the above answer is not correct, Please select a reason and add your answer below.

 

Related Answered Questions

 

Related Open Questions