Meny

Testscenario mot testfall: Vad är skillnaden mellan dessa?

test scenario vs test case

Prova Vårt Instrument För Att Eliminera Problem

Skillnaden mellan testscenario och testfall.

6 år sedan när jag arbetade med ett medelstort MNC, när jag föreslog att dokumentera testscenarier snarare än att slösa bort tid på att förbereda det fullständiga bevisdokumentet som kallades testfall, vände sig alla huvuden irriterande till mig.

Ansikten tittade tydligt på att jag gjorde ett stort misstag genom att föreslå det. Även om ingen förnekade idén accepterade ingen ens. Alla kände att det skulle vara säkrare att följa traditionen, dvs. skriva testdokument. Jag kunde inte argumentera.

Testscenario mot testfall

Efter 4 år , fick företaget ett testprojekt, där den enda begränsningen var tiden och den enda förväntningen var fullt bevis testning.

Vi var på mötet igen och diskuterade idéer för att klara den kritiska tidsfristen. Applikationen handlade främst om att söka och skapa olika rapporter via olika menyalternativ. Att dokumentera testfall skulle fånga för det mesta och vi var inte säkra på hur mycket dokumentet skulle använda för klienten.

Jag föreslog att dokumentera testscenarier och på något sätt tvekade alla överens. Inget behov av att nämna att vi kan spara dyrbar tid på dokumentation och kan använda den för testning.

Vad du kommer att lära dig:

Ersätts testfall snabbt med testscenarier?

Med tiden, när allt förändras, har programvaruindustrin och processerna också förändrats mycket.

sql frågor och svar för erfarna

Traditionell Vattenfall och V-modeller ersätts av smidiga och iterativa modeller. Dokumentation är nödvändig men för att uppfylla tidsfrister och göra processen enkel och transparent kan dokumentationssättet ändras.

När är dokumentation av testfall viktigt?

  1. Kunden har bett om samma sak som en del av projektet.
  2. Det finns ingen tidsbegränsning (jag tror inte att det är möjligt).
  3. Testare är färskare eller okända för produkten.
  4. Företagspolicy (jag tror starkt att den kan ändras).

Låt mig dela med dig en upplevelse:

Jag och mitt team var involverade i att testa ett projekt från ett Fortune 500-företag med flexibla tidslinjer. Vi dokumenterade testfall med bästa tillgängliga mall och fick det godkänt av klienten.

När byggnaden började släppas till QA-teamet, under större delen av dagen, var vår plikt att mekaniskt följa 100 testfall per dag, uppdatera dokumentet med pass / fail-resultat och skicka det till klienten i slutet av dagen. De flesta av teammedlemmar började klaga på monotont arbete men företaget genererade intäkter.

Sedan var det en paus en dag däremellan utan nybyggnad att testa. Vi satt tillsammans i början av dagen och diskuterade vad vi skulle göra för dagen. När jag föreslog att generera fler idéer för att förbättra testfallsdokumentet nekade alla teammedlemmar att anstränga sig.

Enligt dem fanns det inget mer att tänka på eftersom vi hade täckt alla scenarier. Och övertyga dem om att tänk ur en låda och generera fler idéer var riktigt tuff.

När vi dokumenterar testfall och som väl godkänts av klienten tycker det mänskliga sinnet att vi har gjort vårt jobb och vårt sinne slutar automatiskt överväga alla ansträngningar att tänka på andra sätt att testa produkten.

Och tro mig, när testfallsdokumentet utarbetas vill vi bara följa det mekaniskt. Berätta för mig hur många gånger i din karriär, du har upplevt att du eller lagkamraten erbjöd ytterligare testfall till det godkända testfallsdokumentet?

vad är din inställning när du testar mobilapplikationer

En upplevelse till:

Under veckovis teamutmaningsaktivitet meddelade vi ansökan och bad teammedlemmarna att hälla in testscenarier.

