Hvornår skal testen stoppes (udgangskriterier i softwaretest)

when stop testing

Udgangskriterier i testning:

“Godt begyndt er halvt færdig” - Gælder overalt, selv softwaretest.

Ofte ser vi softwaretestere meget begejstrede i starten af ​​projektet. Vi skaber afprøvningsdokumenter såsom teststrategi, testplan eller testcases ivrigt og entusiastisk.

Så kommer vi til at teste software med en BANG! Dette forstærkes kun af de interessante mangler, vi finder i starten af ​​projektet. At få dem løst vil kun øge vores præstation.

Da vi finder masser af mangler og gennemfører den første kørsel, går vi videre til næste fase. Når vi kommer til det andet løb, slapper vi lidt af, og det er den generelle menneskelige tendens til keder sig med at teste det samme i det andet løb.

hvad er det bedste program til fjernelse af malware

Mange testere føler, at det bliver monotont arbejde i senere kørsler og begynder at miste interessen for at teste den samme software igen og igen. Når vi når til, måske den tredje kørsel, begynder et spørgsmål at hjemsøge os, og det er 'Hvornår skal jeg stoppe med at teste softwaren?'

Jeg vedder på, at du må have følt det på samme måde og spurgt, 'Hvornår skal jeg stoppe med at teste?', Mindst en gang. Jeg vil sige, at spørgsmålet er 'Hvornår, hvor og hvordan stopper jeg testen?' :)

Konceptuelt har vi læst, og mange testere mener, at der ikke kan være en bestemt tilstand eller ligning til at beslutte 'Hvornår skal man stoppe med at teste?' Der er en række faktorer, der skal overvejes, før vi afslutter dette spørgsmål.

I dagens artikel vil jeg gerne dele mine tanker om, hvordan man kan afslutte testaktiviteter, når vi når til et punkt i vores testcyklus, hvor vi kan sige, at denne test er nok. Vi gør dette ved hjælp af et par eksempler fra det virkelige liv i en typisk testcyklus.

Hvad du lærer:

• Hvornår er det nok at teste?
• Stop, når alle mangler er fundet: Er det muligt?
• Beslutning om at stoppe testen: Afslutningskriterier
• Hvad er gennemførelse eller udgangskriterier?
• Hvad skal være til stede i udgangskriterier?
• Test kan stoppes, når:
• Konklusion:
• Anbefalet læsning

Hvornår er det nok at teste?

Hvornår kan vi sige, at så meget testning er nok? Kan test nogensinde være afsluttet?

For at besvare disse spørgsmål bliver vi nødt til at analysere testaktiviteter fra start til slut. Vær opmærksom på, at - jeg vil definere disse aktiviteter i lægmandssæt - ikke på en fancy teknisk måde.

Lad os overveje, at du begynder at teste et nyt projekt.

Indledende aktiviteter:

• Testteamet modtager krav.
• Testteamet starter planlægning og design.
• Indledende testdokumenter er klar og gennemgået.

Testkørsel # 1)

• Testteamet starter testudførelse når de modtager det udviklede produkt.
• I testfasen udfører de forskellige scenarier for at bryde softwaren og finde mange defekter. (Også mangelfrekvensen her er højere, fordi applikationen er ny og gennemgås for første gang.)
• Defekterne løses af udviklere og returneres tilbage til testteamet til gentest.
• Testteamet udfører gentest af defekterne og udfører regression.
• Når de fleste af de alvorlige mangler er løst, og softwaren ser stabil ud, udviklingsteam frigiver den næste version.

Testkørsel nr. 2)

• Testteamet starter den anden testkørsel, og lignende aktiviteter udføres som Kørsel 1.
• I denne proces under den anden testkørsel er der få flere mangler fanget.
• Defekterne løses af udviklere og returneres tilbage til testteamet for en gentest.
• Testteamet tester igen manglerne og udfører regression .

Dette kan fortsætte for evigt. Kør 3, kør 4 fremad, indtil alle mangler i softwaren er fundet, og softwaren bliver fejlfri.

Hvis vi vil tegne et rutediagram for disse aktiviteter, vil det se stort set ud som nedenfor:

Fra ovenstående flowdiagram kan vi klart konkludere, at test kan fortsætte, indtil alle mangler i softwaren er fundet.

Men spørgsmålet er - er det muligt at finde hver eneste defekt i softwaren? Lad os prøve at finde svaret på dette million dollar spørgsmål :).

Stop, når alle mangler er fundet: Er det muligt?

Mest software er kompleks og har et enormt testomfang. Det er ikke umuligt at finde alle defekter i softwaren, men det vil tage evigt.

Selv efter at have fundet mange fejl i softwaren, ingen kan faktisk garantere, at softwaren er fejlfri nu. Der kan ikke være en situation, hvor vi med sikkerhed kan sige, at vi har afsluttet testningen, fundet alle defekter i softwaren, og at den ikke har flere fejl.

Desuden er formålet med testning ikke at finde hver eneste fejl i softwaren. Hensigten med softwaretest er at bevise, at softwaren fungerer efter hensigten ved at bryde den eller finde en afvigelse mellem dens nuværende adfærd og forventede adfærd.

