Defect Triage: Alles wat u moet weten staat hier!

Wat is Defect Triage?

Defect Triage is een proces waarbij de testers de bug ontdekken en er een mate van risico, herhaling en ernst aan toekennen. Deze graad geeft in wezen voorrang aan de bug om eerst te worden behandeld.

Triage is echter een medische term die in feite proef of een try-out betekent. Wanneer u op de spoedeisende hulp aankomt, wordt uw eerste medische evaluatie gedaan door een verpleegkundige.

Op de spoedeisende hulp wordt dit meestal gedaan in de triagekamer. In deze tijd is het van groot belang dat de patiënt zijn probleem aan de verpleegkundige beschrijft, zodat zij nauwkeurig kan beoordelen wat er vervolgens moet gebeuren.

Op basis van de ernst of urgentie van de medische toestand van een ander persoon, kan het zijn dat hij sneller wordt teruggenomen dan jij. Dit is precies wat er gebeurt wanneer een software tester een defect of bug triage uitvoert.

Zij kennen een ernstgraad toe aan elke bug en de bug die ernstiger lijkt of de bug die meer potentieel heeft om de integriteit van het systeem in gevaar te brengen, wordt eerst in aanmerking genomen.

Defect Triage Vergadering

Triage vergaderingen worden vergemakkelijkt door de QA lood en het wordt gecoördineerd met bedrijfsanalisten, IT lood, projectmanager, of zelfs de productmanager.

Tijdens de ontwikkeling of de testende fase, komen de testers heel wat kwesties of insecten tegen die iedereen blijven lastig vallen. Om te zorgen voor deze bugs, is de defect triage vergadering georganiseerd.

Het belangrijkste doel van deze triage vergadering is om te categoriseren, prioriteren, en track issues.

Triage vergaderingen gebeuren om de zo vaak, soms zelfs 3 – 4 keer in een week, afhankelijk van de grootte van het project, project situatie, planning, en het aantal defecten. Meerdere factoren spelen een rol bij het bepalen van het aantal triagevergaderingen dat nodig is om een bug voor eens en voor altijd te elimineren.

Al deze vergaderingen omvatten discussies over de complexiteit van het defect, het risico dat ermee gemoeid is, toewijzingen, hertoewijzingen en afwijzingen. Al deze updates worden vastgelegd in het bugtracking-systeem.

Voor de beste resultaten zou de QA-leider het bugrapport met de bestaande defecten of nieuwe defecten voor elke vergadering moeten versturen.

Elk defect moet worden geanalyseerd om te zien of de juiste prioriteit en ernst zijn toegewezen. Het belangrijkste motief van deze vergadering is om alle problemen op een tijdige, vaste, en nauwkeurige manier op te lossen.

Tijdens de vergadering, wordt elke bug gecategoriseerd in een van de drie categorieën:

• IMMEDIATE ACTION TO FIX THE BUG: Het defect valt in deze categorie om twee redenen. De eerste reden is dat er voldoende middelen bij het team zijn om de bug op te lossen en de tweede reden is dat de bug in de toekomst problemen zou kunnen veroorzaken, daarom is het belangrijk dat ze de bug onmiddellijk oplossen.
• ACTIE OP DE BUG OP EEN PUNT LATER IN DE TIJD: Een bug valt in deze categorie wanneer het team weet dat het niet iets groots is en na enige tijd kan worden behandeld.
• GEEN ACTIE BUG: Dit betekent in feite dat de bug zeer klein is en geen effect heeft op het hele systeem. Daarom is er geen noodzaak om een actie op een dergelijke bug.

Stappen in Defect Triage

Het triage team bestaat uit projectmanager, tester, test lead, ontwikkelaar, omgeving manager, test manager, en business analist. Er zijn 3 stappen in defect triage; defect review, defect assessment, en defect toewijzing. Elk van de stappen wordt hieronder in detail besproken:

• DEFECT REVIEW: Al het bovengenoemde personeel duikt diep in de oorsprong en de gevolgen van elk defect in een poging om ze te verhelpen.
• DEFECT BEOORDELING: In deze stap, worden de defecten gecategoriseerd in 2 categorieën; te repareren en in de wacht. De ernst van het defect is de belangrijkste basis van deze segregatie. Het hierboven genoemde personeel neemt gezamenlijk de beslissing welk defect onmiddellijk moet worden behandeld en welk defect in de wacht moet worden gezet.
• DEFECT TOEWIJZING: Nu het team een lijst heeft van defecten die als eerste moeten worden behandeld, wijzen zij elk defect toe aan de betrokken persoon. Dit alles wordt gedaan nadat het defect goed en uitvoerig is geëvalueerd.

Rollen en verantwoordelijkheden van elk lid in het Triage Team

• TEST LEAD: De test lead is degene die het allemaal begint. De testleider stuurt een formele uitnodiging naar alle triage leden samen met een gedetailleerd defect rapport. De testleider is de eerste persoon die het defect identificeert en er een ernstgraad aan toekent. Een van de belangrijkste verantwoordelijkheden van de testleider is het voorbereiden van een presentatie voor het triage team, die hen meer inzicht geeft in elk defect. Deze presentatie helpt de teamleden om snel tot de kern van het probleem door te dringen.
• PROJECT MANAGER: De projectmanager speelt een centrale rol in het prioriteren van defecten, het maken van de defectenlijst, en het bemiddelen van de hele vergadering. Hij zorgt er ook voor dat alle leden van het triage team aanwezig zijn bij de bespreking. Soms loopt de discussie hoog op en dat is waar de projectmanager tussenbeide komt om de teamleden de kans te geven dingen vanuit hun perspectief te verwoorden.
• DEVELOPMENT TEAM LEAD: Development team lead en projectmanager prioriteren gezamenlijk defecten. De belangrijkste functie van de development lead is het communiceren van de risico’s en het complexiteitsniveau van elk defect. Ook is hij degene die taken toewijst aan verschillende leden van het triage team.

