8/13/2019 Bugs Trackings

1/2

Q :- What do we do when we get a bug in an application first? Explain it with the help of anexample of Bug Life Cycle?

ns When we found a bug while testing We need to clarify whether it is bug or not? If u thinkthat'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 anybug tracking tool.

We have to give a uniue bug id to that bug. !ive title of the bug then "escription #teps toreproduce $xpected %esult Actual %esult &riority #everity uild no. (est case id and "ate foundby.

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

When we log or enter a bug that should be in Active or )ew status. When it gets assigned todeveloper he'll fix the bug and he'll change the status to fixed or resolved After that u have tocheck or *erify the bug on the new build. If u didn't find any the same bug in the latest build u +ust

close the bug. ,therwise u have to %eopen the bug. In this way bug life cycle goes on.

or#cenario -When we encounter with a deviation with the behavior w.r.t functionality or !UI asspecified in the /%# or !UI specs then we can directly report it as ug in the ug (racking (ool.Itis always a good practice to take the screenshot as a proof of evidence to show to the developersthat the bug was there in the application when you were testing it if in case the bug is notrepoducable at his end. #pecify the steps to reproduce the bug if the bug is reproducable.

#cenario 0When we are not sure whether it is a bug or not we can send it as an observation tothe (est 1ead he will review it and ask us to report it when he finds that the observation can bereported as a bug in the ug tracking tool after refering to the documents or communicating withthe customer regarding the behavior of the bug and getting it clarified whether it is behaving asintended or is there any deviation in it if there is no proper documentation .

bug life cycle

After confirming it as a ug 2ou have to post it in bug tracking tool. (hen the status of the ug willbe )ew . 2our team lead or any senior person will review it and if it is really a bug then he willchange the status to ,pen . If he confirms that it is not a bug he will close the bug and change thestatus to 3losed .

All the ,pen status bugs will be mailed to the development team. (heir team lead will assign thebugs to the corresponding developer. 4e will change the status to Assign and add the

corresponding developer name. When the developer fixes that bug he changes the bug status to(est .

If the development team lead confirms that this is not a bug then he re+ects that bug with validreasons. (hen the status of that bug will be %e+ected .

If he confirms that this is not reuired for the current build but may be useful for the futurereleases then he changes the status of the bug as "eferred . All the "eferred bugs will beconsidered for future releases

8/13/2019 Bugs Trackings

2/2

All the (est status bugs will be mailed to the testing team. (he corresponding tester tests that bugin the new build or patch and change the status to 3losed if it is fixed otherwise to %e5,pen if it isnot fixed.

All the %e5,pen bugs will be mailed to the development team and then the above cycle repeats.

!efect "e#ectionWhat will you do when de$eloper re#ects your defect?

When a developer re+ects a defect then we 6testers7 have to check on which reason he re+ectedthe defect.

(he developer may re+ect the bug if it is 8)on %epro8 or 89nown issue8 or 8"uplicate 8or if it is according to reuirements or if it is not a valid bug.-. If status he mention is 8)on %epro8 then we have to add sufficient repro steps about that defect

in defect tracking tool.

In case he doesnot satisfied we have to repro in presence of developer in test machine.

$ven though he not satisfied then we have move the issue to our 1ead.

Bug WeightageWhat are different weightages gi$en for a Bug?

#everity 6#everity is Absolute 7#everity - ug causes system crash or data loss.show stopper issue :in which case testing cannot be continued#everity 0 ug causes ma+or functionality or other severe problems; product crashes in obscure

cases.)ot a show stopper but can considerably damage the system which is under test#everity ug contains typos unclear wording or error messages in low visibility fields.veryminor UI issue. may be seen only in some machines which are not recommended for theapplication under test

&riority6&riority is %elative7&riority - =ust fix as soon as possible. ug is blocking further progress in this area.&riority 0 #hould fix soon before product release.&riority