Introduksjon til testscenario
Testscenario er en kombinasjon av to ord, det vil si test og scenario. Testen representerer en verifisering eller validering, og scenariet representerer brukerens reise. Enhver testbar funksjonalitet kalles et testscenario. Testscenario kan beskrives som bekreftelse eller validering av brukerens reise. Det vil være i form av dokumenter som inneholder alle testsakene som er skrevet i detalj for å teste applikasjoner fra ende til ende. Det er en av høynivåklassifiseringene av krav som kan testes. Det er også kjent som en testmulighet eller en testtilstand.
Hvorfor lage testscenarier?
Flere testsaker kan dekkes av ett testscenario. Forholdet mellom testscenarier og testsaker er derfor en-til-mange. Men hvert scenario må tas vare på av testeren mens det opprettes. Testere oppretter den for å teste applikasjonen fra en sluttbrukeres synspunkt. Testere søker fra alle utviklere, interessenter og kunder om å forberede dem som er kritiske.
Årsaken til å opprette dem er som følger:
- Fullstendig og riktig testdekning sikres ved å lage perfekte testscenarier.
- Opprettelsen av dem blir kritisk for å studere ende-til-ende-funksjonaliteten til et program.
- De viktigste og kritiske ende-til-ende-transaksjoner eller bruk av sanntidsapplikasjoner kan vel bestemmes med riktig hjelp av dem.
- De kan brukes som et verktøy for rask bestemmelse av testing av arbeidsstyrke som videre hjelper klientene eller organisasjonene til å lage forslag og organisere testingen av arbeidsstokken effektivt og effektivt.
- For å sikre en grundig og korrekt testing av applikasjoner, gjøres godkjenning av det på forskjellige nivåer, inkludert kunder, forretningsanalytikere, utviklere, etc.
Tilsvarende kan det være visse omstendigheter der opprettelsen av den bør unngås.
- Det er ikke sikkert at det opprettes i prosjekter som følger smidige metodologier som Scrum, etc.
- Når applikasjonene som skal testes er ustabile, eller for kompliserte, eller når prosjektet er i en kritisk tidsoppretting, kan det unngås.
- Opprettelse av den kan unngås for regresjonstesting eller for en ny feil, fordi i vedlikeholdsprosjekter ville tunge dokumenter på forhånd skje i de tidligere testsyklusene.
Hvordan testscenarier kan skrives?
Følgende trinn kan utføres av en tester for oppretting av testscenarier:
- Trinn 1: Dokumentet med krav som BRS (Business Requirement Specification), Functional Requirement Specification (FRS) og System Requirement Specification (SRS) for applikasjonen som skal testes, bør leses grundig og nøye. Manualer, bøker, brukssaker osv. For applikasjonen som testes kan henvises til det samme.
- Trinn 2: Alle mulige mål og brukerhandlinger skal regnes ut ordentlig for alle krav. Alle tekniske funksjoner i ethvert krav bør også bestemmes.
- Trinn 3: Alle mulige årsaker til systemhack og brukerevaluering bør gjøres fra en hackers perspektiv. Brukerevaluering kan gjøres ved å finne alle mulighetene for brukerdrift av applikasjonene.
- Trinn 4: Det skal lages en fullstendig liste over alle mulige testtilfeller for å verifisere alle funksjonalitetene i applikasjonen etter at du har lest dokumentets krav og fullført analysen.
- Trinn 5: Etter verifisering av alle dem, for å verifisere kravet og dets testscenario, samsvarer det med en sporbarhetsmatrise.
- Trinn 6: Alle de opprettede testscenariene blir gjennomgått og evaluert av veilederen. Det blir også verifisert av alle interessenter.
I henhold til prosjektprosedyren, må hvert testscenario tilpasses minst en brukerhistorie eller krav. Det er obligatorisk å verifisere hvert testscenario mot kravet sitt separat, før flere krav i et enkelt testscenario. Komplekse testscenarier med flere krav kan unngås for enkelhets skyld. Prisen er direkte proporsjonal med antallet av dem. Det anbefales alltid å kjøre kun valgte og nødvendige i henhold til kundens prioritet.
eksempler
Nedenfor er noen eksempler på testscenario
Testscenario for Buykart-applikasjonen på nettet
Testscenarier som kan tas i betraktning for bekreftelse av en online shopping-applikasjon Buykart er som følger:
Testsscenario 1: Innloggingsfunksjonskontroll
Testsakene som kan vurderes for opprettelsen er:
- Oppførselen til applikasjonen når du skriver inn en gyldig innloggings-ID og et gyldig passord, kan kontrolleres.
- Appens oppførsel når du oppgir en gyldig innloggings-ID og et ugyldig passord, kan kontrolleres.
- Appens oppførsel når du oppgir en ugyldig innloggings-ID og et gyldig passord, kan kontrolleres.
- Appens oppførsel når du skriver inn en ugyldig innloggings-ID og et ugyldig passord kan sjekkes.
- Søknadsoppførsel når du logger på ved å legge inn påloggings-id alene uten passord, kan kontrolleres.
- Søknadsoppførsel når du logger på ved å angi passord alene uten innloggings-ID kan sjekkes.
- Søknadsoppførsel når du logger på uten å oppgi både påloggings-ID og passord, kan kontrolleres.
- Oppførsel til applikasjonen når glemt passord er valgt.
Test Scenario 2: Sjekk funksjonalitet for søk
Testsakene som kan vurderes for opprettelsen er:
- Oppførselen til applikasjonen når et gyldig produkt blir søkt.
- Appens oppførsel når et ugyldig produkt blir søkt.
Test Scenario 3: Kontroll av produktdetaljer
Testsakene som kan vurderes for opprettelsen er:
- Oppførselen til applikasjonen når et produkt er valgt.
- Oppførselen til applikasjonen et produkt er på listen.
- Oppførselen til applikasjonen når et produkt legges i handlekurven.
- Appens oppførsel når alternativet Kjøp nå er valgt.
- Oppførselen til applikasjonen når en ugyldig adresse legges inn.
- Oppførselen til applikasjonen når en gyldig adresse legges inn.
- Appens oppførsel når flere betalingsalternativer er sjekket.
Testsscenario 4: Kontroll av betalingsfunksjonalitet
Testsakene som kan vurderes for opprettelsen er:
- Oppførselen til applikasjonen når hvert betalingsalternativ er valgt.
- Oppførselen til applikasjonen når et gyldig betalingsalternativ velges.
- Oppførselen til applikasjonen når et ugyldig betalingsalternativ er valgt.
- Oppførselen til applikasjonen når en betaling er vellykket.
- Oppførselen til applikasjonen når en betaling blir avvist.
Testsscenario 5: Kontroller funksjonalitet for bestillingsdetaljer
Testsakene som kan vurderes for opprettelsen er:
- Oppførselen til applikasjonen når hver ordre er valgt.
- Appens oppførsel når alternativet Returprodukt er valgt.
- Appens oppførsel når sporproduktalternativ er valgt.
- Appens oppførsel når alternativet Gjennomgå produkt er valgt.
Konklusjon
Det fungerer som en riktig guide til testerne og hjelper dem å gjøre testing mer effektiv og effektiv. Det hjelper med å redusere testkompleksiteten og redundansen. Hver test case er skrevet i detalj for bedre forståelse. Det er svært tidsbesparende for testere.
Anbefalte artikler
Dette har vært en guide til What is Test Scenario. Her diskuterer vi hvordan du lager testscenarier med forskjellige eksempler. Du kan også se på følgende artikler for å lære mer -
- Jobben usikkerhet stress
- Selvmotivert og dedikert
- Hva er smidig testing?
- Hvordan skrive test case?