Hi,
Can anyone explain about the build in bug life cycle.
Thanks.
Printable View
Hi,
Can anyone explain about the build in bug life cycle.
Thanks.
Bug life cycle:-
1:-tester find a bug and give its status "new" and send to TL(team leader)
2:-TL verify its wheater its a geniune bug or not if yes then give its status "open" and forward to developer for fixing
3:-developer now fix the bug and can give its status:
i-rejected
ii-differ
iii-or if he/she solve it give its status fix and send to tester
4:-now tester verify it if the bug is fix then give its status-closed
and if bug is still exist then give its status-reopen
it was bug life cycle
It defines the Series/Process of steps followed by the time a bug is found, fixed and closed.
The Steps followed are:-
1. As soon as the bug is found it entered into the defect tracking system and assigned the status as "NEW".
2. Once its been analyzed and accepted as a geneuine- defect, the status is changed to "OPEN". If the bug is found to be invalid the status is changed to "REJECT".
3. Its then assigned to a developer status changes to "ASSIGNED TO".
4. Once its fixed by the developer status changes to "Fixed Ready to test".
5. Tester then Re-test the fix and if fix works fine, he/she set the status to "Closed".
6. In some cases, if the bug is a major fix then it is postponed to the future releases in that case the status is changed to "Deffered" an consider for future release.
Bug life cycle starts when a tester finds a bug and it goes through different stage till it is closed finally by tester.
Bug life cycle:
1."new" -as soon as the tester finds the bug it is reported in defect tracking system.
2."validation by team lead". Bug found by tester is validated by team lead against various specifications, if he thinks bug is geninue, assigns to developer else marks rejected.
3."rejected"-invalid bug is marked by test lead as rejected.
4."assigned"-valid bug is assigned to developer by test lead.
5."validation by developer".bug assigned to developer is validated by developer.if the bug is geninue, bug is marked as "open" else marked ""pending rejected"
6."pending rejected"-invalid bug assigned to developer is marked as pending rejected by developer.
7."open"-valid bug assigned to developer is opened by developer to fix it.
8."fixed"-valid bug after fixed by developer is marked as fixed by developer. And marked as "pending retest" by developer lead.
9."pending retest"- fixed bug is marked as pending retest by developer lead for retesting.
10."validation by team lead"-the test fixed by developer is validated by team lead and marked as "retest".
11."retest"-tester retest the bug fixed by developer for previously raised bug.
12."validation by tester"-tester does retest and validates the bug whether it is fixed or not. If fixed the bug is closed and marked as "closed" else marked as "reopen".
13."reopen"-if the bug after retest behaves same as before or has different bug then tester marks the bug as "reopen" and sends to developer.
14."closed"-after retesting if the bug is fixed then marked as "closed".
Apart from this "BLOCKED" "POSTPONED" AND "DEFERRED" .
"BLOCKED"-when a bug reported by tester is already reported by another tester, the bug is marked as "blocked" .once the bug is fixed, it is retested.
"POSTPONED"-When the bug is postponed indefinitely due to unavailability of test case or functional requirements the bug is marked as "POSTPONED".
"DEFERRED"-When the bug reported by tester is of no importance or the bug does not have impact ,the bug is marked as"DEFERRED" and is fixed in next release.
Thanks & Regards
Raj1402
Very nicely explained
[QUOTE=skiran19;19309]It defines the Series/Process of steps followed by the time a bug is found, fixed and closed.
The Steps followed are:-
1. As soon as the bug is found it entered into the defect tracking system and assigned the status as "NEW".
2. Once its been analyzed and accepted as a geneuine- defect, the status is changed to "OPEN". If the bug is found to be invalid the status is changed to "REJECT".
3. Its then assigned to a developer status changes to "ASSIGNED TO".
4. Once its fixed by the developer status changes to "Fixed Ready to test".
5. Tester then Re-test the fix and if fix works fine, he/she set the status to "Closed".
6. In some cases, if the bug is a major fix then it is postponed to the future releases in that case the status is changed to "Deffered" an consider for future release.[/QUOTE]
Hi there,
The bug life cycle is so easy and simple when going thru it theoritically and all the above post are perfect and very informative .Thnx for the answers. I am actually working in a small company and this is very much different .... I wanna know that the above mentioned process work in mnc's ....or its jst a theory??? and my other question is ....In small companies there are alot of projects and jst one test lead so will he still validate whether each and every bug in projects are genuine???? Can anyone explain about this???
hi friend..
According to me companies follow their own approach to fix the bug.. Friend please understand a single thing in an application fixing all bugs is not so easy and not possible too .. fixing the bug immediately depends of the severity of the bug or else fix in the later version... We stop testing a project due to time line specified us ends and some other conditions..
This is the fact happens not some times but many times in the real time.
So don't worry keep on giving your best efforts..
Thanks
Deepasree
Bug life cycle
1.First tester find the bug in the application then send it to the test lead or team leader.
2.team leader see the Bug is valid or not if it is not valid the he assign the bug as "Rejected".
2.If the team leader finds the bug is valid then he send the bug to the Development team and status of the bug is"Open".
3. development lead checks the bug is valid or not if it is not valid then he send the bug to the team lead and the status is the "rejected".
4.If bug is valid then development lead assign the bug to the developer then the status of the bug is the "open"
5.Developer checks the bug is valid or not if it is not valid then it is send to the development leader and status is "rejected".
6.If bug is valid then developer fix then bug and send to the development lead.status is "Fixed".
7.The fixed bug send to the team lead ,team lead send to the tester.Tester test the bug if it really fixed.if it's really fixed then it get closed by the Tester.And status of the bug is "Closed".
8.If the bug is not import to developer then also it is rejected.
9.or it can be postpone by developer.Then the status of the Bug is"Differed".
Thank u !
Pl'z correct me if anything wrong.
hi prachi_nd
One more point, if the developer keep on rejects the bug and you know very well the bug is valid and if u have rights report to the test manager directly.. this scenario comes in very rare case
Thanks
Deepasree
The bug needs to be communicated and asssiged to developers that can fix it.
After the problem is resolved , fixes should be retested, and determinations made regarding requirments for regression testing to check that fixes didn't create problems elsewhere.
That's my idea
thanks
jagathkp
hi,
please referf to tha attachement, the life cycle differs from company to company.
Thanks
Sushma
hi friend..
Bug life cycle never changes from company to company..
Thanks
Deepasree
[quote=bagavathisupriya;19011]hi, can anyone explain about the build in bug life cycle. Thanks.[/quote] a new bug found by tester/customer. Bug is submitted in bug host account. Bug review after review its assigned to development team. Development team fixed that bug and send to qa. Qa verifies bug and gives status fixed or not. Re-assigned/closed.
Hi Deepasree,
u said that bug life cycle never change from company to company its true. bug cycle is same. BUT, the main tool is tracker, its on the tracker, which is used by the company. you can find that every tracker have the different status to set for Tester and designer. and Also, if u point out then check that medium level company have their own tracker tool. and somewhere the tester is directly assigns bug to developer. so there, changes occurs.
hi friend..
i am speaking only a bout the bug life cycle.. i know very well the bug tracking tool is different from company to company
Thanks
Deepasree
hi,
sorry its my mistake meant to write the terminology in life cycle,
Thanks
Sushma
hi
build-once the business analyst gives the requirment document to devlopment department,they develop the appication based on the customer requirements and it is released to the testing department,that type of the release is called build.