När ska man sluta testa (Exit Criteria in Software Testing)

when stop testing

Utgångskriterier vid testning:

”Väl påbörjat är halvklart” - Gäller överallt, även mjukvarutestning.

Ofta ser vi mjukvarutestare som är mycket entusiastiska i början av projektet. Vi skapar testdokument som teststrategi, testplan eller testfall ivrigt och entusiastiskt.

Då får vi testa programvara med en BANG! Detta förstärks bara av de intressanta brister som vi hittar i början av projektet. Att få dem lösta kommer bara att öka vår prestation.

När vi hittar massor av defekter och slutför den första körningen går vi vidare till nästa fas. När vi kommer till andra körningen slappnar vi av och det är den allmänna mänskliga tendensen blir uttråkad med att testa samma sak i andra omgången.

intervjufrågor och svar för mobil testning pdf

Många testare känner att det blir monotont arbete i senare körningar och börja tappa intresset för att testa samma programvara om och om igen. När vi når, kanske den tredje körningen, börjar en fråga haunt oss och det är 'När ska vi sluta testa programvaran?'

Jag slår vad om att du måste ha känt på samma sätt och frågat 'När ska jag sluta testa?', Minst en gång. Jag skulle säga att frågan är 'När, var och hur slutar jag testa?' :)

Konceptuellt har vi läst och många testare tror att det inte kan finnas ett specifikt tillstånd eller en ekvation för att bestämma 'När ska jag sluta testa?' Det finns ett antal faktorer att tänka på innan vi avslutar denna fråga.

I dagens artikel vill jag dela med mig av mina tankar om hur man avslutar testaktiviteter när vi når en punkt i vår testcykel där vi kan säga att denna testning räcker. Vi kommer att göra detta med hjälp av några exempel från verkliga livet i en typisk testcykel.

Vad du kommer att lära dig:

• När är det tillräckligt med testning?
• Slutar när alla fel upptäcks: Är det möjligt?
• Beslut att avbryta testet: Utgångskriterier
• Vad är kompletterings- eller utgångskriterier?
• Vad ska finnas i utgångskriterier?
• Testningen kan stoppas när:
• Slutsats:
• Rekommenderad läsning

När är det tillräckligt med testning?

När kan vi säga att så mycket testning räcker? Kan testning någonsin slutföras?

För att kunna svara på dessa frågor måste vi analysera testaktiviteter från början till slut. Observera att - Jag ska definiera dessa aktiviteter i lekmän - inte på ett snyggt tekniskt sätt.

Låt oss överväga att du börjar testa ett nytt projekt.

Inledande aktiviteter:

• Testteamet får krav.
• Testteamet startar planera och design.
• De första testdokumenten är klara och granskade.

Testkörning nr 1)

• Testteamet startar testkörning när de får den utvecklade produkten.
• Under testfasen utför de olika scenarier för att bryta programvaran och hitta många defekter. (Dessutom är felhastigheten här högre eftersom applikationen är ny och utvärderas för första gången.)
• Defekterna fixas av utvecklare och återvänder till testteamet för omprövning.
• Testteamet utför omprövning av defekterna och utför regression.
• När de flesta av de allvarliga defekterna har lösts och programvaran ser stabil ut, utvecklingsteam släpper nästa version.

Testkörning nr 2)

• Testteamet startar den andra testkörningen och liknande aktiviteter körs som Run 1.
• I denna process under den andra testkörningen fångas några fler defekter.
• Defekterna fixas av utvecklare och återvänder till testteamet för en ny test.
• Testteamet testar igen defekterna och utför regression .

Detta kan fortsätta för alltid. Kör 3, Kör 4 framåt tills alla defekter i programvaran hittas och programvaran blir felfri.

Om vi ​​vill rita ett flödesschema för dessa aktiviteter ser det ungefär ut som nedan:

Från ovanstående flödesschema kan vi tydligt dra slutsatsen att testning kan fortsätta tills alla fel i programvaran hittas.

Men frågan är - Är det möjligt att hitta varje enskild defekt i programvaran? Låt oss försöka hitta svaret på denna miljonfråga :).

Slutar när alla fel upptäcks: Är det möjligt?

De flesta programvaror är komplexa och har ett enormt testomfång. Det är inte omöjligt att hitta alla defekter i programvaran men det tar evigt.

Även efter att ha hittat många buggar i programvaran, ingen kan faktiskt garantera att programvaran är felfri nu. Det kan inte finnas en situation där vi med säkerhet kan säga att vi har slutfört testningen, hittat alla defekter i programvaran och att den inte har fler buggar.

Syftet med testningen är dessutom inte att hitta varje defekt i programvaran. Syftet med testning av programvara är att bevisa att programvaran fungerar som avsett genom att bryta den eller hitta avvikelse mellan dess nuvarande beteende och förväntade beteende.