Er zijn andere leden in het team, maar de projectmanager, de testleider, en de development team lead zijn de belangrijkste personen. De vergadering zou niet tot een conclusie komen als een van hen ontbreekt.

Wat gebeurt er in een triagevergadering?

De defect triagevergadering is verdeeld in 3 delen: voor de vergadering, tijdens de vergadering en na de vergadering. Voordat de vergadering begint, stuurt de testleider een rapport naar alle leden van het triage team, zodat zij tot op zekere hoogte op de hoogte zijn van de laatste bugs.

• PRE-MEETING: Testers hebben een sleutelrol te spelen in de pre-meeting. De testers geven informatie over de insecten aan het team en zij categoriseren elk insect in verschillende secties op basis van strengheid en prioriteit. Zo fundamenteel, is de pre-meetingsessie eigendom van de testers.
• DURING MEETING: Het gebeurt niet altijd dat alle kwesties in een vergadering worden opgelost. Sommige hangende kwesties van de vorige defect triage vergadering worden besproken alvorens over te gaan tot de nieuwe kwesties. Daarna wordt de voortgang van eerdere issues besproken. Vanaf dit punt wordt elk punt genoteerd over de ernst van de bestaande defecten. De teamleden nemen gezamenlijk een beslissing over welk defect onmiddellijk moet worden opgelost en welk defect ze kunnen uitstellen tot een latere datum. Als de deadline nabij is, zullen de defecten met een hogere graad van ernst het eerst worden behandeld en zullen de minder ernstige defecten in de wacht worden gezet. Echter, als er geen druk is van deadlines, kunnen zelfs de kleinste bugs worden opgelost in het begin van het project. Op basis hiervan wordt de buglijst bijgewerkt en dit is waar de toewijzing van taken komt. De testleider heeft het laatste woord in de vergadering. Hij vat de hele vergadering snel samen en deelt de onmiddellijke actiepunten mee aan de respectieve teamleden.
• POST-MEETING: MOM (notulen van de vergadering) wordt gedeeld aan het defect triage team na de voltooiing van de vergadering. Dit document bevat de belangrijkste punten die tijdens de vergadering zijn besproken.

Inhoud van een Bug Triage Rapport

1. DEFECT ID: Aan elk defect is een uniek nummer toegekend dat het onderscheidt van andere defecten.
2. DEFECTBESCHRIJVING: Dit heeft betrekking op de wijze waarop het defect storingen in het systeem veroorzaakt.
3. CREATION DATE: Het is de datum waarop de bug voor het eerst werd opgemerkt.
4. CREATOR: De maker is de persoon die het defect voor het eerst heeft opgemerkt en gemeld.
5. SEVERITY: Dit is een maat voor hoe ernstig de bug is.
6. PRIORITY: De prioriteit kan hoog, gemiddeld, of laag zijn. Hoge prioriteit betekent dat de bug onmiddellijke aandacht vereist, gemiddelde prioriteit betekent dat de bug na enige tijd kan worden opgelost en geen onmiddellijke actie vereist, en lage prioriteit betekent dat de bug geen significante of merkbare invloed op het project heeft en daarom al dan niet kan worden opgelost.
7. STATUS: Of de bug nieuw, in beoordeling, in uitvoering, of voltooid is, wordt bepaald door te verwijzen naar de bugstatus.
8. TOEWIJZINGSDATUM: Dit is de datum waarop de bug werd toegewezen aan het respectieve personeel om te worden opgelost.
9. TOEWIJZING AAN: Dit veld heeft de naam van de persoon aan wie de bug is toegewezen om te worden opgelost.
10. RESOLUTION: Wat wordt gedaan om de bug op te lossen.
11. DATE OF RESOLUTION: Geschatte datum waarop het defect volledig zal zijn opgelost.
12. ESTIMATED TIME: Geschatte tijd van het oplossen van het defect.
13. ACTUELE TIJD: Totale tijd verstreken voor het oplossen van het defect.
14. ROOT CAUSE DESCRIPTION: Dit veld heeft informatie met betrekking tot waarom de bug verscheen in de eerste plaats.

Waarom hebben we Defect Triage nodig?

Het belangrijkste voordeel dat u krijgt van het proces is dat uw team krijgt om de ernst van de bug te evalueren, plannen te bedenken om het uit te vissen en tot een conclusie te komen met betrekking tot de middelen die moeten worden toegewezen voor het proces. Defect triage wordt voornamelijk gebruikt in agile testmethodologie

CONCLUSIE

Om het defect op te lossen, wordt een defect triage vergadering bijeengeroepen. De testleider, projectmanager en ontwikkelteamleider moeten aanwezig zijn onder alle triage teamleden.

De defect triage vergadering wordt voltooid in 3 fasen; pre-meeting, tijdens de vergadering, en na de vergadering. Na dit alles stelt de testleider een gedetailleerd triage-rapport op.

Het rapport bevat alle informatie vanaf het moment dat het defect voor het eerst werd opgemerkt tot de hoofdoorzaak van het defect.

De frequentie van de defect triage hangt volledig af van de omvang van het project. Het kan op een wekelijkse, maandelijkse of dagelijkse basis worden georganiseerd.