Der er ubegrænsede mangler i software, og derfor er det upraktisk at teste det, indtil alle mangler er fundet, da vi aldrig kan vide, hvilken mangel der er den sidste. Sandheden er, at vi ikke kan stole på at finde alle manglerne i softwaren for at afslutte vores test.

Ærligt talt er test endeløs, og testcyklusser fortsætter, indtil der træffes en beslutning, hvornår og hvor man skal stoppe. Nu bliver det endnu mere kompliceret at træffe en beslutning om at stoppe testen. Hvis 'stop, når alle mangler er fundet' ikke er kriteriet for at stoppe testen, på hvilket grundlag skal det besluttes?

Beslutning om at stoppe testningen: Udgangskriterier

Lad os nu prøve at forstå - Hvad er de vigtigste faktorer, der skal overvejes, når vi afslutter testaktiviteter? Jeg føler, at beslutningen om at stoppe testen for det meste afhænger af Tid, budget og testens omfang.

Den mest almindelige tilgang er at stoppe, når enten tid / budget er opbrugt, eller alle testscenarier udføres. Men med denne tilgang vil vi gå på kompromis med testkvaliteten, og dette giver ikke tilstrækkelig tillid til softwaren; hvordan?

Lad os se med eneksempel.

Testscenarie:

Antag at du tester et softwaremodul. Du har fået tildelt et bestemt budget til at dække det. Projektets tidslinjer er i en måned. De samlede testscenarier er 200. Du er den eneste, der tester dette modul.

Scenarie nr. 1)

Uge 1: Du finder showstopper / sværhedsgrad 1-manglen på dag 1, og hele testen er blokeret i 3 dage. Derfor er du ikke i stand til at udføre nogen af ​​scenarierne, før Severity 1-defekten er løst. Efter at have mistet 3 dage løses blokeringen, og du fortsætter med din udførelse.

I slutningen af ​​ugen gennemfører du 20 scenarier med få vigtigere høje prioritetsfejl .

Uge 2: Du begynder at teste softwaren og sætter mere fokus på fejlfinding. Du åbner nogle få flere alvorligheds-, sværheds- og sværhedsgradsfejl i løbet af den anden uge, og i slutningen af ​​ugen er du i stand til at dække 70 scenarier.

Uge 3: Ved starten af ​​3^rduge får du alle de højt prioriterede fejl løst, så sammen med udførelse af ventende scenarier er du nu nødt til at teste alle de mangler, der er landet i testspanden. Fortsætter du med de gode fremskridt, dækker du 120 scenarier med yderligere mangler.

På dette tidspunkt er alle højprioritetsfejl allerede fundet og rapporteret. Så nu har du kun alvorligheds 3-mangler tilbage at finde.

Uge 4: I uge 4 skal du teste de fleste af de åbnede defekter og de resterende 80 scenarier. Med dette ved udgangen af ​​uge 4 er du i stand til at gennemføre op til 180 scenarier med alle høj- og mellemprioritetsdefekter rettet og testet igen.

Sætte disse oplysninger i tabelform:

Skal du stoppe her?

Årsagen til, at du er opbrugt Test af tid helt og har rapporteret og rettet de fleste af de højt prioriterede fejl. Vil stoppe på dette tidspunkt give dig tillid til softwaren? Ikke rigtig på grund af nedenstående grunde:

• Scenarier udføres ikke fuldstændigt.
• Få strømme testes ikke engang en gang.
• Alle de scenarier, der er dækket, udføres kun en gang.
• Software har stadig mangler i sig.
• Regression er ikke dækket.

Scenarie nr. 2)

Uge 1: Du finder sværhedsgrad 1-defekt på dag 1, og komplet test er blokeret i 3 dage. Derfor er du ikke i stand til at udføre nogen af ​​scenarierne, før Severity 1 Defect er løst. Efter at have mistet 3 dage er blokeringen løst, og du fortsætter med din udførelse.

I slutningen af ​​ugen gennemfører du 20 scenarier med få flere mangler. Denne uge forbliver den samme som Scenario 1.

Uge 2: Du åbner nogle få flere alvorligheds-, sværheds- og sværhedsgrad-mangler i løbet af den anden uge, men fokus er at dække flere scenarier for at dække efterslæb fra uge 1. I slutningen af ​​ugen er du i stand til at dække 120 scenarier.

Uge 3: Ved starten af ​​3^rduge får du alle de åbne fejl løst, så sammen med udførelsen af ​​ventende scenarier skal du nu teste alle de mangler, der er landet i en testspand. Stadig fortsat med gode fremskridt i slutningen bliver antallet af gennemførte scenarier 200 med yderligere mangler.

Nu kan du kun rapportere alvorligheds- 2 og alvorlighedsfejl.

Sætte disse oplysninger i tabelform:

Skal du stoppe her?

Du har dækkede alle testscenarier fuldstændigt en gang og har åbnet nogle få store mangler. Vil stoppe på dette tidspunkt give dig tillid til softwaren?

hvad er den bedste dvd-kopieringssoftware

