Når skal jeg stoppe testing (avslutningskriterier i programvaretesting)

when stop testing

Utgangskriterier i testing:

“Godt begynt er halvparten ferdig” - Gjelder overalt, til og med programvaretesting.

Ofte ser vi programvaretestere veldig entusiastiske i begynnelsen av prosjektet. Vi skaper teste dokumenter som teststrategi, testplan eller testtilfeller ivrig og entusiastisk.

Så får vi teste programvare med en BANG! Dette forsterkes bare av de interessante feilene vi finner i begynnelsen av prosjektet. Å få dem løst vil bare øke vår prestasjon.

Når vi finner mange mangler og fullfører den første løpeturen, går vi videre til neste fase. Når vi kommer til det andre løpet, slapper vi av, og det er den generelle menneskelige tendensen til kjeder seg med å teste det samme i andre omgang.

implementering av en stack c ++

Mange testere føler at det blir monotont arbeid i senere løp og begynner å miste interessen for å teste den samme programvaren om og om igjen. Når vi kommer til, kanskje det tredje løpet, begynner ett spørsmål å hjemsøke oss, og det er 'Når skal vi slutte å teste programvaren?'

Jeg vedder på at du må ha følt på samme måte og spurte 'Når skal du slutte å teste?', Minst en gang. Jeg vil si at spørsmålet er 'Når, hvor og hvordan stopper jeg testen?' :)

Konseptuelt har vi lest, og mange testere mener at det ikke kan være en spesifikk tilstand eller ligning for å bestemme 'Når skal jeg slutte å teste?' Det er en rekke faktorer å vurdere før vi konkluderer med dette spørsmålet.

I dagens artikkel vil jeg dele tankene mine om hvordan vi kan avslutte testaktiviteter når vi når et punkt i testsyklusen der vi kan si at denne testen er nok. Vi vil gjøre dette ved hjelp av noen få eksempler fra virkeligheten i en typisk testsyklus.

Hva du vil lære:

• Når er det nok testing?
• Stopper når alle feil er funnet: Er det mulig?
• Beslutning om å stoppe testing: Utgangskriterier
• Hva er fullføring eller utgangskriterier?
• Hva skal være til stede i Exit Criteria?
• Testing kan stoppes når:
• Konklusjon:
• Anbefalt lesing

Når er det nok testing?

Når kan vi si at så mye testing er nok? Kan testingen noen gang fullføres?

For å svare på disse spørsmålene, må vi analysere testaktiviteter fra start til slutt. Vær oppmerksom på at - Jeg skal definere disse aktivitetene i lekmannens termer - Ikke på en fancy teknisk måte.

La oss vurdere at du begynner å teste et nytt prosjekt.

Innledende aktiviteter:

• Testteamet mottar krav.
• Testteamet starter planlegger og design.
• Første testdokumenter er klare og gjennomgått.

Testkjøring nr. 1)

• Testeteamet starter testutførelse når de mottar det utviklede produktet.
• I løpet av testfasen utfører de forskjellige scenarier for å bryte programvaren og finne mange feil. (Dessuten er mangelfrekvensen her høyere fordi applikasjonen er ny og gjennomgås for aller første gang.)
• Defektene løses av utviklere og returneres tilbake til testteamet for omprøving.
• Testteamet utfører ny testing av feilene og utfører regresjon.
• Når de fleste av de alvorlige feilene er løst og programvaren ser stabil ut, utviklingsteam utgir neste versjon.

Testkjøring nr. 2)

• Testteamet starter den andre testen og lignende aktiviteter utføres som Run 1.
• I denne prosessen i løpet av den andre testkjøringen, er det få flere feil.
• Defektene løses av utviklere og returneres tilbake til testteamet for en ny test.
• Testteamet tester feilene og utfører på nytt regresjon .

Dette kan fortsette for alltid. Kjør 3, kjør 4 videre til alle feil i programvaren blir funnet og programvaren blir feilfri.

Hvis vi vil tegne et flytskjema for disse aktivitetene, vil det se omtrent ut som nedenfor:

Fra flytskjemaet ovenfor kan vi tydelig konkludere med at testing kan fortsette til alle feil i programvaren er funnet.

Men spørsmålet er - er det mulig å finne hver eneste feil i programvaren? La oss prøve å finne svaret på dette million dollar-spørsmålet :).

Stopper når alle feil er funnet: Er det mulig?

Mesteparten av programvaren er kompleks og har et enormt testomfang. Det er ikke umulig å finne alle feil i programvaren, men det vil ta evig tid.

Selv etter å ha funnet mange feil i programvaren, ingen kan faktisk garantere at programvaren er feilfri nå. Det kan ikke være en situasjon der vi trygt kan si at vi har fullført testing, funnet alle feil i programvaren, og den ikke har flere feil.

Videre er formålet med testing ikke å finne hver eneste feil i programvaren. Hensikten med programvaretesting er å bevise at programvaren fungerer som ment ved å bryte den eller finne avvik mellom den nåværende oppførselen og forventede atferd.

