Defectbeheerproces bij het testen van software

Wat is een defectbeheerproces?

Het Defectbeheerproces Testlevenscyclus is een systematische aanpak die wordt gebruikt bij softwaretesten om bugs te identificeren, classificeren, verhelpen en verifiëren voordat software wordt uitgebracht. De levenscyclus omvat zes kernfasen: 1) Ontdekking van het defect, 2) Categorisatie, 3) Oplossing door ontwikkelaars, 4) Verificatie door testers, 5) Afronding en 6) Rapportage van het defect aan het einde van het project.

Dit artikel legt uit hoe u het defectbeheerproces kunt toepassen met behulp van de GuruEen voorbeeld van de 99 Bank-website, zodat beginners en gevorderde testers elke stap in een echte projectcontext kunnen begrijpen.

Waarom heeft u een defectbeheerproces nodig?

Stel je voor dat je team tijdens het testen verschillende bugs heeft gevonden. Guru99 Bankproject. Zonder een gestructureerd proces verloopt de communicatie tussen testers en ontwikkelaars mondeling of via verspreide berichten.

Een week later reageert de ontwikkelaar met een andere kijk op de zaak.

De week daarop reageert de tester opnieuw, wat voor nog meer verwarring zorgt.

Wanneer defecten mondeling of informeel worden gemeld, worden de zaken al snel ingewikkeld. Om bugs te beheersen en effectief te beheren, is een gedefinieerde defectlevenscyclus nodig die de manier waarop teams rapporteren standaardiseert. track, en sluit kwesties af.

Stap 1) Ontdekking

In de De reis van mijn leven In deze fase moet het projectteam zoveel mogelijk defecten identificeren voordat de eindklant ze tegenkomt. Een defect wordt als "ontdekt" beschouwd zodra het door het ontwikkelteam is erkend en geaccepteerd, waarna de status verandert naar Aanvaard.

In het voorbeeldscenario ontdekten testers 84 defecten op de GuruWebsite van 99 Bank.

Testers en ontwikkelaars zijn het echter niet altijd met elkaar eens. Kijk bijvoorbeeld naar het volgende voorbeeld, waarin het testteam problemen identificeert op de GuruDe website van 99 Bank meldt deze fouten, maar het ontwikkelteam betwist of het om defecten gaat.

Wat moet je in zo'n geval doen als testmanager?

A) Ga ermee akkoord dat het een defect is, zoals het testteam ook aangeeft.
B) Neem de rol van rechter op je en beslis of het probleem een ​​defect is of niet.
C) Ga met het ontwikkelteam overeen dat het geen defect is.

De juiste aanpak is optie B. Er moet een oplossingsproces worden toegepast om het conflict op te lossen, en de testmanager moet het probleem onpartijdig beoordelen alvorens te beslissen of het als een defect kan worden beschouwd.

Stap 2) Categorisatie

Het categoriseren van defecten helpt ontwikkelaars hun werk te prioriteren, zodat de meest bedrijfskritische problemen als eerste worden opgelost. Categorisatie wordt doorgaans uitgevoerd door de testmanager en is gebaseerd op ernst en impact op de bedrijfsvoering.

Defecten worden doorgaans ingedeeld in vier prioriteitsniveaus: Kritiek, Hoog, Gemiddeld en LaagProbeer aan elk van de volgende defecten de juiste prioriteit toe te kennen:

1. De website is te traag.
2. De inlogfunctie van de website werkt niet naar behoren.
3. De gebruikersinterface van de website wordt niet correct weergegeven op mobiel toestellen.
4. De website kan de gebruikerssessie niet onthouden.
5. Sommige links werken niet.

Hieronder vindt u de aanbevolen antwoorden:

Nee.	Beschrijving	Prioriteit	Uitleg
1	De prestaties van de website zijn te traag	Hoge	Prestatieproblemen veroorzaken grote overlast voor eindgebruikers.
2	De inlogfunctie werkt niet naar behoren.	kritisch	Inloggen is een essentiële functie van een bankwebsite. Als dit mislukt, wordt het hele gebruikerstraject geblokkeerd.
3	De gebruikersinterface wordt niet correct weergegeven op mobiele apparaten.	Medium	Het defect treft gebruikers die de website op smartphones bekijken.
4	De website kan de gebruikersaanmeldingssessie niet onthouden.	Hoge	Gebruikers kunnen wel inloggen, maar geen verdere transacties uitvoeren.
5	Sommige links werken niet	Laag	Een eenvoudige oplossing voor ontwikkelaars, en gebruikers kunnen de rest van de site nog steeds bezoeken.

Stap 3) Probleemoplossing

Defectoplossing In softwaretesten is het oplossen van defecten een stapsgewijs proces. Het oplossingsproces begint met het toewijzen van defecten aan ontwikkelaars, die vervolgens de oplossingen inplannen op basis van prioriteit, de correcties implementeren en ten slotte een oplossingsrapport terugsturen naar de testmanager. Deze volgorde maakt defecten tracTransparant en verantwoordelijk.

Je kunt de volgende stappen volgen om een ​​defect te verhelpen:

• Opdracht: Het defect wordt toegewezen aan een ontwikkelaar of technicus, en de status ervan verandert naar reageren.
• Vastleggen van het schema: Het ontwikkelteam neemt het over en stelt een reparatieschema op basis van de prioriteit van de defecten.
• Verhelp het defect: Terwijl de ontwikkelaars de fouten herstellen, is de testmanager tracks voortgang ten opzichte van het geplande schema.
• Rapporteer de resolutie: Ontwikkelaars sturen een rapport waarin wordt bevestigd welke defecten zijn verholpen en hoe.

