Triage or War Room or Ship Room, as it is called in different groups and organizations, is a place where team representatives meet on a regular basis to review defects that have been reported and decide their course of action. This is a team decision, hence the representatives typically include all disciplines such as business, design, development, testing and build/maintenance. Like a scrum master, typically a program manager or a product manager drives these triage meetings with defined protocols on time and communication, especially since they will have to look at a large set of bugs within the short period of time they have. Also, given that they look at bugs filed even by remote testers or remote team members, this is a very selectively hand-picked team that is able to derive the meaning of defects even if the reporting is not very articulate and is able to take the right decisions on behalf of the end users holding up product quality. While this team plays such an important role in the product life cycle, sometimes given the overhead involved in driving triage meetings and managing triage teams that have quite some team members, some teams may compromise on the comprehensive team representation and may decide to settle with just doing informal triages with the developers and directly assign the bugs to them. Sometimes, the developer may trespass to directly triage the bug himself (as he may often have admin rights to the defect database) to save time and skip triage meetings. He may also do this to avoid his bugs being discussed in large forums especially if he takes defects in his areas of work as a personal representation of his quality of work. When such scenarios arise, very soon the discipline around a formal triage meeting and the value that comes out of it, may be lost.

I talked about testers’ defending their defects in an earlier blog a couple of months back. Keep in mind that triage representation is a tester’s entitlement. Even if formal triage meetings have traditionally not been the norm in an organization, the tester needs to push his way up with the product team to ensure he at least has paired discussions with the developer and with the business teams in determining the right priorities, severities and courses of action for defects. Each of these entities bring in their own view into defect management. A tester’s view bringing in the end user empathy, should never be compromised on. Slowly see if you can bring in the formal touch into your group by starting triage meetings. And if product/program management is hesitant to drive triage meetings, take the onus on yourself as a tester. This might look as an additional overhead, but soon you will be able to convince your team of the value and have the right team drive it. Also, this will be a big help you do to yourself and your test team by clearing up the huge backlog of defects. This is especially true in the early stages of your product lifecycle when the team is still lax about implementing formal defect management processes. So, as a tester, it is your entitlement to be a part of the triage team and propose one, if it does not exist as of today. Do not miss this opportunity in your own best interest, in the interest of your entire product team and in the overall interest of your product under development.