Defectbeheerproces bij het testen van software
Thomas Hamilton
Wat is een defectbeheerproces?
Defect Management is een systematisch proces om bugs te identificeren en te repareren. Een defect management cyclus bevat de volgende fasen: 1) Ontdekking van defect, 2) Defect categorisering, 3) Het repareren van defect door ontwikkelaars, 4) Verificatie door testers, 5) Defect sluiting, 6) Defect rapporten aan het einde van het project.
Dit onderwerp zal u helpen bij het toepassen van het defectbeheerproces op de projectwebsite van Guru99 Bank. U kunt de onderstaande stappen volgen om defecten te beheren.
Stap 1) Ontdekking
In de ontdekkingsfase moeten de projectteams ontdekken hoe veel gebreken als mogelijk, voordat de eindklant het kan ontdekken. Er wordt gezegd dat een defect is ontdekt en van status verandert aanvaard wanneer het wordt erkend en geaccepteerd door de ontwikkelaars
In het bovenstaande scenario ontdekten de testers 84 fouten in de website Guru99.
Laten we eens kijken naar het volgende scenario; uw testteam ontdekte een aantal problemen op de Guru99 Bank-website. Ze beschouwen deze als defecten en rapporteerden dit aan het ontwikkelingsteam, maar er is een conflict –
Wat ga je in zo’n geval doen als Testmanager?
B) Testmanager neemt de rol van rechter op zich om te beslissen of het probleem een defect is of niet
C) Ben het met het ontwikkelteam eens dat dit geen defect is
In dat geval moet een oplossingsproces worden toegepast om het conflict op te lossen, waarbij u de rol van rechter op zich neemt om te beslissen of het probleem met de website een defect is of niet.
Stap 2) Categorisatie
Door defecten te categoriseren kunnen softwareontwikkelaars hun taken prioriteren. Dat betekent dat dit soort prioriteit de ontwikkelaars helpt bij het eerst oplossen van de defecten die zeer cruciaal zijn.
Defecten worden meestal gecategoriseerd door de Testmanager –
Laten we een kleine oefening doen zoals hieronder
Sleep de defectprioriteit hieronder| 1) De prestaties van de website zijn te traag |
|
| 2) De inlogfunctie van de website werkt niet goed |
|
| 3) De GUI van de website wordt niet correct weergegeven Mobile apparaten |
|
| 4) De website kon de inlogsessie van de gebruiker niet onthouden |
|
| 5) Sommige links werken niet |
|
Hier zijn de aanbevolen antwoorden
| Nr. | Technische Beschrijving | Prioriteit | Uitleg |
|---|---|---|---|
|
1 |
De prestaties van de website zijn te traag |
Hoog |
De prestatiefout kan voor de gebruiker enorm ongemak veroorzaken. |
|
2 |
De inlogfunctie van de website werkt niet goed |
kritisch |
Inloggen is een van de belangrijkste functies van de bankwebsite. Als deze functie niet werkt, zijn er ernstige bugs |
|
3 |
De GUI van de website wordt niet correct weergegeven op mobiele apparaten |
Medium |
Het defect treft de gebruiker die een smartphone gebruikt om de website te bekijken. |
|
4 |
De website kon de inlogsessie van de gebruiker niet onthouden |
Hoog |
Dit is een serieus probleem, aangezien de gebruiker wel kan inloggen, maar geen verdere transacties kan uitvoeren |
|
5 |
Sommige links werken niet |
Laag |
Dit is een gemakkelijke oplossing voor ontwikkelaars en de gebruiker heeft nog steeds toegang tot de site zonder deze links |
Stap 3) Probleemoplossing
Defectoplossing bij het testen van software is een stapsgewijs proces om de defecten op te lossen. Het proces voor het oplossen van defecten begint met het toewijzen van defecten aan ontwikkelaars, waarna ontwikkelaars plannen dat het defect volgens prioriteit wordt verholpen, vervolgens worden defecten verholpen en ten slotte sturen ontwikkelaars een oplossingsrapport naar de testmanager. Dit proces helpt om defecten eenvoudig op te lossen en te volgen.
U kunt de volgende stappen volgen om het defect te verhelpen.
- Toewijzing: toegewezen aan een ontwikkelaar of andere technicus om te repareren, en de status gewijzigd in reageren.
- Planning repareren: De ontwikkelaarskant neemt in deze fase de leiding. Ze zullen een schema opstellen om deze defecten op te lossen, afhankelijk van de prioriteit van het defect.
- Herstel het defect: Terwijl het ontwikkelingsteam de defecten repareert, volgt de Testmanager het proces van het repareren van de defecten, in vergelijking met het bovenstaande schema.
- Rapporteer de resolutie: ontvang een rapport van de oplossing van ontwikkelaars wanneer defecten zijn verholpen.
Stap 4) Verificatie
Na het ontwikkelteam vast en gerapporteerd het defect, het testteam gecontroleerd dat de gebreken daadwerkelijk zijn opgelost.
In het bovenstaande scenario bijvoorbeeld, wanneer het ontwikkelingsteam rapporteerde dat ze al 61 defecten hadden verholpen, zou jouw team opnieuw testen om te verifiëren of deze defecten daadwerkelijk waren verholpen of niet.
Stap 5) Sluiting
Zodra een defect is opgelost en geverifieerd, wordt de status van het defect gewijzigd als CLOSED. Als dit niet het geval is, moet u een melding naar de ontwikkeling sturen om het defect opnieuw te controleren.
Stap 6) Rapportage van defecten
Rapportage van defecten bij het testen van software is een proces waarbij testmanagers het defectrapport voorbereiden en naar het managementteam sturen voor feedback over het defectbeheerproces en de status van defecten. Vervolgens controleert het managementteam de defectmelding en stuurt feedback of biedt indien nodig verdere ondersteuning. Het rapporteren van defecten helpt bij het beter communiceren, volgen en gedetailleerd uitleggen van defecten.
De directie heeft het recht om de status van het defect te kennen. Zij moeten het defectmanagementproces begrijpen om u bij dit project te kunnen ondersteunen. Daarom moet u hen de huidige defectsituatie melden om feedback van hen te krijgen.
Waarom heeft u een defectbeheerproces nodig?
Uw team heeft bugs gevonden tijdens het testen van het Guru99 Banking-project.
Na een week reageert de ontwikkelaar –
Volgende week reageert de tester
Als de defecte communicatie mondeling plaatsvindt, worden de zaken, net als in het bovenstaande geval, al snel erg ingewikkeld. Om bugs onder controle te houden en effectief te beheren, heb je een levenscyclus van defecten nodig.
Belangrijke defectstatistieken
Steun het bovenstaande scenario. De ontwikkelaars- en testteams hebben de gemelde defecten beoordeeld. Hier is het resultaat van die discussie
Hoe meet en evalueer je de kwaliteit van de testuitvoering?
Dit is een vraag die elke Testmanager wil weten. Er zijn 2 parameters die u als volgt kunt beschouwen
In het bovenstaande scenario kunt u de afwijzingsratio van afvalligheid (DRR) is 20/84 = 0.238 (23.8%).
Een ander voorbeeld, verondersteld dat de website van Guru99 Bank total 64 defecten, maar uw testteam detecteert deze alleen 44 gebreken, dat wil zeggen dat ze gemist hebben 20 gebreken. Daarom kunt u berekenen dat de defectlekkageverhouding (DLR) 20/64 = is 0.312 (31.2%).
Conclusie: de kwaliteit van de uitvoering van de test wordt geëvalueerd via de volgende twee parameters
Hoe kleiner de waarde van DRR en DLR is, des te beter is de kwaliteit van de testuitvoering. Wat is het verhoudingsbereik dat is aanvaardbaar? Dit bereik kan worden gedefinieerd en geaccepteerd op basis van het projectdoel, of u kunt de statistieken van vergelijkbare projecten raadplegen.
In dit project is de aanbevolen waarde van een acceptabele verhouding 5 ~ 10%. Het betekent dat de kwaliteit van de testuitvoering laag is. U zou tegenmaatregelen moeten vinden om deze verhoudingen te verminderen, zoals
- Verbeteren de testvaardigheden van het lid.
- Besteed meer tijd voor het testen van de uitvoering, met name voor het beoordelen van de resultaten van de uitvoering van de test.
Veelgestelde vragen
Klik hier als de video niet toegankelijk is
Bronnen:
Download een voorbeeldsjabloon voor defectrapportage