Det finns obegränsade defekter i programvaran och därför är det opraktiskt att testa det tills alla defekter hittas eftersom vi aldrig kan veta vilken defekt som är den sista. Sanningen är att vi inte kan lita på att hitta alla defekter i programvaran för att avsluta våra tester.

Ärligt talat är testning oändlig och testcykler fortsätter tills beslut fattas när och var man ska sluta. Nu blir det ännu mer komplicerat att komma till ett beslut att sluta testa. Om 'stopp när alla defekter upptäcks' inte är kriteriet för att sluta testa, på vilken grund ska det då bestämmas?

Beslut att sluta testa: Utgångskriterier

Låt oss nu försöka förstå - Vilka är de viktigaste faktorerna som ska beaktas när vi avslutar testaktiviteter? Jag känner att beslutet att sluta testa är mest beroende av Tid, budget och testets omfattning.

Det vanligaste tillvägagångssättet är att stoppa när antingen tid / budget är slut eller alla testscenarier körs. Men med detta tillvägagångssätt kommer vi att kompromissa med testkvaliteten och detta ger inte tillräckligt förtroende för programvaran; hur?

Låt oss se med enexempel.

Testscenario:

Anta att du testar en programvarumodul. Du har tilldelats en viss budget för att täcka den. Projektets tidslinjer är i en månad. Totala testscenarier är 200. Du är den enda som testar den här modulen.

Scenario 1)

Vecka 1: Du hittar showstopper / allvar 1-fel på dag 1 och hela testningen blockeras i 3 dagar. Därför kan du inte utföra några av scenarierna förrän allvarlighetsfel 1 är löst. Efter att ha förlorat tre dagar löses blockeraren och du fortsätter med din körning.

I slutet av veckan slutför du 20 scenarier med några viktigare höga prioritetsfel .

Vecka 2: Du börjar testa programvaran och lägger mer fokus på att hitta fel. Du öppnar några fler svårighetsgrad 1, svårighetsgrad 2 och svårighetsgrad 3 under den andra veckan och i slutet av veckan kan du täcka 70 scenarier.

Vecka 3: I början av 3^rdvecka får du alla högprioritetsdefekter lösta så tillsammans med körning av väntande scenarier måste du nu testa alla defekter som har landat i testskopan. Fortsätter du med de goda framstegen täcker du 120 scenarier med ytterligare defekter.

Vid denna tidpunkt har alla fel med hög prioritet redan hittats och rapporterats. Så nu har du bara svårighetsgrader 3 kvar att hitta.

Vecka 4: Vid vecka 4 måste du testa om de flesta av de öppnade defekterna och de återstående 80 scenarierna. Med detta i slutet av vecka 4 kan du slutföra upp till 180 scenarier med alla höga och medelstora prioritetsdefekter fixade och testade igen.

Att lägga denna information i tabellform:

Ska du stanna här?

Anledningen till att du har uttömt Testar tid helt och har rapporterat och åtgärdat de flesta av de högprioriterade bristerna. Kommer du att stanna vid denna tidpunkt ge dig självförtroende för programvaran? Inte riktigt på grund av nedanstående skäl:

• Scenarier körs inte helt.
• Få flöden testas inte ens en gång.
• Alla scenarier som omfattas utförs bara en gång.
• Programvaran har fortfarande defekter i sig.
• Regression täcks inte.

Scenario # 2)

Vecka 1: Du hittar allvar 1-fel på dag 1 och fullständig testning blockeras i 3 dagar. Därför kan du inte köra några av scenarierna förrän allvar 1 defekt är löst. Efter att ha förlorat tre dagar är blockeraren löst och du fortsätter med din körning.

I slutet av veckan slutför du 20 scenarier med några fler defekter. Den här veckan förblir densamma som Scenario 1.

Vecka 2: Du öppnar några fler svårighetsgrader 1, svårighetsgrad 2 och svårighetsgrad 3 under den andra veckan, men fokus är att täcka fler scenarier för att täcka eftersläp från vecka 1. I slutet av veckan kan du täcka 120 scenarier.

Vecka 3: I början av 3^rdvecka får du alla öppna defekter lösta så tillsammans med utförande av väntande scenarier måste du nu testa alla defekter som hamnar i en testskopa. Fortfarande fortsätter med bra framsteg i slutet blir antalet avslutade scenarier 200 med ytterligare defekter.

Nu kan du bara rapportera fel på svårighetsgrad 2 och svårighetsgrad 3.

Att lägga denna information i tabellform:

Ska du stanna här?

Du har täckte alla testscenarier helt en gång och har öppnat några större brister. Kommer du att stanna vid denna tidpunkt ge dig självförtroende för programvaran?

Inte riktigt på grund av nedanstående skäl:

