Hoe testgevallen en bugrapporten te schrijven & Amp; Wat zijn de belangrijkste componenten?

In dit artikel gaan we leren over testcases en bugrapporten en hoe je echt goede kunt schrijven, zodat het de testers en ontwikkelaars die bij het proces betrokken zijn, helpt.

Wat is een testcase?

Een testcase is een reeks acties om de functionaliteit of functie in een softwaretoepassing te verifiëren. Het bevat specifieke testen, testgegevens, preconditie, postconditie, etc. Enkele van de meest populaire tools voor testcasebeheer zijn Quality Center, JIRA, enz. Sterker nog, veel bedrijven gebruiken nog steeds Excel-sheets als het gaat om het schrijven van testcases.

Hoe testgevallen schrijven?

Het schrijven van testcases hangt volledig af van wat er door de testcase wordt gemeten. Door testcases te delen met testers en ontwikkelaars, is het mogelijk om het testproces te versnellen, maar het meeste hangt af van hoe goed testcases zijn geschreven.

Hieronder staan enkele van de integrale onderdelen van een testcase.

Stap 1: Testcase-ID

Alle testgevallen moeten een unieke ID hebben die kan worden gebruikt om ze te identificeren. Door een testcase-ID toe te wijzen, wordt het duidelijk voor de ontwikkelaar om het probleem op te lossen.

Stap 2: Beschrijving testcase

Beschrijf in detail over de eenheid, functie en functie die wordt getest of geverifieerd.

Stap 3: Aannames/randvoorwaarden

In deze stap schets je alle voorwaarden waaraan moet worden voldaan voordat de testcase wordt uitgevoerd. Een van de voorwaarden kan bijvoorbeeld zijn dat alleen een e-mail van een organisatie wordt toegestaan.

Stap 4: Testgegevens

Het verwijst naar de variabelen en hun waarden die zich in de testcase bevinden.

Stap 5: Stappen voor uitvoering

Houd er rekening mee dat deze stappen worden uitgevoerd vanuit het perspectief van een eindgebruiker, dus ze moeten gemakkelijk herhaalbaar zijn. Het inloggen op de portal kan bijvoorbeeld de volgende stappen hebben.

1. Open de portal met behulp van de URL of interne link
2. Vul je gebruikersnaam in
3. Voer wachtwoord in
4. Klik op ‘inloggen’ of ‘verzenden’.

Stap 6: Resultaat

Het toont het resultaat dat u kunt verwachten na de uitvoering van de testcasestap. Als u de juiste inloggegevens invoert, wat is dan het verwachte resultaat en waar brengt het de gebruiker naartoe.

Stap 7: Resultaat en postcondities

We kunnen de testcase bepalen op basis van het al dan niet invoeren van de juiste waarden. De post-conditie is wat er kan gebeuren als resultaat van de uitvoeringsstappen, of ze in staat zullen zijn om in te loggen of naar een pagina gestuurd te worden waar ze gevraagd worden om de informatie opnieuw in te voeren.

Stap 8: Slagen of zakken

Het bepaalt de pass/fail-status, afhankelijk van hoe het verwachte resultaat en het werkelijke resultaat zich tot elkaar verhouden.

Best practices voor het schrijven van goede testcases:

1. Testgevallen moeten eenvoudig en transparant zijn: De testgevallen moeten zo eenvoudig mogelijk zijn. Zorg ervoor dat u eenvoudige taal gebruikt, zoals ‘Klik op de startpagina’ of ‘Voer de gegevens in’, zodat het gemakkelijk is om de stappen te begrijpen.
2. Maak testcases met de eindgebruiker in gedachten: het doel van elk project is ervoor te zorgen dat het voldoet aan de verwachtingen van de eindgebruiker. Een tester moet bij het maken van testgevallen rekening houden met de eindgebruiker.
3. Testcases niet herhalen: Als een testcase nodig is voor het uitvoeren van een andere testcase, kun je de testcase aanroepen met het testcase-ID in de voorwaardekolom.
4. Houd u aan het specificatiedocument: maak niet de fout om de functionaliteit en kenmerken van de softwaretoepassing aan te nemen.
5. 100% dekking: zorg ervoor dat u testcases schrijft om alle softwarevereisten te controleren die in het specificatiedocument worden vermeld.
6. Geef de testcase-ID’s een naam zodat ze gemakkelijk kunnen worden geïdentificeerd tijdens het opsporen van defecten of het identificeren van een vereiste.
7. Laat de testcases beoordelen door je collega’s.

