defect, to include schedule impacts, when and where to put the defect resolution (which release/environment) and the potential impact of the defect resolution on other parts of the system (regression). They also provide feedback on the impact on test schedules and resources.
Other team members may be invited as needed. These other team members may include system architects, database administrators, business analysts, subject matter experts, individual developers or testers, technical writers, change management, or others. These team members may be able to provide greater insight on issues such as customer expectations, specific development issues, build and migration impacts, or test processes.
Sometimes it is best to include the rest of the team as"silent members" so that they can hear and contribute to the discussions. They also provide immediate feedback when needed. I like inviting them and have them sit on the perimeter of the room rather than at the "big tabl." The entire team is always encouraged to attend as workload and schedules permit. I'm the first to admit that I don’t have all the answers. But I know people who do! In the long run, it may save time later on in the project. Of course, the more people involved, the greater the chance of getting stuck on a single issue or off on a tangent.
Regardless of how you structure the process, the goal of Triage remains the same: evaluate, prioritize and assign the resolution of defects. As a minimum, you want to validate defect severities, make changes as needed, prioritize resolution of the defects, and assign resources.
Your process may vary, but I try to keep Triage focused on the following:
Defect Review, Assessment and Assignment. Triage Teams typically review and make an initial assessment of all new and/or rejected defects. They review each defect to validate the severity, clarify any issues surrounding the defect and then prioritize them for resolution. It is typically during this process that we set the defect’s Priority in the defect tracking system and assign it to a team member for resolution or further investigation. I like to have the Defect Tracking System open and projected on a wall for all to see, making changes as we go.
Any rejected defects are also reviewed to validate the reason for the rejection and to determine its disposition. In some cases the defect may be deferred to a future release or even closed outright if the team determines the defect, after further investigation, should be closed.
Investigation. In some cases, defects may be assigned to a team member for further review, investigation, or to coordinate with other team members. The reasons vary, but typically these defects need review or coordination with customers, or other team members to fully assess them for the level of effort involved with resolving and retesting them. We usually revisit them at future Triage meetings once all the pertinent questions have been answered.
A question I am often asked is "How often should the Triage Team meet?" My less than concrete answer is typically: "It depends." It depends on the impact on schedules of team members and their availability. It depends on project schedules. It depends on where we are in the development lifecycle. It depends on how many defects there are. Sorry, that’s the best answer I can give you."It depends."
Given that completely vague answer, typically a triage team meets often in the early days or weeks of the development process, and less frequently later in the process. You may meet daily at first, then 2-3 times a week, and finally 0nce