Wanneer moet u stoppen met testen (exitcriteria bij softwaretests)

when stop testing

Exit-criteria bij testen:

'Een goed begin is het halve werk' - Geldt overal, zelfs software testen.

Vaak zien we softwaretesters bij aanvang van het project erg enthousiast. We creëren testen van documenten zoals Teststrategie, Testplan of Testcases gretig en enthousiast.

Daarna gaan we software testen met een BANG! Dit wordt alleen versterkt door de interessante gebreken die we aan het begin van het project aantreffen. Het oplossen van deze problemen zal alleen maar bijdragen aan onze prestatie.

Als we heel veel defecten vinden en de eerste run voltooien, gaan we verder met de volgende fase. Als we bij de tweede run komen, ontspannen we ons enigszins en dat geldt ook voor de algemene menselijke neiging van verveeld raken met het testen van hetzelfde in de tweede run.

informatica interviewvragen en antwoorden voor 5 jaar ervaring

Veel testers hebben het gevoel dat het wordt eentonig werk in latere runs en beginnen de interesse in het steeds opnieuw testen van dezelfde software te verliezen. Wanneer we bij, misschien de derde run, komen, begint een vraag ons te achtervolgen en dat is 'Wanneer moet u stoppen met het testen van de software?'

Ik wed dat je hetzelfde gevoeld hebt en ten minste één keer hebt gevraagd: 'Wanneer moet je stoppen met testen?'. Ik zou zeggen dat de vraag is 'Wanneer, waar en hoe stop je met testen?' ​

Conceptueel hebben we gelezen en veel testers zijn van mening dat er geen specifieke voorwaarde of vergelijking kan zijn om te beslissen 'Wanneer stoppen met testen?' Er zijn een aantal factoren waarmee u rekening moet houden voordat we een conclusie trekken over deze vraag.

In het artikel van vandaag wil ik graag mijn mening geven over hoe we testactiviteiten kunnen afronden wanneer we een punt in onze testcyclus bereiken waarop we kunnen zeggen dat deze test voldoende is. We zullen dit doen met behulp van enkele praktijkvoorbeelden in een typische testcyclus.

Wat je leert:

• Wanneer is het genoeg testen?
• Stoppen als alle defecten zijn gevonden: is het mogelijk?
• Besluit om te stoppen met testen: exitcriteria
• Wat zijn voltooiings- of exitcriteria?
• Wat moet aanwezig zijn in exitcriteria?
• Het testen kan worden gestopt als:
• Gevolgtrekking:
• Aanbevolen literatuur

Wanneer is het genoeg testen?

Wanneer kunnen we zeggen dat zoveel testen voldoende is? Kan het testen ooit worden voltooid?

Om deze vragen te kunnen beantwoorden, zullen we testactiviteiten van begin tot eind moeten analyseren. Houd er rekening mee dat - ik ga deze activiteiten in lekentermen definiëren - niet op een chique technische manier.

Stel dat u begint met het testen van een nieuw project.

Initiële activiteiten:

• Het testteam ontvangt eisen.
• Het testteam begint planning en ontwerpen.
• Initiële testdocumenten zijn klaar en beoordeeld.

Testrun # 1)

• Het testteam start de uitvoering van de test zodra ze het ontwikkelde product hebben ontvangen.
• Tijdens de testfase voeren ze verschillende scenario's uit om de software te kraken en veel defecten op te sporen. (Ook is het defectpercentage hier hoger omdat de applicatie nieuw is en voor het eerst wordt geëvalueerd.)
• De defecten worden verholpen door ontwikkelaars en worden teruggestuurd naar het testteam voor een nieuwe test.
• Het testteam test de defecten opnieuw en voert regressie uit.
• Zodra de meeste van de zeer ernstige defecten zijn opgelost en de software er stabiel uitziet, ontwikkelteam brengt de volgende versie uit.

Testrun # 2)

• Het testteam begint met de tweede testronde en soortgelijke activiteiten worden uitgevoerd als Run 1.
• In dit proces worden tijdens de tweede testrun weinig meer defecten opgemerkt.
• De defecten worden verholpen door ontwikkelaars en teruggestuurd naar het testteam voor een nieuwe test.
• Het testteam test de defecten opnieuw en presteert regressie ​