Wat is een bugrapport?

Het schrijven van een goed bugrapport vergroot de kans dat het wordt opgelost. Als de bug niet op de juiste manier wordt gemeld, wordt deze genegeerd door de ontwikkelaar die zegt dat deze niet duidelijk was.

Hoe schrijf je een goed bugrapport?

Een goed bugrapport moet specifiek, informatief en reproduceerbaar zijn.

Specifiek- Wanneer u de bug meldt, zorg er dan voor dat u niet treuzelt door dingen te schrijven die niet nodig zijn. Wees specifiek. Rijd recht naar het punt.

Informatief- Zorg ervoor dat u een uniek nummer toewijst aan elk van de bugs in uw rapport. Het helpt bij het identificeren van de bugrecord. Wanneer u een geautomatiseerde tool voor het melden van fouten gebruikt, wordt automatisch een nummer toegewezen.

reproduceerbaar– Als de bug niet kan worden gereproduceerd, kan deze helemaal niet worden gerepareerd. Zorg ervoor dat de bug stapsgewijs wordt gemeld. Er zijn momenten waarop het niet mogelijk is om de bug te reproduceren zoals hij is, in een dergelijk geval moet u het periodieke karakter van de bug vermelden terwijl u deze vermeldt.

Test de bug op vergelijkbare modules– Het is bekend dat ontwikkelaars dezelfde bug gebruiken voor vergelijkbare modules. In dat geval zul je de bug ook in andere modules zien verschijnen. Het is zelfs mogelijk om een meer gecompliceerde versie van de bug op een andere module te vinden.

Schrijf duidelijk– Voordat u op de verzendknop klikt, is het absoluut noodzakelijk dat u het bugrapport minstens drie keer opnieuw leest om er zeker van te zijn dat het correct is. De woorden die u gebruikt, moeten eenvoudig, duidelijk en gemakkelijk te begrijpen zijn. Probeer jargon te vermijden, tenzij absoluut noodzakelijk.

Wat zijn de onderdelen van een bugrapport?

Hieronder vindt u een voorbeeld van een bugrapport dat kan worden gebruikt voor effectieve rapportage.

Tester– Naam en e-mailadres.

Product– Het product waarin de bug is gevonden.

Version– De versie van het product waarin de bug is gevonden.

onderdeel- Belangrijkste submodules van het product

Platform – In welk hardwareplatform is de bug gevonden? PC, MAC, HP, Sun, enz. Zijn enkele van de platforms.

Besturingssysteem– Hoewel Windows, Linux, Unix, enz. Besturingssystemen zijn, moet u ervoor zorgen dat u vermeldt welke versie van het besturingssysteem het is. Zonder het exacte platform te kennen, kan het moeilijk worden voor de ontwikkelaar, omdat de bug zich anders kan gedragen, afhankelijk van de omgeving waarin de applicatie wordt gebruikt.

Prioriteit- De prioriteit van bugs wordt meestal ingesteld in het formaat P1 tot P5. P1 is de bug met de hoogste prioriteit, terwijl P5 een bug is die geen onmiddellijke aandacht vereist.

Ernst van de bug- De impact van de bug kan op vele manieren worden beschreven.

Blokker– U kunt hier niet meer op testen.

Kritiek– Deze bug kan ervoor zorgen dat de applicatie crasht.

Belangrijk– Het beïnvloedt de toepassing ernstig.

Minderjarige– Ze hebben weinig invloed op het functioneren van de app.

Bugstatus – Wanneer u zich aanmeldt bij het bugvolgsysteem, wordt de bugstatus toegewezen als ‘Nieuw’. Hierna blijft de status van de bug veranderen – opgelost, geverifieerd, opnieuw geopend, kan niet worden opgelost, enz.

Toewijzen: Vermeld het e-mailadres van de ontwikkelaar.

beschrijf het probleem: Schrijf een korte beschrijving van de bug, zodat de ontwikkelaar het probleem gemakkelijk kan begrijpen.

Conclusie:

Je bugrapport moet van hoge kwaliteit zijn, want er komt veel op je af. Stel je voor dat je door een ander probleem gaat dan het echte probleem, omdat het bugrapport niet duidelijk was geschreven. Er moet duidelijke communicatie zijn tussen de testers en ontwikkelaars, zodat ze allebei weten wat ze van elkaar kunnen verwachten. Hoewel het schrijven van een goed bugrapport de verantwoordelijkheid is van een tester, moeten de ontwikkelaars ook hun eventuele richtlijnen doorgeven.