Alla teammedlemmar, inklusive de sena responderna eller de som inte svarar, lägger fram idéer. Varför? Det fanns ingen formell dokumentation där de var tvungna att fylla det förväntade resultatet för varje sekvens av funktionalitet och förutsättningar för varje testfall. Vi samlade 40 testscenarier på en dag och det var en fantastisk upplevelse.

För att gynna min upplevelse, Jag skulle vilja presentera ett exempel.

Ta en provapplikation, säg inloggningssida med användarnamn, lösenord, inloggning och avbryt-knappar. Om vi ​​ombeds skriva testfall för samma sak kommer vi att skriva mer än 50 testfall genom att kombinera olika alternativ och detaljer.

Men om testscenarier ska skrivas kommer det att handla om 10 rader enligt nedan:

Scenario på hög nivå: Inloggningsfunktionalitet
Scenarier på låg nivå :

1. För att kontrollera att applikationen startar
2. För att kontrollera textinnehållet på inloggningssidan
3. För att markera fältet Användarnamn
4. För att kontrollera lösenordsfältet
5. För att kontrollera inloggningsknappen och avbryta knappfunktionen

Se även=> 180+ exempel på testscenarier för testning av webb- och skrivbordsapplikationer.

Eftersom vi alla har kort tid, fungerar testscenarier som smärtstillande spray snarare än den gamla IODEX. Och ändå är effekten densamma.

Skillnader mellan testscenario och testfall i tabellformat

Slutligen vill jag sammanfatta skillnaden mellan testscenario och testfall:

TestfallTesta scenarier
Vad det är => Ett koncept som ger detaljerad information om vad man ska testa, steg som ska vidtas och förväntat resultat av detsammaEtt koncept som ger en rad information om vad man ska testa.
Det handlar om => Det handlar mer om att dokumentera detaljer.Det handlar mer om att tänka och diskutera detaljer.
Betydelse => Det är viktigt när testning är avstängd och utveckling sker på plats. Att skriva testfall med detaljer hjälper både dev- och QA-team i synkronisering.Det är viktigt när tiden är mindre och de flesta av teammedlemmarna kan komma överens om / förstå detaljerna från ett linjescenario.
Fördel => Engångsdokumentation av alla testfall är fördelaktigt för att spåra 1000-talet med regressionstest i framtiden.
För det mesta är det bra att rapportera fel. Testaren behöver bara ge referens till testfallets ID och behöver inte nämna varje minuts detalj.
En tidsbesparing och idégenereringsaktivitet, föredragen av den nya generationens mjukvarutestning.
Ändring och tillägg är enkel och inte specifik för en person.
För ett enormt projekt, där grupp människor bara känner till specifika moduler, ger denna aktivitet en chans för alla att titta på andra moduler och hjärnstorm och diskutera
Gynnsamt för => Ett fullständigt testdokument är en livslinje för ny testare.God testtäckning kan uppnås genom att dela applikationen i testscenarier och det minskar repeterbarheten och komplexiteten hos produkten
Nackdel = = Tid och pengar som kräver mer resurser för att beskriva allt om vad man ska testa och hur man testarOm den skapas av en specifik person, kanske granskaren eller den andra användaren inte synkroniserar den exakta tanken bakom den. Behöver fler diskussioner och teaminsatser.

Slutsats

Testfall är den viktigaste delen av livscykeln för programvaruutveckling och utan den är det svårt att spåra, förstå, följa och resonera något. Men i Agile-tiden ersätts testfall snabbt med testscenarier.

En vanlig testchecklista för varje typ av testning (databastestning, GUI-testning, funktionstestning, etc) i kombination med testscenarier är det moderna artilleriet för programvarutestare. Diskussioner, träning, frågor och övning kan definitivt ändra den slutliga grafen för din produktivitet samt en felrapportmatris.

Som vanligt välkomnar vi dina tankar och frågor. Vänligen ställa in.

PREV-handledning | NÄSTA självstudie

Rekommenderad läsning

^