What are your defect management strategies for both waterfall and agile projects? Sure this is a wide ranging question, but how do you raise, manage and track them. Who is responsible for managing them (because not every project has a Defect Manager!)…
2 Likes
As acknowledged this is very broad, but here is our process
If the issue is directly related to a story under construction, a story defect is added as a task to the story itself and managed as part of the sprint - responsibility is story owner(s) for resolution.
If the issue is within the ownership of the team, but not related to current work, then a defect story card is written and added to the backlog based on severity/priority then prioritized for work. Responsibility is team members pulling in the work. A good practice here is to set a regular/scheduled review of any defect backlog with definition of when to close due to age (as not all defects/issues are always addressed.)
If the issue crosses functional teams, a separate tool is used (ClearQuest). It is assigned to a product which drives team ownership. It then becomes the responsibility of that team representative (Sr developer or architect) to analyze and assign for resolution.
Regards
2 Likes
Our process is very similar. We leave space at the end of the sprint and create a “clean up” story to catch any urgent defects that need to be addressed before the release to production.
1 Like
I have worked on both types of projects (Waterfall and Agile) and the defect process has been basically the same for both. Testers write up the defects and retest the fixes, there is a triage with members of the BA/test team and development to determine severity and rank their with priority.
The difference comes in the middle of the flow. In Agile, it was a business owner and a UAT Test Coordinator who triaged for UAT (determined severity and assigned priority). During System Test, there was only discussion if there was a conflict of opinion on severity. Priority is always dependent on severity and time needed (can this be fixed before the next Sprint without impacting the Sprint deliverables, does this have to be fixed NOW, or can it wait?).
In Waterfall, during System Test we would have triage meetings one or more times weekly (depending on the number of bugs and where we were in the cycle) to agree to or reset the severity of the bug and determine the priority of when it would be fixed (depended on the likelihood of it happening and the impact). During UAT, any bugs found were fixed now (unless they were minor and could be built into the next release). UAT defects were handled in this manner because in Waterfall, UAT usually took place in the last one to three weeks before Release deployment.
I hope this helps.
2 Likes
Our process is really similar to what Sean’s described above. An added part of it is that if a detect is found and we can attribute it to a recently released story (e.g. if we made frontend changes to the footer on the homepage then found an issue with the footer alignment a few days after release), then we re-open the story and link a bug subtask to it. The story is then added as part of the current sprint.
2 Likes