Ikke rigtig på grund af nedenstående grunde:

• Alle scenarier udføres kun en gang.
• Software har stadig mange store fejl.
• Regression er ikke dækket.

Vi kan se, at kvaliteten er kompromitteret i ovenstående begge scenarier. Den bedste tilgang er at finde et punkt, hvor alle faktorer fra scenario 1 og scenario 2 er dækket, og kvaliteten heller ikke kompromitteres. For at opnå dette bliver vi nødt til at definere bestemte kriterier i starten af ​​testen.

Disse kriterier betegnes som udfyldelse eller udgangskriterier. Det er svaret på vores spørgsmål - 'Hvornår skal jeg stoppe med at teste?'.

Hvad er gennemførelse eller udgangskriterier?

Udgangskriterierne evalueres i slutningen af ​​testcyklussen og er defineret i testplanen. Det er det sæt betingelser eller aktiviteter, der skal være opfyldt for at afslutte testen.

Udgangskriterierne definerer, hvor meget test der er nok, og hvornår testaktiviteter kan erklæres færdige. Dækning og færdiggørelseskriterier kombineres for at definere udgangskriterier til test.

Hvad skal være til stede i udgangskriterier?

Ideelt set defineres udgangs- eller stopkriterier ved at kombinere forskellige faktorer og er derfor unikke på tværs af alle projekter. Det afhænger af projektkravet og bør derfor defineres under testplanlægning; i begyndelsen af ​​projektet. Parametre defineret i den skal kvantificeres så meget som muligt.

Nedenfor er der få henvisninger, der skal overvejes, når man definerer udgangskriterier i tilfælde af funktionel eller systemtest. Du kan kombinere få eller alle nedenstående faktorer, mens du beslutter, hvor du skal stoppe med at teste efter dine projektbehov.

Test kan stoppes, når:

Krav:

• 100% kravsdækning er opnået.

Mangler:

• Defineret / ønsket antal defekter er nået.
• Alle Show Stopper-defekter eller -blokkere er rettet, og ingen kendt kritisk / alvorligheds 1-defekt er i åben status.
• Alle fejl med høj prioritet identificeres og løses.
• Fejlfrekvens falder under defineret acceptabel hastighed.
• Meget få mellemstore prioritetsfejl er åbne og har en løsning på plads.
• Meget få åbne defekter med lav prioritet, der ikke påvirker softwareanvendelsen.
• Alle højprioritetsdefekter testes igen og lukkes, og tilsvarende regressionsscenarier udføres med succes.

Testdækning:

• Testdækning skal være 95% opnået.
• Test case Pass Rate bør være 95%. Dette kan beregnes ved hjælp af formlen
  • (Samlet antal TC'er bestået / Samlet antal TC'er) * 100.
• Alle kritiske testsager er bestået.
• 5% testsager kan mislykkes, men de mislykkede testsager har lav prioritet.
• Komplet funktionel dækning opnås.
• Alle større funktionelle / forretningsstrømme udføres med succes med forskellige input og fungerer fint.

Frister:

• Projektfrist eller testafslutningsfrist er nået.

Testdokumenter:

• Alle testdokumenter / leverancer (eksempel - Testoversigtsrapport ) forberedes, gennemgås og offentliggøres på tværs.

Budget:

• Komplet testbudget er opbrugt.

Møder med 'Go / No Go':

• ' Gå / Nej Gå ' møde er gennemført med interessenter, og der træffes en beslutning om projektet skal gå i produktion eller ej.

Konklusion:

Lad os gøre det meget simpelt i slutningen.

Besvar spørgsmål med et simpelt ja eller nej.

Hvis du får de fleste af svarene som Ja, betyder det, at du kan stoppe med at teste på dette tidspunkt. Hvis de fleste af svarene er nej, betyder det, at du skal kontrollere, hvad der mangler ved testning, og dette kan hjælpe dig med at finde en undslippende produktionsfejl :)

• Udføres alle testsager mindst en gang?
• Er testcase-godkendelseshastigheden som defineret?
• Opnås komplet testdækning?
• Udføres alle funktionelle / forretningsstrømme mindst én gang?
• Er det besluttede antal defekter nået?
• Er alle større højprioritetsdefekter rettet og lukket?
• Er alle mangler blevet testet igen og lukket?
• Er der gjort regression for alle åbne defekter?
• Har du opbrugt testbudgettet?
• Er testens sluttid nået?
• Bliver alle testleverancer gennemgået og offentliggjort?

Om forfatteren: Dette er en gæsteartikel af Renuka K. Hun har 11+ års erfaring med softwaretest.

Håber denne artikel var nyttig for dig. Jeg vil også gerne høre dine tanker / kommentarer om emnet.

God test!

Anbefalet læsning

• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Software Testning QA Assistant Job
• Softwaretestkursusplan - Online kursus detaljeret træningsplan
• Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
• Valg af softwaretest som din karriere
• Softwaretest Teknisk indhold Writer Freelancer Job
• Nogle interessante spørgsmål om software-test Interview
• Software Testing Course Feedback og anmeldelser