Denne vejledning forklarer, hvad et testscenarie er, samt vigtigheden, implementeringen, eksemplerne og skabelonerne for et testscenarie:
Enhver softwarefunktionalitet/-funktion, der kan testes, kaldes et testscenarie. Slutbrugerperspektivet tages i betragtning, når der skrives testscenarier.
Denne vejledning vil hjælpe dig med at besvare spørgsmålene: hvorfor testscenarier er nødvendige, hvornår testscenarier skal skrives, og hvordan man skriver testscenarier.
Hvad er et testscenarie?
Overvej en hypotetisk situation: Der er et stort hav, og du skal rejse over havet fra den ene kyst til den anden. For eksempel, fra Mumbai, Indien kysten til Colombo, Srilanka kysten.
Du kan vælge mellem følgende rejseformer:
(i) Luftfartsselskaber: Tag et fly til Colombo
(ii) Vandveje: Foretrækker et skib til Colombo
(iii) Jernbaner: Tag et tog til Srilanka
Nu til testscenarierne: At rejse fra Mumbai kysten til Colombo kysten er en funktionalitet, der skal afprøves.
Testscenarierne omfatter:
- Rejser med fly,
- Rejser ad vandveje eller
- Rejser med jernbane.
Disse testscenarier vil have testcases.
Testcases, der kan skrives for ovenstående testscenarier, omfatter:
Testscenarie: Rejser med flyselskaber
Testcases kan omfatte scenarier som f.eks:
- Flyvningen er som planlagt.
- Flyvningen er ikke som planlagt.
- Der er opstået en nødsituation (kraftig nedbør og storm).
På samme måde kan der skrives et separat sæt testcases for andre resterende scenarier.
Lad os nu gå over til de teknologiske testscenarier.
Alt, hvad der kan testes, er et testscenarie. Vi kan således sige, at enhver softwarefunktionalitet, der testes, kan opdeles i flere mindre funktionaliteter og kan betegnes som et "testscenarie".
Før et produkt leveres til kunden, skal produktets kvalitet vurderes og evalueres. Testscenarier hjælper med at vurdere den funktionelle kvalitet af en softwareapplikation, der er i overensstemmelse med forretningskravene.
Et tester-scenarie er en proces, hvor testeren tester en softwareapplikation fra et slutbrugerperspektiv. Softwareapplikationens ydeevne og kvalitet vurderes grundigt, før den implementeres i produktionsmiljøet.
Betydningen af testscenariet
- Et testscenarie kan have flere "testtilfælde" Det kan opfattes som et stort panoramabillede, og testtilfælde er de små dele, som er vigtige for at fuldende panoramaet.
- Det er en enkelt linje, og testcases omfatter en trinvis beskrivelse for at opfylde formålet med testscenariet.
- Eksempel:
Testscenarie: Betal for den benyttede taxitjeneste.
Der vil være flere testcases som anført nedenfor:
(i) Betalingsmetode: PayPal, Paytm, kredit-/debitkort.
(ii) Betalingen er gennemført med succes.
(iii) Betalingen er ikke lykkedes.
(iv) Betalingen blev afbrudt i mellemtiden.
(v) Ikke i stand til at få adgang til betalingsmetoder.
(vi) Ansøgningen bryder sammen i mellemtiden.
- Testscenarier hjælper således med at evaluere softwareapplikationen i forhold til den virkelige verden.
- Testscenarier, når de er fastlagt, hjælper med at opdele testens omfang.
- Denne opdeling kaldes prioritering, som hjælper med at bestemme de vigtige funktioner i softwareapplikationen.
- Prioriteret test af funktionaliteterne hjælper i høj grad med at sikre en vellykket implementering af softwareapplikationen.
- Når testscenarierne bliver prioriteret, kan de vigtigste funktionaliteter nemt identificeres og testes efter prioritet. Dette sikrer, at størstedelen af de vigtige funktionaliteter fungerer fint, og at fejl relateret til dem bliver behørigt registreret og rettet.
- Testscenarierne bestemmer forretningsprocessens flow i softwaren, og det er således muligt at teste applikationen fra ende til ende.
Forskellen mellem testscenarie og testcase
| Testscenarie | Testcases |
|---|---|
| Testscenarie er et koncept. | Testcases er løsningerne til at verificere dette koncept . |
| Testscenarie er en funktionalitet på højt niveau. | Testcases er en detaljeret procedure til at teste funktionaliteten på højt niveau. |
| Testscenarier er afledt af krav/brugerhistorier. | Testcases er afledt af testscenarier . |
| Testscenariet er "Hvilken funktionalitet skal testes". | Testcases er "hvordan man tester funktionaliteten". |
| Testscenarier har flere testcases. | Testtilfælde kan være tilknyttet flere testscenarier eller ej. |
| Enkeltstående testscenarier kan aldrig gentages. | En enkelt testcase kan anvendes flere gange i forskellige scenarier. |
| Kortfattet dokumentation er påkrævet. | Der kræves detaljeret dokumentation. |
| Brainstorming-sessioner er nødvendige for at færdiggøre et testscenarie. | Detaljeret teknisk viden om softwareapplikationen er påkrævet |
| Det sparer tid, da der ikke er brug for minutiøse detaljer. | Tidskrævende, da hver eneste lille detalje skal passes. |
| Vedligeholdelsesomkostningerne er lave, da der kun kræves få ressourcer. | Omkostningerne til vedligeholdelse er høje, da der kræves mange ressourcer |
Hvorfor er testscenarier uundværlige?
Testscenarier er afledt af krav eller brugerhistorier.
- Tag et eksempel på et testscenarie for reservation af taxaer.
- Scenarierne kan være muligheder for at bestille taxaer, betalingsmetoder, GPS-sporing, vejkort, der vises korrekt eller ej, taxa- og chaufføroplysninger, der vises korrekt eller ej osv., som alle er anført i skabelonen for testscenarier.
- Lad os nu antage, at testscenariet skal kontrollere, om placeringstjenesterne er aktiveret, og hvis de ikke er aktiveret, skal meddelelsen "Turn on-location services" vises. Dette scenario er ikke medtaget og er ikke opført i skabelonen for testscenarier.
- Scenariet "lokaliseringstjeneste" giver anledning til andre testscenarier i tilknytning hertil.
Det kan være:
- Placeringstjenesten er gråtonet.
- Lokaliseringstjenesten er slået til, men der er intet internet.
- Begrænsninger for tjenester på stedet.
- Den forkerte placering vises.
- Manglende et enkelt scenario kan betyde, at man går glip af mange andre afgørende scenarier eller testcases . dette kan have en stor betydning negativ indvirkning Dette medfører et stort tab af ressourcer (tidsfrister).
- Testscenarier er i høj grad med til at at undgå udtømmende prøvning Det sikrer, at alle de vigtige og forventede forretningsstrømme bliver testet, hvilket yderligere hjælper med at teste applikationen fra ende til ende.
- Det er tidsbesparende. Der er heller ikke behov for en meget mere detaljeret beskrivelse af testcases. Der er kun behov for en enlinjers beskrivelse af, hvad der skal testes.
- Testscenarierne skrives efter brainstorming-sessioner Dermed er sandsynligheden for at overse et scenarie (afgørende eller mindre vigtigt) minimal. Dette gøres under hensyntagen til de tekniske detaljer og også til softwareapplikationens forretningsflow.
- Desuden kan testscenarierne godkendes enten af en forretningsanalytiker eller af en kunde eller af begge parter, som har eksplicit kendskab til den applikation, der skal testes.
Testscenarier er derfor en uundværlig del af SDLC.
Gennemførelse af testscenarier
Lad os se på implementeringen af testscenarier eller hvordan man skriver testscenarier:
- Epics/forretningskrav udarbejdes.
- Eksempel på Epic : Opret en Gmail-konto. Epic kan være den vigtigste funktion i et program eller et forretningskrav.
- Epics er opdelt i mindre brugerhistorier på tværs af sprints.
- Brugerhistorier er afledt af Epics. Disse brugerhistorier skal baselineres og godkendes af interessenterne.
- Testscenarier udledes af brugerhistorier eller BRS (Business Requirement Document), SRS (System Requirement Specification Document) eller FRS (Functional Requirement Document), som er færdiggjort og baseret.
- Testerne skriver testscenarierne.
- Disse testscenarier godkendes af teamleder, forretningsanalytiker eller projektleder, afhængigt af organisationen.
- Hvert testscenarie skal være knyttet til mindst én brugerhistorie.
- Der skal identificeres positive såvel som negative testscenarier.
- Brugerhistorier omfatter Acceptkriterier som :
- Acceptkriterier er en liste over betingelser eller en liste over hensigten med kundekravene. Kundens forventninger og misforståelser tages i betragtning, når acceptkriterierne skrives.
- Disse er unikke for en brugerhistorie, og hver brugerhistorie skal have mindst ét acceptkriterium, som skal kunne testes uafhængigt af hinanden.
- Acceptkriterierne hjælper med at afgøre, hvilke funktioner der er omfattet og hvilke der ikke er omfattet af et projekt. Disse kriterier bør omfatte både funktionelle og ikke-funktionelle funktioner.
- Forretningsanalytikere skriver godkendelseskriterierne, og produktejeren godkender dem.
- Eller i nogle tilfælde kan produktejeren selv skrive kriterierne.
- Testscenarier kan fås fra acceptkriterierne.
Eksempler på testscenarier
#1) Testscenarier for Kindle App
Kindle er den app, der gør det muligt for e-bogslæsere at søge efter e-bøger online, downloade og købe dem. Amazon Kindle giver e-bogslæseren den virkelige oplevelse af at holde en bog i hånden og læse den. Selv omslaget af siderne simuleres fint i appen.
Lad os nu notere testscenarierne. ( Bemærk: Nedenfor er der anført begrænsede scenarier for at få en generel idé om, hvordan testscenariet skal skrives. Der kan være flere testcases afledt af det).
| Testscenarier # | Testscenarier |
|---|---|
| 1 | Kontroller, om Kindle-appen starter korrekt. |
| 2 | Kontroller, at skærmopløsningen justeres efter de forskellige enheder, når appen er startet. |
| 3 | Kontroller, at den viste tekst er læsbar. |
| 4 | Kontroller, at zoom ind og zoom ud fungerer. |
| 5 | Kontroller, at kompatible filer, der importeres i Kindle-appen, kan læses. |
| 6 | Kontroller lagerkapaciteten på Kindle App. |
| 7 | Kontroller, at downloadfunktionen fungerer korrekt. |
| 8 | Kontroller, at simuleringen af sideskift fungerer korrekt |
| 9 | Kontroller, om e-bogsformatet er kompatibelt med Kindle-appen. |
| 10 | Kontroller skrifttyper, der understøttes af Kindle-appen. |
| 11 | Kontroller den batterilevetid, der udnyttes af Kindle-appen. |
| 12 | Kontroller Kindles ydeevne afhængigt af netværksforbindelsen (Wi-Fi, 3G eller 4G). |
Der kan udledes flere testcases fra hvert af de ovennævnte testscenarier.
#2) Godkendelseskriterier for Google Docs
Google Docs er et webbaseret program til at oprette, redigere og dele Word-dokumenter, regneark, dias og formularer. Alle filer kan tilgås online ved hjælp af en webbrowser med internetforbindelse.
De oprettede dokumenter kan deles som en webside eller et udskriftsklart dokument. Brugeren kan fastsætte begrænsninger for, hvem der kan se og redigere dokumenterne. Et enkelt dokument kan deles i fællesskab og bearbejdes af forskellige personer fra forskellige geografiske steder.
Nedenfor er der nævnt begrænsede testscenarier til generel forståelse. Detaljerede testscenarier for Google Docs kan være et helt andet emne.
| Godkendelseskriterier # | Godkendelseskriterier |
|---|---|
| 1 | Word, Sheets eller Forms kan åbnes uden fejl. |
| 2 | Der findes skabeloner til dokumenter, ark og dias. |
| 3 | De tilgængelige skabeloner er tilgængelige for brugerne. |
| 4 | Den anvendte skabelon kan redigeres (f.eks. skrifttyper, skriftstørrelse, tilføjelse af tekst, sletning af tekst, indsættelse af dias). |
| 5 | Hvis internetforbindelsen ikke er tilgængelig midlertidigt, kan filen gemmes lokalt og uploades, når internetforbindelsen er tilgængelig. |
| 6 | Ændringer foretaget af flere brugere overskrives ikke. |
| 7 | Flere brugere kan arbejde på samme dokument. |
| 8 | Det udførte arbejde gemmes, hvis internetforbindelsen går tabt, mens du uploader en fil. |
| 9 | Delingsbegrænsninger anvendes korrekt. |
| 10 | Brugere med visningsbegrænsning kan ikke redigere dokumenterne. |
| 11 | Dokumenter kan offentliggøres på internettet for offentligheden. |
| 12 | Ændringer i dokumenter gemmes med tidsstempel & forfatteroplysninger. |
Antallet af testscenarier vil være mange og meget stort for Google Docs. I sådanne tilfælde er det normalt kun acceptkriterierne, der fastsættes og godkendes af interessenterne, og teammedlemmerne arbejder på disse acceptkriterier. At skrive testcases til eller rettere testscenarier kan være en udtømmende opgave for store applikationer.
Disse acceptkriterier spiller en vigtig rolle i den iterative procesplanlægning og bør aldrig overses. Ved at definere dem på forhånd og på forhånd undgår man overraskelser eller chok ved afslutningen af sprints eller udgivelser.
I betragtning af en forudsætning.
Når til at udføre en handling.
Derefter resultatet er forventet.
Formaterne Given, When og Then er nyttige til at specificere acceptkriterier.
Eksempel på skabelon til testscenarier
| Brug Story ID # | Testscenarie ID nr. | Version # | Testscenarier | # Antal testtilfælde | Vigtighed |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1.1 | Kin12.4 | Kontroller, om Kindle-appen starter korrekt. | 4 | Høj |
| USID12.1 | TSID12.1.2 | Kin12.4 | Kontroller lagerkapaciteten på Kindle App. | 3 | Medium |
Konklusion
I enhver softwaretestning er forståelse af livscyklus og fastlæggelse af testscenarier et meget vigtigt element. Kvaliteten af softwaren kan forbedres ved at have et godt grundlag for testscenarier. Ofte kan brugen af testcases og testscenarier blive forvekslet.
Men tommelfingerreglen er, at testscenariet bruges til at skrive flere testcases, eller vi kan sige, at testcases er afledt af testscenarier. Veldefinerede testscenarier sikrer software af god kvalitet.