Menu

Testscenarie mod testtilfælde: Hvad er forskellen mellem disse?

test scenario vs test case

Prøv Vores Instrument Til At Fjerne Problemer

Forskellen mellem testscenarie og testcase.

6 år siden , mens jeg arbejdede med en mellemstor MNC, da jeg foreslog at dokumentere testscenarier snarere end at spilde tid på at forberede det fulde bevisdokument kaldet testcases, vendte alle hovederne mig irriteret.

Ansigtsudseendet formåede tydeligt, at jeg lavede en stor fejl ved at foreslå det. Selvom ingen benægtede ideen, accepterede ingen engang. Alle følte, at det ville være sikrere at følge traditionen, dvs. skrive testdokumenter. Jeg kunne ikke argumentere.

Test Scenario Vs Test Case

Efter 4 år , virksomheden modtog et testprojekt, hvor den eneste begrænsning var tiden, og den eneste forventning var fuld bevis testning.

Vi var på mødet igen og diskuterede ideer for at overholde den kritiske deadline. Ansøgningen handlede primært om at søge og generere forskellige rapporter via forskellige menupunkter. Dokumentation af testsager skulle formodes at snappe det meste af tiden, og vi var ikke sikre på, hvor meget dokumentet skulle bruge til klienten.

Jeg foreslog at dokumentere testscenarier og på en eller anden måde med en vis tøven var alle enige. Ingen grund til at nævne, at vi kunne spare dyrebar tid med dokumentation og kunne bruge den til test.

Hvad du lærer:

Erstattes testsager hurtigt med testscenarier?

Med tiden, da alt ændrer sig, har softwareindustrien og processerne også ændret sig meget.

forskel mellem sort boks og hvid boks test

Traditionel Vandfald og V-modeller erstattes af smidige og iterative modeller. Dokumentation er nødvendig men for at overholde deadlines og gøre processen let og gennemsigtig kan dokumentationsmetoden ændres.

Hvornår er dokumentation af testsager vigtig?

  1. Kunden har bedt om det samme som en del af projektet.
  2. Der er ingen tidsbegrænsning (jeg tror ikke det er muligt).
  3. Testere er friskere eller ukendte for produktet.
  4. Virksomhedspolitik (jeg tror stærkt på, at den kan ændres).

Lad mig dele med dig en oplevelse:

Jeg og mit team var involveret i at teste et projekt fra et Fortune 500-firma med fleksible tidslinjer. Vi dokumenterede testsager med den bedste tilgængelige skabelon og fik den godkendt af klienten.

Når bygningen begyndte at frigives til QA-teamet, var det vores pligt, mekanisk at følge 100 testsager pr. Dag, opdatere dokumentet med pass / fail-resultat og sende det til klienten i slutningen af ​​dagen. Det meste af teammedlemmer begyndte at klage over monotont arbejde men virksomheden genererede indtægter.

Derefter var der en pause i en dag imellem uden nye build at teste. Vi sad sammen i begyndelsen af ​​dagen og diskuterede, hvad vi skulle gøre for dagen. Da jeg foreslog at generere flere ideer til forbedring af testdokumentet, nægtede alle holdmedlemmerne at gøre en indsats.

Ifølge dem var der ikke mere at tænke på, da vi havde dækket alle scenarierne. Og overbevise dem om tænk ud af en boks og generer flere ideer var virkelig hård.

Når vi dokumenterer testtilfælde, og det også en gang godkendt af klienten, mener det menneskelige sind, at vi har gjort vores job og vores sind stopper automatisk med at overveje enhver indsats for at tænke på andre måder at teste produktet på.

Og tro mig, når testcases dokument udarbejdes, vil vi bare følge det mekanisk. Fortæl mig for hvor mange gange i din karriere, du har oplevet, at du eller holdkammeraten tilbød yderligere testsager til det godkendte testsagsdokument?

En oplevelse mere:

teknisk support analytiker interview spørgsmål og svar

Under ugentlig teamudfordringsaktivitet annoncerede vi ansøgningen og bad teammedlemmerne om at hælde testscenarier ind.