Dit kan voor altijd doorgaan. Run 3, Run 4 en verder totdat alle defecten in de software zijn gevonden en de software geen fouten meer bevat.

Als we voor deze activiteiten een stroomschema willen tekenen, ziet het er ongeveer als volgt uit:

Uit het bovenstaande stroomschema kunnen we duidelijk concluderen dat het testen kan doorgaan totdat alle defecten in de software zijn gevonden.

Maar de vraag is: is het mogelijk om elk defect in de software te vinden? Laten we proberen het antwoord te vinden op deze vraag van een miljoen dollar :).

Stoppen als alle defecten zijn gevonden: is het mogelijk?

De meeste software is complex en heeft een enorm testbereik. Het is niet onmogelijk om alle defecten in de software te vinden, maar het zal een eeuwigheid duren.

Zelfs na het vinden van veel bugs in de software, niemand kan echt garanderen dat de software nu defectvrij is. Er kan geen situatie zijn waarin we met vertrouwen kunnen zeggen dat we de tests hebben voltooid, alle defecten in de software hebben gevonden en dat deze geen bugs meer bevat.

Bovendien is het doel van testen niet om elk defect in de software te vinden. De bedoeling van softwaretests is om te bewijzen dat de software werkt zoals bedoeld door deze te breken of door een afwijking te vinden tussen het huidige gedrag en het verwachte gedrag.

Er zijn onbeperkte defecten in software en daarom is het onpraktisch om het te testen totdat alle defecten zijn gevonden, omdat we nooit kunnen weten welk defect het laatste is. De waarheid is dat we niet kunnen vertrouwen op het vinden van alle defecten in de software om onze tests af te ronden.

Eerlijk gezegd is testen eindeloos en zullen testcycli doorgaan totdat er een beslissing is genomen wanneer en waar te stoppen. Nu wordt het nog ingewikkelder om tot een besluit te komen om te stoppen met testen. Als 'stoppen als alle defecten zijn gevonden' niet het criterium is om te stoppen met testen, op welke basis moet dan worden besloten?

Besluit om te stoppen met testen: Exit criteria

Laten we het nu proberen te begrijpen: wat zijn de belangrijkste factoren waarmee rekening moet worden gehouden bij het afronden van testactiviteiten? Ik voel dat de beslissing om te stoppen met testen grotendeels afhankelijk is van Tijd, budget en omvang van testen.

De meest gebruikelijke aanpak is om te stoppen wanneer de tijd / het budget is opgebruikt of alle testscenario's zijn uitgevoerd. Met deze aanpak doen we echter concessies aan de kwaliteit van het testen en dit geeft onvoldoende vertrouwen in de software; hoe?

Laten we eens kijken met eenvoorbeeld​

Testscenario:

Stel dat u een softwaremodule test. U hebt een bepaald budget toegewezen gekregen om dit te dekken. De projecttijdlijnen zijn voor een maand. Het totale aantal testscenario's is 200. U bent de enige die deze module test.

Scenario 1)

Week 1: U vindt de showstopper / ernst 1 defect op dag 1 en de volledige test wordt 3 dagen geblokkeerd. Daarom kunt u geen van de scenario's uitvoeren totdat het defect van Severity 1 is opgelost. Na het verlies van 3 dagen is de blokkering opgelost en gaat u verder met uw uitvoering.

Aan het einde van de week voltooit u 20 scenario's met enkele belangrijkere hoogtepunten prioriteitsgebreken ​

Week 2: Je begint met het testen van de software en legt meer focus op het opsporen van defecten. Je opent nog een paar Severity 1, Severity 2 en Severity 3 defecten tijdens de tweede week en aan het einde van de week kun je 70 scenario's behandelen.

Week 3: Aan het begin van de 3^rdweek krijg je alle defecten met hoge prioriteit opgelost, dus samen met de uitvoering van lopende scenario's moet je nu alle defecten die in de testemmer zijn beland opnieuw testen. Als u doorgaat met de goede voortgang, behandelt u 120 scenario's met aanvullende defecten.