• Alla scenarier körs bara en gång.
• Programvaran har fortfarande många stora fel.
• Regression täcks inte.

Vi kan se att kvaliteten äventyras ovanför båda scenarierna. Det bästa tillvägagångssättet är att hitta en punkt där alla faktorer från scenario 1 och scenario 2 täcks och kvalitet inte heller äventyras. För att uppnå detta måste vi definiera vissa kriterier i början av testningen.

Dessa kriterier kallas komplettering eller utgångskriterier. Det är svaret på vår fråga - 'När ska jag sluta testa?'.

Vad är kompletterings- eller utgångskriterier?

Utgångskriterierna utvärderas i slutet av testcykeln och definieras i testplanen. Det är uppsättningen villkor eller aktiviteter som måste uppfyllas för att avsluta testningen.

Utgångskriterierna definierar hur mycket test som räcker och när testaktiviteter kan förklaras slutförda. Rapportering och kompletteringskriterier kombineras för att definiera utgångskriterier för testning.

Vad ska finnas i utgångskriterier?

Idealt definieras utgångs- eller stoppkriterier genom att kombinera olika faktorer och är därför unika för alla projekt. Det beror på projektkravet och bör därför definieras under testplanering. i början av projektet. Parametrar som definieras i den ska kvantifieras så mycket som möjligt.

vad är en .eps-fil

Nedan följer några tips som ska övervägas när man definierar utgångskriterier vid funktionstest eller systemtestning. Du kan kombinera få eller alla nedanstående faktorer medan du bestämmer var du ska sluta testa enligt ditt projektbehov.

Testningen kan stoppas när:

Krav:

• 100% kravtäckning uppnås.

Fel:

• Definierat / önskat defektantal uppnås.
• Alla Show Stopper-defekter eller blockerare är fixade och ingen känd kritisk / allvarlighetsfel 1 är i öppen status.
• Alla högprioritetsfel identifieras och åtgärdas.
• Defektfrekvens faller under definierad acceptabel hastighet.
• Mycket få defekter med medelhög prioritet är öppna och har en lösning på plats.
• Mycket få öppna prioritetsfel med låg prioritet som inte påverkar programvaran.
• Alla högprioritetsdefekter testas om och stängs och motsvarande regressionsscenarier utförs framgångsrikt.

Testtäckning:

• Testtäckningen bör uppnås 95%.
• Testfall Godkänd andel ska vara 95%. Detta kan beräknas med formeln
  • (Totalt antal godkända TC / totalt antal TC: er) * 100.
• Alla kritiska testfall är godkända.
• 5% testfall kan misslyckas men fallet misslyckades har låg prioritet.
• Fullständig funktionell täckning uppnås.
• Alla större funktionella / affärsflöden genomförs framgångsrikt med olika ingångar och fungerar bra.

Tidsfrister:

• Tidsfristen för projektet eller Test Slutdatum är nådd.

Testdokument:

• Alla testdokument / leveranser (exempel - Testöversiktsrapport ) förbereds, granskas och publiceras överallt.

Budget:

• Komplett testbudget är slut.

'Go / No Go' -möten:

• ' Go / No Go ' möte har genomförts med intressenter och beslut fattas om projektet ska gå i produktion eller inte.

Slutsats:

Låt oss göra det väldigt enkelt i slutet.

Svara på frågor med ett enkelt ja eller nej.

Om du får de flesta svaren som Ja betyder det att du kan sluta testa vid denna tidpunkt. Om de flesta av svaren är Nej betyder det att du måste kontrollera vad som saknas i testningen och detta kan hjälpa dig att hitta en produktionsfel som flyr :)

• Verkställs alla testfall minst en gång?
• Är testfallets godkända nivå definierad?
• Uppnås fullständig testtäckning?
• Körs alla funktionella / affärsflöden minst en gång?
• Uppnås det beslutade defektantalet?
• Är alla stora högprioritetsdefekter fixade och stängda?
• Har alla defekter testats och stängts igen?
• Har regression gjorts för alla öppna defekter?
• Har du tömt testbudgeten?
• Har testtidens sluttid nått?
• Granskas och publiceras alla testleveranser?

Om författaren: Detta är en gästartikel av Renuka K. Hon har 11+ års erfarenhet av programvarutestning.

Hoppas den här artikeln var till hjälp för dig. Jag skulle också vilja höra dina tankar / kommentarer om ämnet.

Glad testning!

Rekommenderad läsning

• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Programvarutestning QA-assistentjobb
• Kursplan för programvarutestning - Detaljerad utbildningsplan för online-kurs
• Programvarutestningskurs: Vilket programvarutestinstitut ska jag gå med?
• Välja programvarutestning som din karriär
• Programvarutestning Tekniskt innehåll Writer Freelancer Jobb
• Några intressanta programtestintervjufrågor
• Programtestkursfeedback och recensioner