Alle teammedlemmerne, inklusive de sene respondenter eller ikke-respondenterne, fremsatte ideer. Hvorfor? Der var ingen formel dokumentation, hvor de var nødt til at udfylde det forventede resultat for hver sekvens af funktionalitet og forudsætning for hver testsag. Vi samlede 40 testscenarier på en dag, og det var en stor oplevelse.

For at favorisere min oplevelse Jeg vil gerne præsentere et eksempel.

Tag en prøveapplikation, sig loginside med brugernavn, adgangskode, login og annulleringsknapper. Hvis vi bliver bedt om at skrive testsager for det samme, ender vi med at skrive mere end 50 testsager ved at kombinere forskellige muligheder og detaljer.

Men hvis testscenarier skal skrives, vil det være et spørgsmål om 10 linjer som nedenfor:

Scenario på højt niveau: Login-funktionalitet
Scenarier på lavt niveau :

1. For at kontrollere, at applikationen starter
2. For at kontrollere tekstindholdet på login-siden
3. For at kontrollere feltet Brugernavn
4. For at kontrollere adgangskodefeltet
5. For at kontrollere loginknap og annullere knapfunktionalitet

Se også=> 180+ eksempler på testscenarier til test af web- og desktopapplikationer.

Da vi alle har kort tid, fungerer testscenarier som smertestillende spray snarere end den gamle IODEX. Og stadig, effekten er den samme.

Forskelle mellem testscenarie og testsag i tabelformat

Endelig vil jeg sammenfatte forskellen mellem testscenarie vs testsag:

Test tilfældeTest scenarier
Hvad det er => Et koncept, der giver detaljeret information om, hvad man skal teste, skridt, der skal tages, og forventet resultat af det sammeEt koncept, der giver information i en linje om, hvad man skal teste.
Det handler om => Det handler mere om at dokumentere detaljer.Det handler mere om at tænke og diskutere detaljer.
Vigtighed => Det er vigtigt, når test er ude af bredden, og udvikling finder sted på stedet. Skrivning af testsager med detaljer hjælper både dev og QA team med at synkronisere.Det er vigtigt, når tiden er mindre, og de fleste af teammedlemmerne kan være enige om / forstå detaljerne fra en-linjescenariet.
Fordel => Engangsdokumentation af alle testsagerne er en fordel at spore 1000-runder med regressionstest i fremtiden.
Det meste af tiden er det nyttigt under fejlrapportering. Tester skal bare referere til test case ID og kræver ikke at nævne hver eneste detalje.
En tidsbesparende og idégenererende aktivitet, foretrukket af den nye generation af softwaretestfællesskab.
Ændring og tilføjelse er enkel og ikke specifik for en person.
For et stort projekt, hvor en gruppe mennesker kun kender specifikke moduler, giver denne aktivitet en chance for alle at se på andre moduler og hjernestorm og diskutere
Gunstigt at => Et fuldt bevis dokument er en livslinje for nye testere.God testdækning kan opnås ved at opdele applikationen i testscenarier, og det reducerer produktets repeterbarhed og kompleksitet
Ulempe => Tidskrævende tid og penge, da det kræver flere ressourcer til at uddybe alt om, hvad man skal teste, og hvordan man testerHvis oprettet af en bestemt person, synkroniserer anmelderen eller den anden bruger muligvis ikke den nøjagtige idé bag den. Brug for flere diskussioner og teamindsats.

Konklusion

Testcases er den vigtigste del af softwareudviklingens livscyklus, og uden den ene er det svært at spore, forstå, følge og ræsonnere noget. Men i tiden med Agile erstattes testsager hurtigt med testscenarier.

En fælles test tjekliste for hver type test (databasetest, GUI-test, funktionstest osv.) kombineret med testscenarier er det moderne artilleri til softwaretestere. Diskussioner, træning, spørgsmål og praksis kan helt sikkert ændre den endelige graf for din produktivitet samt en fejlrapportmatrix.

Som sædvanligt hilser vi dine tanker og spørgsmål velkommen. Indstil venligst.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^