Stap 4) Verificatie

Nadat het ontwikkelingsteam vast en gerapporteerd de defecten, het testteam gecontroleerd dat de problemen zijn opgelost.

Als het ontwikkelteam bijvoorbeeld meldt dat 61 defecten zijn verholpen, test het testteam elk defect opnieuw om te bevestigen of de oplossingen correct werken onder dezelfde omstandigheden die de oorspronkelijke fout veroorzaakten.

Stap 5) Sluiting

Zodra een defect is verholpen en geverifieerd, wordt de status ervan gewijzigd naar GeslotenAls het defect tijdens de verificatie niet naar behoren is opgelost, moet u een melding terugsturen naar het ontwikkelteam zodat zij het opnieuw kunnen onderzoeken. Sluiting geeft aan dat het defect niet langer actief is in het systeem.

Stap 6) Rapportage van defecten

Rapportage van defecten In softwaretesten is het het proces waarbij testmanagers de status van defecten voorbereiden en delen met het managementteam. Het managementteam beoordeelt het rapport en geeft feedback of extra ondersteuning indien nodig. Het rapporteren van defecten verbetert de communicatie. trackoning, en zichtbaarheid rondom defecten.

Het management heeft het recht om de status van de defecten te kennen om het project effectief te kunnen ondersteunen. Daarom moet u regelmatig rapporteren over de actuele defectensituatie, zodat zij de nodige begeleiding en middelen kunnen bieden.

Belangrijke defectstatistieken

Terugkerend naar het oorspronkelijke scenario, bekijken de ontwikkelaars- en testteams de defecten samen. De gecombineerde resultaten worden hieronder weergegeven.

Hoe kun je de kwaliteit van de testuitvoering meten en evalueren?

Dit is een cruciale vraag voor iedereen. Testmanager wil antwoorden. Twee belangrijke parameters worden doorgaans gebruikt:

In het bovenstaande scenario, de Defect Rejection Ratio (DRR) wordt berekend als 20/84 = 0.238 (23.8%).

Laten we als ander voorbeeld eens aannemen dat... GuruDe website van 99 Bank heeft in totaal... 64 defecten, maar het testteam detecteert er slechts enkele. 44 - betekenis 20 Er werden gebreken over het hoofd gezien. De Defect Leakage Ratio (DLR) wordt berekend als 20/64 = 0.312 (31.2%).

Samenvattend wordt de kwaliteit van de testuitvoering beoordeeld aan de hand van de twee onderstaande parameters:

Hoe kleiner de DRR- en DLR-waarden, hoe beter de kwaliteit van de testuitvoering. Het acceptabele bereik wordt over het algemeen bepaald door projectdoelstellingen of vergeleken met vergelijkbare projecten. In dit voorbeeld is het aanbevolen acceptabele bereik: 5% tot 10%De huidige uitvoering valt buiten dit bereik, wat aangeeft dat de testkwaliteit verbeterd moet worden door middel van de volgende maatregelen:

• Verbeteren de testvaardigheden van teamleden.
• Besteed meer tijd bij het uitvoeren van tests, met name bij het beoordelen van de uitvoeringsresultaten.

Beste werkwijzen voor effectief defectbeheer

Het volgen van gestructureerde best practices is wat een volwassen defectmanagementproces onderscheidt van een chaotisch proces. Het doel is niet alleen om bugs te verhelpen, maar om een ​​systeem te creëren dat voorkomt dat ze in productie terechtkomen en communicatiestoringen tussen testers en ontwikkelaars minimaliseert.

Dit zijn de beste werkwijzen die beginnende en gevorderde testers direct zouden moeten toepassen:

1. Standaardiseer het sjabloon voor defecten: Gebruik een standaard sjabloon voor defectrapporten met velden zoals Defect-ID, DescriptIon, Stappen om te reproduceren, Ernst, Prioriteit, Omgeving en Bijlagen. Consistentie vermindert de heen-en-weer communicatie tussen testers en ontwikkelaars.
2. Geef prioriteit voordat u taken toewijst: Categoriseer defecten altijd op ernst en prioriteit voordat u ze naar de ontwikkelaars stuurt. Dit zorgt ervoor dat kritieke problemen niet ondersneeuwen door cosmetische problemen.
3. Reproduceer het probleem voordat u het meldt: Reproduceer het defect minstens twee keer in een schone omgeving voordat u het meldt. Reproduceerbare defecten worden sneller verholpen en verlagen het afkeuringspercentage.
4. Neem een ​​defect aan trackoningsgereedschap: Gebruik hulpmiddelen zoals: JIRA, Bugzillaof Mantis centraliseren trackoning, geschiedenis en verslaggeving.
5. Voer triagevergaderingen uit: Houd korte, gerichte vergaderingen voor het prioriteren van defecten om de prioriteiten tussen de QA-, ontwikkelings- en productteams op elkaar af te stemmen.
6. Lekkage en afstoting meten: Track DLR en DRR elke sprint of cyclus. Een stijgend lekpercentage is een vroege waarschuwing dat de testdekking onvolledig is.
7. Voer een oorzaakanalyse uit: Voer bij terugkerende of ernstige defecten een oorzaakanalyse uit, zodat hetzelfde type bug niet opnieuw voorkomt in toekomstige releases.
8. Sluit de cirkel met rapportage: Deel wekelijks dashboards met defecten met belanghebbenden, zodat problemen zichtbaar en oplosbaar blijven.

Als deze werkwijzen consequent worden toegepast, stabiliseren ze de levenscyclus van defecten en verhogen ze de algehele kwaliteit van elke release.

Bronnen:

Download een voorbeeldsjabloon voor defectrapportage

Veelgestelde vragen