Whenever the tester finds defect in the solution it will be created in the tracker as new issue with the priority & severity number.
Once the issue has been accepted by the developers as valid (if the issue is reproducible and it is a mis from requirement) it will be moved to open state.
If the developer is not able to reproduce the defect raised by the tester then the status will get changed as not reproducible.
If the issue reported is not a valid issue then the status will be rejected.
If the issue raised by the tester is not in the requirement but if it is valid one the client will accept the issue as change request.
If the same issue has been raised by a different reporter or if the issue has been covered in the different defect then the status will be of Duplicated.
The team lead will assign that bug to the corresponding team member so that the bug will be in Assigned state.
Once the developer start looking into the root cause of the problem then the status will be changed to Work in Progress.
If the issue has been resolved by the developer it will be moved to fixed/resolved state.
Once the reporter test the same issue and confirms that issue is not reproducible the status will be moved to closed.
Once the reporter test the same issue and confirms that issue is reproducible the reporter will reopen the same issue.
If the team accepts that the issue is valid but if the priority is low so that it can be fixed in next phase or next build then the status will be deferred.
If the developer needs some clarification on the bug raised or if he has some doubt on fixing the defect the status will be feedback.
These procedures are being followed in DDTS (Distributed Defect Tracking System).
Once the issue has been accepted by the developers as valid (if the issue is reproducible and it is a mis from requirement) it will be moved to open state.
If the developer is not able to reproduce the defect raised by the tester then the status will get changed as not reproducible.
If the issue reported is not a valid issue then the status will be rejected.
If the issue raised by the tester is not in the requirement but if it is valid one the client will accept the issue as change request.
If the same issue has been raised by a different reporter or if the issue has been covered in the different defect then the status will be of Duplicated.
The team lead will assign that bug to the corresponding team member so that the bug will be in Assigned state.
Once the developer start looking into the root cause of the problem then the status will be changed to Work in Progress.
If the issue has been resolved by the developer it will be moved to fixed/resolved state.
Once the reporter test the same issue and confirms that issue is not reproducible the status will be moved to closed.
Once the reporter test the same issue and confirms that issue is reproducible the reporter will reopen the same issue.
If the team accepts that the issue is valid but if the priority is low so that it can be fixed in next phase or next build then the status will be deferred.
If the developer needs some clarification on the bug raised or if he has some doubt on fixing the defect the status will be feedback.
These procedures are being followed in DDTS (Distributed Defect Tracking System).
Posts
{ 0 comments... read them below or add one }
Post a Comment