Tegen die tijd zijn alle defecten met hoge prioriteit al gevonden en gerapporteerd. Dus nu heb je nog maar Severity 3 defecten te vinden.

Week 4: In week 4 moet u de meeste geopende defecten en de resterende 80 scenario's opnieuw testen. Hiermee kunt u tegen het einde van week 4 tot 180 scenario's voltooien met alle defecten met hoge en gemiddelde prioriteit opgelost en opnieuw getest.

Deze informatie in tabelvorm plaatsen:

Moet je hier stoppen?

De reden dat je uitgeput bent Testtijd volledig en hebben de meeste defecten met hoge prioriteit gemeld en opgelost. Geeft het stoppen op dit punt u vertrouwen in de software? Niet echt vanwege onderstaande redenen:

• Scenario's worden niet volledig uitgevoerd.
• Weinig stromen worden niet eens één keer getest.
• Alle scenario's die worden behandeld, worden slechts één keer uitgevoerd.
• Software heeft nog steeds defecten.
• Regressie wordt niet gedekt.

Scenario # 2)

Week 1: U vindt een defect van Severity 1 op dag 1 en het volledige testen wordt 3 dagen geblokkeerd. Daarom kunt u geen van de scenario's uitvoeren totdat Severity 1 Defect is opgelost. Na het verliezen van 3 dagen is de blokkering opgelost en gaat u verder met uw uitvoering.

Aan het einde van de week voltooit u 20 scenario's met nog enkele defecten. Deze week blijft hetzelfde als Scenario 1.

Week 2: Je opent nog enkele Severity 1-, Severity 2- en Severity 3-defecten tijdens de tweede week, maar de focus ligt op het behandelen van meer scenario's om de achterstand van week 1 te dekken. Aan het einde van de week kun je 120 scenario's behandelen.

Week 3: Aan het begin van de 3^rdweek krijg je alle openstaande defecten opgelost, dus samen met de uitvoering van lopende scenario's moet je nu alle defecten die in een testemmer terechtkomen opnieuw testen. Aan het einde nog steeds met goede vooruitgang, wordt het aantal voltooide scenario's 200 met extra defecten.

Nu kunt u alleen Severity 2- en Severity 3-defecten melden.

Deze informatie in tabelvorm plaatsen:

Moet je hier stoppen?

Jij hebt omvatte alle testscenario's volledig een keer en hebben enkele grote defecten geopend. Geeft het stoppen op dit punt u vertrouwen in de software?

Niet echt vanwege onderstaande redenen:

• Alle scenario's worden slechts één keer uitgevoerd.
• Software heeft nog steeds veel grote gebreken.
• Regressie wordt niet gedekt.

We kunnen zien dat de kwaliteit in het gedrang komt in beide scenario's. De beste aanpak is het vinden van een punt waar alle factoren uit scenario 1 en scenario 2 aan bod komen en de kwaliteit ook niet in het gedrang komt. Om dit te bereiken, zullen we aan het begin van het testen bepaalde criteria moeten definiëren.

de beste gratis mp3-downloader voor Android

Deze criteria worden Voltooiings- of Exitcriteria genoemd. Het is het antwoord op onze vraag - 'Wanneer stoppen met testen?'.

Wat zijn voltooiings- of exitcriteria?

De exitcriteria worden aan het einde van de testcyclus geëvalueerd en vastgelegd in Testplan. Het is de reeks voorwaarden of activiteiten waaraan moet worden voldaan om het testen af ​​te ronden.

De exitcriteria bepalen hoeveel testen voldoende is en wanneer testactiviteiten voltooid kunnen worden verklaard. Dekking en voltooiingscriteria worden gecombineerd om exitcriteria voor testen te definiëren.

Wat moet aanwezig zijn in exitcriteria?

Idealiter worden exit- of stopcriteria gedefinieerd door verschillende factoren te combineren en daarom uniek voor alle projecten. Het hangt af van de projectvereisten en moet daarom tijdens de testplanning worden gedefinieerd; aan het begin van het project. Parameters die erin zijn gedefinieerd, moeten zoveel mogelijk worden gekwantificeerd.