Det er ubegrensede feil i programvaren, og det er derfor upraktisk å teste den til alle feil er funnet, da vi aldri kan vite hvilken mangel som er den siste. Sannheten er at vi ikke kan stole på å finne alle feilene i programvaren for å avslutte testingen.

Ærlig talt, testing er uendelig, og testing sykluser vil fortsette til en beslutning blir tatt når og hvor du skal stoppe. Nå blir det enda mer komplisert å komme til en beslutning om å slutte å teste. Hvis 'stopp når alle mangler er funnet' ikke er kriteriet for å stoppe testingen, på hvilket grunnlag bør det avgjøres?

Beslutning om å stoppe testingen: Utgangskriterier

La oss nå prøve å forstå - Hva er de viktigste faktorene som må vurderes når vi avslutter testaktiviteter? Jeg føler at avgjørelsen om å slutte å teste for det meste er avhengig av Tid, budsjett og omfang av testing.

Den vanligste tilnærmingen er å stoppe når enten tid / budsjett er oppbrukt eller alle testscenarier blir utført. Imidlertid, med denne tilnærmingen, vil vi gå på kompromiss med kvaliteten på testingen, og dette vil ikke gi nok tillit til programvaren; hvordan?

La oss se med eneksempel.

Test Scenario:

Anta at du tester en programvaremodul. Du har fått tildelt et visst budsjett for å dekke det. Prosjektets tidslinjer er i en måned. Totale testscenarier er 200. Du er den eneste som tester denne modulen.

Scenario nr. 1)

Uke 1: Du finner showstopper / alvorlighetsgrad 1-feil på dag 1, og hele testen er blokkert i 3 dager. Derfor er du ikke i stand til å utføre noen av scenariene før alvorlighetsgrad 1-feil er løst. Etter å ha tapt tre dager, er blokkeringen løst, og du fortsetter med henrettelsen.

På slutten av uken fullfører du 20 scenarier med få viktigere høye prioritetsfeil .

Uke 2: Du begynner å teste programvaren og setter mer fokus på å finne feil. Du åpner noen flere alvorlighetsgrad 1, alvorlighetsgrad 2 og alvorlighetsgrad 3 i løpet av den andre uken, og på slutten av uken kan du dekke 70 scenarier.

Uke 3: Ved starten av 3^rduke får du alle de høye prioritetsfeilene løst, så sammen med utførelsen av ventende scenarier må du nå teste alle feilene som har kommet i testbøtta. Fortsetter du med den gode fremgangen, dekker du 120 scenarier med ekstra mangler.

På dette tidspunktet er alle mangler med høy prioritet allerede funnet og rapportert. Så nå har du bare alvorlighetsgrad 3-mangler igjen å finne.

Uke 4: I uke 4 må du teste de fleste av de åpnede feilene og de gjenværende 80 scenariene. Med dette innen utgangen av uke 4, er du i stand til å fullføre opptil 180 scenarier med alle høyt og middels prioritetsfeil løst og testet på nytt.

Sette denne informasjonen i tabellform:

Skal du stoppe her?

Årsaken til at du har brukt opp Testing Time helt og har rapportert og løst de fleste av de høye prioritetsfeilene. Vil du stoppe på dette tidspunktet gi deg selvtillit til programvaren? Ikke egentlig på grunn av nedenstående årsaker:

• Scenarier utføres ikke helt.
• Få flyter blir ikke engang testet en gang.
• Alle scenariene som dekkes, utføres bare én gang.
• Programvare har fortsatt mangler i seg.
• Regresjon dekkes ikke.

Scenario nr. 2)

Uke 1: Du finner alvorlighetsgrad 1-feil på dag 1, og fullstendig testing er blokkert i 3 dager. Derfor er du ikke i stand til å utføre noen av scenariene før alvorlighetsgrad 1-feil er løst. Etter å ha mistet 3 dager er blokkeringen løst, og du fortsetter med henrettelsen.

På slutten av uken fullfører du 20 scenarier med få flere mangler. Denne uken forblir den samme som Scenario 1.

Uke 2: Du åpner noen flere mangler i alvorlighetsgrad 1, alvorlighetsgrad 2 og alvorlighetsgrad 3 i løpet av den andre uken, men fokuset er å dekke flere scenarier for å dekke etterslep fra uke 1. På slutten av uken kan du dekke 120 scenarier.

Uke 3: Ved starten av 3^rduke får du alle åpne feil løst, så sammen med utførelse av ventende scenarier må du nå teste alle feilene som er landet i en testbøtte. Fortsatt med god fremgang på slutten blir antallet fullførte scenarier 200 med ytterligere mangler.

Nå kan du bare rapportere alvorlighetsgrad 2 og alvorlighetsgrad 3.

Sette denne informasjonen i tabellform:

Skal du stoppe her?

Du har dekket alle testscenariene fullstendig en gang og har åpnet noen få store mangler. Vil du stoppe på dette tidspunktet gi deg selvtillit til programvaren?

Ikke egentlig på grunn av nedenstående årsaker:

