Wat is een bug?
Een bug is het gevolg / resultaat van een coderingsfout.
Defect in softwaretests
Een defect in softwaretests is een variatie of afwijking van de softwareapplicatie van de vereisten van de eindgebruiker of de oorspronkelijke zakelijke vereisten. Een softwarefout is een coderingsfout die onjuiste of onverwachte resultaten veroorzaakt van een softwareprogramma dat niet aan de werkelijke vereisten voldoet. Testers kunnen dergelijke defecten tegenkomen tijdens het uitvoeren van de testcases.
Deze twee termen hebben een zeer dunne lijn van verschillen. In de industrie zijn beide fouten die moeten worden verholpen en dus onderling uitwisselbaar zijn die door sommige van de testteams worden gebruikt.
Wanneer testers de testcases uitvoeren, kunnen ze dergelijke testresultaten tegenkomen die in tegenspraak zijn met de verwachte resultaten. Deze variatie in testresultaten wordt een softwarefout genoemd. Deze defecten of variaties worden in verschillende organisaties met verschillende namen aangeduid, zoals issues, problemen, bugs of incidenten.
In deze tutorial leer je-
- Bug report
- Defectenbeheerproces
- Ontdekking
- Categorisering
- Resolutie
- Verificatie
- Sluiting
- Rapporteren
- Belangrijke defectstatistieken
Bugrapport bij softwaretests
Een bugrapport bij softwaretests is een gedetailleerd document over bugs die zijn aangetroffen in de softwareapplicatie. Bugrapport bevat elk detail over bugs, zoals beschrijving, datum waarop de bug werd gevonden, naam van de tester die de bug heeft gevonden, naam van de ontwikkelaar die de bug heeft gerepareerd, etc. Bugrapport helpt bij het identificeren van soortgelijke bugs in de toekomst, zodat het kan worden vermeden.
Als u de bug aan de ontwikkelaar rapporteert, moet uw bugrapport de volgende informatie bevatten
- Defect_ID - Uniek identificatienummer voor het defect.
- Defect Description - Gedetailleerde beschrijving van het Defect inclusief informatie over de module waarin het Defect werd gevonden.
- Versie - Versie van de applicatie waarin het defect is gevonden.
- Stappen - Gedetailleerde stappen samen met schermafbeeldingen waarmee de ontwikkelaar de defecten kan reproduceren.
- Date Raised - Datum waarop het defect is opgetreden
- Referentie - waar in u Geef een verwijzing naar de documenten zoals. vereisten, ontwerp, architectuur of misschien zelfs screenshots van de fout om het defect te helpen begrijpen
- Gedetecteerd door - Naam / ID van de tester die het defect heeft gemeld
- Status - Status van het defect, hierover later meer
- Opgelost door - Naam / ID van de ontwikkelaar die het heeft gerepareerd
- Datum gesloten - Datum waarop het defect is gesloten
- Ernst die de impact van het defect op de applicatie beschrijft
- Prioriteit die verband houdt met urgentie voor het verhelpen van defecten. Prioriteit van ernst kan hoog / gemiddeld / laag zijn op basis van de urgentie van de impact waarop het defect moet worden verholpen
Klik hier als de video niet toegankelijk is
Middelen
Download een voorbeeld van een defectrapportagesjabloon
Overweeg het volgende als testmanager
Uw team heeft bugs gevonden tijdens het testen van het Guru99 Banking-project.
Na een week reageert de ontwikkelaar -
Volgende week reageert de tester
Zoals in het bovenstaande geval, als de defecte communicatie mondeling wordt gedaan, worden de zaken al snel erg gecompliceerd. Om bugs te beheersen en effectief te beheren, heeft u een defectlevenscyclus nodig.
Wat is het proces voor defectbeheer?
Defect Management is een systematisch proces om bugs te identificeren en op te lossen. Een defectbeheercyclus omvat de volgende fasen: 1) Ontdekking van defect, 2) categorisering van defecten 3) Fixing van defecten door ontwikkelaars 4) Verificatie door testers, 5) Afsluiting van defecten 6) Rapportage van defecten aan het einde van het project
In dit onderwerp wordt uitgelegd hoe u het defectbeheerproces toepast op de website van de Guru99 Bank van het project. U kunt de onderstaande stappen volgen om defecten te beheren.
Ontdekking
In de ontdekkingsfase moeten de projectteams zoveel mogelijk defecten ontdekken , voordat de eindklant het kan ontdekken. Er wordt gezegd dat een defect wordt ontdekt en verandert in de status geaccepteerd wanneer het wordt erkend en geaccepteerd door de ontwikkelaars
In het bovenstaande scenario ontdekten de testers 84 defecten in de website Guru99.
Laten we eens kijken naar het volgende scenario; uw testteam heeft enkele problemen ontdekt op de website van Guru99 Bank. Ze beschouwen ze als defecten en rapporteerden aan het ontwikkelingsteam, maar er is een conflict -
Wat ga je dan als Test Manager doen?
A) Ben het eens met het testteam dat het een defect is
B) Test Manager neemt de rol van rechter op zich om te beslissen of het probleem defect is of niet
C) Spreek af met het ontwikkelingsteam dat dit geen defect is Juist Onjuist
In dat geval moet een oplossingsproces worden toegepast om het conflict op te lossen, u neemt de rol van rechter op zich om te beslissen of het websiteprobleem een defect is of niet.
Categorisering
Het categoriseren van defecten helpt de softwareontwikkelaars om hun taken te prioriteren. Dat betekent dat dit soort prioriteit de ontwikkelaars helpt om eerst die defecten op te lossen die zeer cruciaal zijn.
Defecten worden meestal gecategoriseerd door de Test Manager -
Laten we een kleine oefening doen als het volgende: Drag & Drop de Defect Priority Below
- Kritisch
- Hoog
- Medium
- Laag
| 1) De prestaties van de website zijn te traag |
|
| 2) De inlogfunctie van de website werkt niet naar behoren |
|
| 3) De GUI van de website wordt niet correct weergegeven op mobiele apparaten |
|
| 4) De website kon de inlogsessie van de gebruiker niet herinneren |
|
| 5) Sommige links werken niet |
|
Hier zijn de aanbevolen antwoorden
| Nee. | Omschrijving | Prioriteit | Uitleg |
|---|---|---|---|
| 1 | De prestaties van de website zijn te traag | Hoog | De prestatiebug kan de gebruiker enorm veel ongemak bezorgen. |
| 2 | De inlogfunctie van de website werkt niet naar behoren | Kritisch | Inloggen is een van de belangrijkste functies van de bankwebsite als deze functie niet werkt, het zijn ernstige bugs |
| 3 | De GUI van de website wordt niet correct weergegeven op mobiele apparaten | Medium | Het defect is van invloed op de gebruiker die smartphone gebruikt om de website te bekijken. |
| 4 | De website kon de inlogsessie van de gebruiker niet herinneren | Hoog | Dit is een ernstig 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 |
Oplossing van defecten
Het oplossen van defecten 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, vervolgens plannen ontwikkelaars het defect volgens prioriteit te verhelpen, vervolgens worden defecten opgelost en ten slotte sturen de ontwikkelaars een rapport van oplossing naar de testmanager. Dit proces helpt om defecten gemakkelijk op te lossen en op te sporen.
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 .
- Schema oplossen : de ontwikkelaar neemt de leiding in deze fase. Ze zullen een schema opstellen om deze defecten op te lossen, afhankelijk van de prioriteit van het defect.
- Het defect verhelpen : terwijl het ontwikkelingsteam de defecten oplost, volgt de testmanager het proces van het repareren van defecten in vergelijking met het bovenstaande schema.
- Rapporteer de oplossing : ontvang een rapport van de oplossing van ontwikkelaars wanneer defecten zijn verholpen.
Verificatie
Na het ontwikkelingsteam vast en meldde het defect, het testen team verifieert dat de gebreken daadwerkelijk opgelost.
Als het ontwikkelingsteam bijvoorbeeld in het bovenstaande scenario meldde dat ze al 61 defecten hadden verholpen, testte uw team opnieuw om te verifiëren dat deze defecten daadwerkelijk waren verholpen of niet.
Sluiting
Zodra een defect is verholpen en geverifieerd, wordt het defect van status gewijzigd naar gesloten . Is dit niet het geval, dan heeft u een melding naar de ontwikkeling gestuurd om het defect nogmaals te controleren.
Defectrapportage
Defectrapportage bij softwaretests is een proces waarin testmanagers het defectrapport voorbereiden en naar het managementteam sturen voor feedback over het defectmanagementproces en de status van defecten. Vervolgens controleert het managementteam de defectrapportage en stuurt feedback of biedt indien nodig verdere ondersteuning. Defectrapportage helpt om defecten beter te communiceren, op te sporen en uit te leggen.
De directie heeft het recht de defectstatus te kennen. Ze moeten het defectmanagementproces begrijpen om u bij dit project te ondersteunen. Daarom moet u hen de huidige defectsituatie melden om feedback van hen te krijgen.
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 kun je berekenen dat de defection rejection ratio (DRR) 20/84 = 0,238 (23,8%) is.
Een ander voorbeeld, veronderstelt dat de Guru99 Bank-website in totaal 64 defecten heeft, maar uw testteam detecteert slechts 44 defecten, dwz ze hebben 20 defecten gemist . Daarom kunt u berekenen dat de defectlekratio (DLR) 20/64 = 0,312 (31,2%) is.
Conclusie: de kwaliteit van de testuitvoering wordt beoordeeld aan de hand van de volgende twee parameters
De kleinere waarde van DRR en DLR is, de betere kwaliteit van de testuitvoering. Wat is het verhoudingsbereik dat acceptabel is ? Dit bereik kan worden gedefinieerd en geaccepteerd als basis in het projectdoel of u kunt verwijzen naar de statistieken van vergelijkbare projecten.
In dit project is de aanbevolen waarde van een acceptabele verhouding 5 ~ 10%. Het betekent dat de kwaliteit van de testuitvoering laag is. U moet tegenmaatregelen vinden om deze verhoudingen te verminderen, zoals
- Verbeter de testvaardigheden van het lid.
- Besteed meer tijd aan het testen van de uitvoering, vooral aan het bekijken van de testuitvoeringsresultaten.