Hieronder staan ​​enkele punten waarmee rekening moet worden gehouden bij het definiëren van exitcriteria in het geval van functionele of systeemtests. U kunt enkele of alle onderstaande factoren combineren terwijl u beslist waar u wilt stoppen met testen volgens uw projectbehoeften.

Het testen kan worden gestopt als:

Vereisten:

• 100% dekking van de vereisten is bereikt.

Gebreken:

• Het gedefinieerde / gewenste aantal defecten is bereikt.
• Alle Show Stopper-defecten of -blokkers zijn opgelost en geen bekend Critical / Severity 1-defect bevindt zich in de status Open.
• Alle defecten met hoge prioriteit worden geïdentificeerd en verholpen.
• Het defectpercentage valt onder het gedefinieerde aanvaardbare percentage.
• Zeer weinig defecten met gemiddelde prioriteit zijn open en hebben een tijdelijke oplossing.
• Zeer weinig open defecten met een lage prioriteit die geen invloed hebben op het softwaregebruik.
• Alle defecten met hoge prioriteit worden opnieuw getest en gesloten en de bijbehorende regressiescenario's worden met succes uitgevoerd.

Testdekking:

• De testdekking moet voor 95% worden bereikt.
• Het slagingspercentage van de testcase moet 95% zijn. Dit kan worden berekend met een formule
  • (Totaal aantal behaalde TC's / Totaal aantal TC's) * 100.
• Alle kritische testgevallen zijn geslaagd.
• 5% Testgevallen kunnen mislukken, maar de mislukte testgevallen hebben een lage prioriteit.
• Volledige functionele dekking wordt bereikt.
• Alle belangrijke functionele / zakelijke stromen worden succesvol uitgevoerd met verschillende inputs en werken prima.

Deadlines:

• Deadline voor project of deadline voor einde van test is bereikt.

Test documenten:

• Alle testdocumenten / deliverables (voorbeeld - Samenvatting testrapport ) worden voorbereid, beoordeeld en gepubliceerd.

Begroting:

• Het volledige testbudget is op.

'Go / No Go' -vergaderingen:

• ​ Wel of niet doorgaan ​ vergadering is uitgevoerd met belanghebbenden en er wordt besloten of het project naar productie moet gaan of niet.

Gevolgtrekking:

Laten we het aan het eind heel eenvoudig maken.

Beantwoord vragen met een simpel ja of nee.

Als u de meeste antwoorden met Ja krijgt, betekent dit dat u op dit punt kunt stoppen met testen. Als de meeste antwoorden Nee zijn, betekent dit dat u moet controleren wat er ontbreekt tijdens het testen en dit kan u helpen een ontsnappend productiefout te vinden :)

• Worden alle testcases minimaal één keer uitgevoerd?
• Is het slagingspercentage van de testcase zoals gedefinieerd?
• Is de volledige testdekking bereikt?
• Worden alle functionele / bedrijfsstromen minimaal één keer uitgevoerd?
• Is het vastgestelde aantal defecten bereikt?
• Zijn alle belangrijke defecten met hoge prioriteit verholpen en verholpen?
• Zijn alle defecten opnieuw getest en gesloten?
• Is er regressie uitgevoerd voor alle open defecten?
• Heeft u het testbudget opgebruikt?
• Is de eindtijd van het testen bereikt?
• Worden alle testresultaten beoordeeld en gepubliceerd?

Over de auteur: Dit is een gastartikel van Renuka K. Ze heeft meer dan 11 jaar ervaring in het testen van software.

Ik hoop dat dit artikel je heeft geholpen. Ik zou ook graag uw mening / opmerkingen over het onderwerp willen horen.

Veel plezier met testen!

Aanbevolen literatuur

• Beste softwaretesttools 2021 (QA Test Automation Tools)
• Software testen QA Assistant Job
• Software Testcursus Syllabus - Online cursus Gedetailleerd trainingsplan
• Software Testing-cursus: bij welk Software Testing Institute moet ik me aansluiten?
• Softwaretests kiezen als uw carrière
• Softwaretest Schrijver van technische inhoud Freelancer-baan
• Enkele interessante sollicitatievragen voor het testen van software
• Feedback en recensies over softwaretestcursussen