• Alle scenarier utføres bare en gang.
• Programvare har fremdeles mange store feil.
• Regresjon dekkes ikke.

Vi kan se at kvaliteten er kompromittert i over begge scenariene. Den beste tilnærmingen vil være å finne et punkt der alle faktorene fra scenario 1 og scenario 2 dekkes, og kvaliteten heller ikke kompromitteres. For å oppnå dette må vi definere visse kriterier i begynnelsen av testingen.

Disse kriteriene blir betegnet som fullføring eller utgangskriterier. Det er svaret på spørsmålet vårt - 'Når skal jeg slutte å teste?'.

hvordan du bygger en brannmur for windows

Hva er fullføring eller utgangskriterier?

Utgangskriteriene blir evaluert på slutten av testsyklusen og er definert i testplan. Det er settet med vilkår eller aktiviteter som må oppfylles for å fullføre testingen.

Utgangskriteriene definerer hvor mye testing som er nok, og når testaktiviteter kan erklæres fullført. Dekning og fullføringskriterier kombineres for å definere utgangskriterier for testing.

Hva skal være til stede i Exit Criteria?

Ideelt sett defineres Exit or Stop Criteria ved å kombinere ulike faktorer og er derfor unikt i alle prosjekter. Det avhenger av prosjektkravet og bør derfor defineres under testplanlegging; i begynnelsen av prosjektet. Parametere som er definert i den, bør kvantifiseres så mye som mulig.

Nedenfor er noen få tips som skal vurderes når du definerer utgangskriterier i tilfelle funksjonell eller systemtesting. Du kan kombinere få eller alle nedenstående faktorer mens du bestemmer deg for hvor du skal stoppe testingen i henhold til prosjektets behov.

Testing kan stoppes når:

Krav:

• 100% kravsdekning er oppnådd.

Mangler:

• Definerte / Ønskede feilantall er nådd.
• Alle feil på Show Stopper eller blokkeringer er løst, og ingen kjent kritisk / alvorlighetsgrad 1-feil er i åpen status.
• Alle feil med høy prioritet blir identifisert og løst.
• Defektrate faller under definert akseptabel hastighet.
• Svært få middels prioritetsdefekter er åpne og har en løsning på plass.
• Svært få åpne prioritetsdefekter med lav prioritet som ikke påvirker programvarebruk.
• Alle høyprioritetsdefekter testes på nytt og lukkes, og tilsvarende regresjonsscenarier blir utført.

Testdekning:

• Testdekning bør oppnås 95%.
• Test case Pass Rate bør være 95%. Dette kan beregnes etter formel
  • (Totalt antall godkjente TC-er / totalt antall TC-er) * 100.
• Alle kritiske testsaker er bestått.
• 5% testsaker kan mislykkes, men mislykkede testsaker har lav prioritet.
• Komplett funksjonell dekning oppnås.
• Alle viktige funksjonelle / forretningsstrømmer gjennomføres med suksess med forskjellige innganger og fungerer bra.

Frister:

• Frist for prosjekt eller Test Finish er nådd.

Testdokumenter:

• Alle testdokumenter / leveranser (eksempel - Test Sammendrag Rapport ) blir utarbeidet, gjennomgått og publisert på tvers.

Budsjett:

• Komplett testbudsjett er oppbrukt.

“Go / No Go” -møter:

• ' Gå / Nei Gå ' møte har blitt gjennomført med interessenter og det tas en beslutning om prosjektet skal gå i produksjon eller ikke.

Konklusjon:

La oss gjøre det veldig enkelt til slutt.

Svar på spørsmål med et enkelt ja eller nei.

Hvis du får de fleste svarene som Ja, betyr det at du kan slutte å teste på dette tidspunktet. Hvis de fleste av svarene er Nei, betyr det at du må sjekke hva som mangler i testingen, og dette kan hjelpe deg med å finne en rømmende produksjonsfeil :)

• Er alle testsaker utført minst en gang?
• Er testcase-godkjennelsesgraden som definert?
• Oppnås fullstendig testdekning?
• Utføres alle funksjonelle / forretningsstrømmer minst én gang?
• Er den avgjorte mangeltellingen nådd?
• Er alle store feil med høy prioritet løst og lukket?
• Har alle feil blitt testet og lukket på nytt?
• Er regresjon gjort for alle åpne mangler?
• Har du brukt opp testbudsjettet?
• Har testens sluttid nådd?
• Blir alle testleveranser gjennomgått og publisert?

Om forfatteren: Dette er en gjesteartikkel av Renuka K. Hun har 11+ års erfaring med programvaretesting.

Håper denne artikkelen var nyttig for deg. Jeg vil også gjerne høre dine tanker / kommentarer om emnet.

Glad test!

Anbefalt lesing

• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Programvaretesting QA Assistant Job
• Programtestkursplan - Online kursdetaljert opplæringsplan
• Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
• Velge programvaretesting som din karriere
• Programvaretesting Teknisk innhold Writer Freelancer Jobb
• Noen interessante intervjusspørsmål om programvaretesting
• Programvaretestkurs Tilbakemelding og anmeldelser