test scenario vs test case
Forskjellen mellom testscenario og testsak.
6 år siden , mens jeg jobbet med et mellomstort MNC, da jeg foreslo å dokumentere testscenarier i stedet for å kaste bort tid på å utarbeide det fullstendige bevisdokumentet som ble kalt testsaker, vendte alle hodene meg irritert.
Ansiktet så tydelig ut at jeg gjorde en stor feil ved å foreslå det. Selv om ingen benektet ideen, godtok ingen engang. Alle følte at det ville være tryggere å følge tradisjonen, det vil si å skrive testdokumenter. Jeg kunne ikke krangle.
Etter 4 år , mottok selskapet et testprosjekt, der den eneste begrensningen var tid og den eneste forventningen var full bevis testing.
Vi var på møtet igjen og diskuterte ideer for å overholde den kritiske fristen. Søknaden handlet hovedsakelig om å søke og generere forskjellige rapporter via forskjellige menyelementer. Dokumentering av testtilfeller skulle snappe mesteparten av tiden, og vi var ikke sikre på hvor mye dokumentet skulle bruke til klienten.
Jeg foreslo å dokumentere testscenarier, og på en eller annen måte, med litt nøling, var alle enige. Ingen grunn til å nevne at vi kunne spare dyrebar tid med dokumentasjon og kunne bruke den til testing.
Hva du vil lære:
- Erstatt tilfeller raskt med testscenarier?
- Når er dokumentasjon av testtilfeller viktig?
- Forskjeller mellom testscenario mot testtilfelle i tabellformat
- Konklusjon
- Anbefalt lesing
Erstatt tilfeller raskt med testscenarier?
Etter hvert som alt er i endring, har programvareindustrien og prosessene også endret seg mye.
forskjellen mellom soapui og soapui pro
Tradisjonell Foss og V-modeller blir erstattet av smidige og iterative modeller. Dokumentasjon er nødvendig men for å overholde frister og gjøre prosessen enkel og gjennomsiktig, kan dokumentasjonsmåten endres.
Når er dokumentasjon av testtilfeller viktig?
- Klienten har bedt om det samme som en del av prosjektet.
- Det er ingen tidsbegrensning (jeg tror ikke det er mulig).
- Testere er ferskere eller ukjente for produktet.
- Bedriftens policy (jeg tror sterkt at den kan endres).
La meg dele en opplevelse med deg:
Jeg og teamet mitt var involvert i å teste et prosjekt fra et Fortune 500-selskap med fleksible tidslinjer. Vi dokumenterte testsaker med den beste tilgjengelige malen og fikk den godkjent av klienten.
Når bygningen begynte å bli utgitt til QA-teamet, for det meste av dagen, var vår plikt å følge 100 testsaker per dag mekanisk, oppdatere dokumentet med pass / fail-resultat og sende det til klienten på slutten av dagen. Mesteparten av teammedlemmer begynte å klage på monotont arbeid men selskapet genererte inntekter.
Så var det en pause en dag innimellom uten nybygg å teste. Vi satt sammen på begynnelsen av dagen og diskuterte hva vi skulle gjøre for dagen. Da jeg foreslo å generere flere ideer for å forbedre testdokumentet, nektet alle teammedlemmene å gjøre en innsats.
I følge dem var det ingenting mer å tenke på, da vi hadde dekket alle scenariene. Og overbevise dem om tenk ut av en boks og generer flere ideer var veldig tøff.
Når vi dokumenterer testsaker og som også en gang er godkjent av klienten, mener det menneskelige sinnet at vi har gjort jobben vår og tankene våre slutter automatisk å vurdere ethvert forsøk på å tenke på andre måter å teste produktet på.
Og tro meg, når testdokumenter blir utarbeidet, vil vi bare følge det mekanisk. Fortell meg for hvor mange ganger i karrieren din, du har opplevd at du eller lagkameraten tilbød flere testsaker til det godkjente testsaksdokumentet?
En opplevelse til:
Under ukentlig teamutfordringsaktivitet kunngjorde vi søknaden og ba teammedlemmene om å hente inn testscenarier.
Alle teammedlemmene, inkludert de sene respondentene eller ikke-responderne, la inn ideer. Hvorfor? Det var ingen formell dokumentasjon der de måtte fylle det forventede resultatet for hver sekvens av funksjonalitet og forutsetning for hver testsak. Vi samlet 40 testscenarier på en dag, og det var en flott opplevelse.
For å favorisere min opplevelse, Jeg vil gjerne presentere et eksempel.
Ta et eksempel på en applikasjon, si påloggingsside med brukernavn, passord, pålogging og avbryt-knapper. Hvis vi blir bedt om å skrive testsaker for det samme, vil vi ende opp med å skrive mer enn 50 testsaker ved å kombinere forskjellige alternativer og detaljer.
Men hvis testscenarier skal skrives, vil det dreie seg om ti linjer som nedenfor:
Scenario på høyt nivå: Påloggingsfunksjonalitet
Scenarier på lavt nivå :
1. For å sjekke Application is Launching
2. For å sjekke tekstinnholdet på innloggingssiden
3. For å sjekke brukernavnfeltet
4. For å sjekke passordfeltet
5. For å sjekke Login-knappen og avbryte knappefunksjonalitet
Se også=> 180+ eksempler på testscenarier for testing av nett- og skrivebordsprogrammer.
Ettersom vi alle har kort tid, fungerer testscenarier som smertestillende spray i stedet for den gamle IODEX. Og fortsatt er effekten den samme.
Forskjeller mellom testscenario mot testtilfelle i tabellformat
Til slutt vil jeg oppsummere forskjellen mellom testscenario og testsak:
hva er den beste gratis datamaskinrenseren
Test tilfeller | Test scenarier | |
---|---|---|
Hva det er => | Et konsept som gir detaljert informasjon om hva du skal teste, trinn som skal tas og forventet resultat av det samme | Et konsept som gir en linje informasjon om hva du skal teste. |
Det handler om => | Det handler mer om å dokumentere detaljer. | Det handler mer om å tenke og diskutere detaljer. |
Viktighet => | Det er viktig når testing er utenfor land og utvikling er på stedet. Å skrive testsaker med detaljer vil hjelpe både dev og QA team i synkronisering. | Det er viktig når tiden er kortere, og de fleste av teammedlemmene kan være enige / forstå detaljene fra en-linjescenario. |
Fordel => | Engangsdokumentasjon av alle testsakene er gunstig for å spore 1000-runder med regresjonstesting i fremtiden. Mesteparten av tiden, det er nyttig mens feilrapportering. Tester trenger bare å gi referanse til test-saks-ID og krever ikke å nevne hver eneste detalj. | En tidsbesparende og idégenererende aktivitet, foretrukket av ny generasjon programvaretestingssamfunn. Endring og tillegg er enkelt og ikke spesifikt for en person. For et stort prosjekt, hvor en gruppe mennesker bare kjenner til bestemte moduler, gir denne aktiviteten en sjanse til alle å se på andre moduler og hjernestorm og diskutere |
Gunstig til => | Et fullsikkert testdokument er en livslinje for ny tester. | God testdekning kan oppnås ved å dele applikasjonen i testscenarier, og det reduserer repeterbarhet og kompleksitet av produktet |
Ulempe => | Tid og penger som krever mer ressurser for å detaljere alt om hva du skal teste og hvordan du skal teste | Hvis den er opprettet av en bestemt person, kan det hende at anmelderen eller den andre brukeren ikke synkroniserer den eksakte ideen bak den. Trenger flere diskusjoner og teaminnsats. |
Konklusjon
Testtilfeller er den viktigste delen av programvareutviklingens livssyklus, og uten den er det vanskelig å spore, forstå, følge og resonnere noe. Men i tiden med Agile blir testsaker raskt erstattet med testscenarier.
En vanlig test sjekkliste for hver type testing (databasetesting, GUI-testing, funksjonalitetstesting osv.) kombinert med testscenarier er det moderne artilleriet for programvaretestere. Diskusjoner, trening, spørsmål og praksis kan definitivt endre den endelige grafen for produktiviteten din samt en feilrapportmatrise.
Som vanlig ønsker vi dine tanker og spørsmål velkommen. Vennligst still inn.
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- Forskjellen mellom testplan, teststrategi, testtilfelle, testskript, testscenario og testtilstand
- Typer programvaretesting: Ulike testtyper med detaljer
- Hvordan skrive testsaker: Den ultimate guiden med eksempler
- Hvordan gjennomgå SRS-dokument og lage testscenarier - Programvare Testing Training på et live prosjekt - Dag 2
- Hvordan klassifisere positive og negative testscenarier - En testers jukseark
- Ytelsestesting vs belastningstesting vs stresstesting (forskjell)
- Statisk testing og dynamisk testing - Forskjellen mellom disse to viktige testteknikkene
- 101 Forskjeller mellom grunnleggende om testing av programvare