Triage van bugs/defecten bij het testen van software
Redactie
⚡ Slimme samenvatting
Defecttriage is een beoordelingsvergadering waarin de testleider, de ontwikkelingsleider en de projectmanager elke gemelde bug rangschikken op ernst, prioriteit en risico, waarna ze verantwoordelijken toewijzen en een realistisch reparatieschema afspreken.
Wat is 'Defecttriage'?
Defecttriage is een proces waarbij elke bug wordt geprioriteerd op basis van de ernst, frequentie, risico, enzovoort. De term triage wordt gebruikt in de Software testen / QA om de ernst en prioriteit van nieuwe defecten te bepalen.
De naam is ontleend aan de spoedeisende geneeskunde, waar patiënten bij triage op urgentie worden ingedeeld wanneer de middelen beperkt zijn. Een QA-team staat voor dezelfde beperking: de lijst met defecten is altijd langer dan de beschikbare tijd vóór de releasedatum, dus moet iemand beslissen wat er nu wordt opgelost, wat later en wat wordt uitgesteld. Triage is de bijeenkomst waar die beslissing wordt genomen en vastgelegd.
Waarom hebben we 'Defect Triage' nodig?
Het doel van Bug Triage is het evalueren, prioriteren en toewijzen van de oplossing van defecten. Het team moet de ernst van het defect valideren, indien nodig wijzigingen aanbrengen, de oplossing van de defecten voltooien en middelen toewijzen. Wordt voornamelijk gebruikt bij agile projectmanagement.
Zonder triage blijven defecten in de tracDe ernst van de melding wordt bepaald door de tester die het rapport opstelt, en ontwikkelaars kiezen werk op basis van persoonlijke voorkeur in plaats van de impact op de bedrijfsvoering. De onderstaande banner vat de redenen samen waarom teams de vergadering in de agenda houden.
Hoe vaak moet er een 'Defect Triage' worden uitgevoerd in een release?
De frequentie van de defecttriagevergaderingen staat niet vast. Het hangt af van de projectsituatie.
Hier volgen enkele belangrijke factoren die de frequentie van de defecttriagevergaderingen bepalen:
Deze belangrijke factoren zijn:
- Volgens de projectplanning
- Aantal defecten in het systeem
- Impact op de planning van de beschikbaarheid van teamleden
- Algemene projectgezondheid
Normaal gesproken worden Defect Triage Meetings twee of drie keer per week gehouden.
De werkdruk neemt toe naarmate een release dichterbij komt. Teams werken in korte tijd. Worsteling om de bal Bij iteraties wordt vaak een korte triage in de dagelijkse routine opgenomen tijdens de laatste sprint, terwijl een project met een langere, planmatige cyclus mogelijk slechts één keer per week een triage uitvoert tot het einde. regressietesten fase begint.
Wie zijn de verplichte en overige deelnemers aan 'Defect Triage'?
Verplichte deelnemers
Onderstaande projectleden nemen altijd deel aan Defect Triage Meetings.
- Projectleider
- Testteamleider
- Technische leiding
- Teamleider Ontwikkeling
Optionele deelnemers
- Developers
- Testers
- Bedrijfsanalist
De optionele deelnemers worden uitgenodigd wanneer hun input nodig is bij een specifiek defect, bijvoorbeeld wanneer een businessanalist moet bevestigen of het gerapporteerde gedrag daadwerkelijk in strijd is met een vereiste of een verkapte wijzigingsaanvraag betreft.
Rollen en verantwoordelijkheden van deelnemers tijdens 'Defect Triage'.
Elke verplichte deelnemer komt met een andere verantwoordelijkheid, en de vergadering kan alleen op tijd beginnen als alle drie zich van tevoren hebben voorbereid.
Testteamleider
- Geplande bugtriagevergadering en vergaderingsmelding verzenden naar deelnemers.
- Maak een defectrapport en stuur dit vóór de vergadering naar alle deelnemers.
- Prioriteit toewijzen en strengheid van de defecten.
- Geef een presentatie zodat andere leden de oorzaak van het defect begrijpen.
- Elke vergadernotitie wordt vastgelegd en naar de deelnemers aan de vergadering verzonden.
Ontwikkelingsleider
- Helpt bij het prioriteren van de defecten.
- Bespreek de moeilijkheidsgraad van een defect en leg het risico uit dat aan dat defect verbonden is.
- Wijs werk om defecten op te lossen toe aan relevante ontwikkelaars.
- Werk de probleemoplossing bij en voeg ontwikkelingsnotities toe voor het geval er informatie ontbreekt of als er aanvullende informatie nodig is voor ontwikkelaars.
Projectleider
- Hulp bij het prioriteren van de defecten.
- Bespreek de releasedatum van de volgende iteratie voor QA.
- Zorg ervoor dat vertegenwoordigers van gerelateerde gebruikers ook worden uitgenodigd voor de bugtriagevergadering.
De projectmanager bepaalt de releasedatum, dus de uiteindelijke beslissing over een eventueel betwist defect ligt doorgaans bij hem of haar, zoals hieronder weergegeven.
Wat gebeurt er tijdens de ‘Defect Triage’ bijeenkomst?
- Testteamleider stuurt een bugrapport met de nieuwe defecten. Tijdens het defecttriagegesprek wordt elk defect geanalyseerd om te zien of er de juiste prioriteit en ernst aan wordt toegekend.
- Indien nodig worden de prioriteiten herschikt.
- Defecten worden geanalyseerd en beoordeeld op basis van de ernst ervan.
- Hierbij wordt onder andere gesproken over de complexiteit van het defect, risico's, afkeuring en het opnieuw toewijzen van fouten.
- Updates worden vastgelegd in bugs. trackoningssysteem.
- De QA-ingenieur zal de wijzigingen in elk defect aanbrengen en deze met elke deelnemer bespreken.
- Het veld “Opmerkingen” wordt correct bijgewerkt door de essentiële punten van de vergadering te noteren.
De meeste discussietijd gaat op aan de twee aspecten die het gemakkelijkst door elkaar gehaald kunnen worden. Ernst en prioriteit worden onafhankelijk van elkaar vastgesteld, en een defect kan hoog scoren op het ene aspect en laag op het andere.
| Aspect | Strengheid | Prioriteit |
|---|---|---|
| Wat het meet | In hoeverre het defect het product of de functionaliteit ervan aantast. | Hoe snel moet het defect verholpen worden ten opzichte van andere werkzaamheden? |
| Normaal ingesteld door | De tester die het defect meldt. | Overeenstemming bereikt tijdens de triage, met de projectmanager en de productafdeling als voortrekkers. |
| Gedreven door | Technische impact en de getroffen functionaliteit | Impact op het bedrijf, zichtbaarheid voor de klant en de releasedatum |
| Voorbeeld van een mismatch | Ernstige storing, lage prioriteit: een probleem met een functie die niemand gebruikt tot het volgende kwartaal. | Lage ernst, hoge prioriteit: een verkeerd gespelde bedrijfsnaam op de landingspagina. |
Tip: Houd de bespreking van een enkel defect kort. Als een probleem niet binnen een paar minuten kan worden opgelost, zet het dan even opzij, wijs een verantwoordelijke aan om het te onderzoeken en neem het mee terug naar de volgende sessie, in plaats van één defect de hele vergadering te laten in beslag nemen.
Wat is de uitkomst van de ‘Defect Triage’?
Aan het einde van elke bijeenkomst worden Defect Triage Metrics opgesteld en aan alle aanwezigen gegeven. Dit rapport fungeert als notulen van de vergadering en kan nuttig zijn voor toekomstige vergaderingen.
Het rapport is het punt waarop de triage weer verbonden wordt met de bredere context. defectbeheerprocesTeams leggen hierin doorgaans het volgende vast:
- Tijdens de sessie zijn de gebreken besproken, waarbij voor elk gebrek de overeengekomen ernst en prioriteit zijn vastgesteld.
- Nieuw toegewezen defecten, samen met de ontwikkelaar die er nu eigenaar van is.
- Gebreken die zijn uitgesteld, afgewezen of als duplicaten zijn gemarkeerd, met vermelding van de reden.
- Het aantal openstaande defecten per ernstgraad wordt weergegeven, zodat de trend over de verschillende sessies heen zichtbaar is.
- Actiepunten meegenomen naar de volgende vergadering.
Omdat elke wijziging wordt teruggeschreven in de tracker, de toestand van elk item blijft consistent met zijn positie in de defectlevenscyclusEn de volgende sessie begint met een accurate lijst in plaats van een verouderde.
