what is test scenario
Denna handledning förklarar vad som är testscenario tillsammans med betydelse, implementering, exempel och mallar för testscenario:
Varje programvarufunktion / funktion som kan testas sägs vara ett testscenario. Slutanvändarens perspektiv beaktas när man skriver eventuella testscenarier.
Denna handledning hjälper dig att svara på frågorna: varför testscenarier krävs, när testscenarier skrivs och hur man skriver testscenarier.
Vad du kommer att lära dig:
Vad är ett testscenario?
Tänk på en hypotetisk situation: Det finns ett stort hav. Du måste resa över havet från en strand till en annan. Till exempel, från Mumbai, India Seashore till Colombo, Srilanka seashore.
Vilket resesätt du kan välja är:
(i) Airways: Ta ett flyg till Colombo
(ii) Vattenvägar:Föredrar att ett fartyg reser till Colombo
(iii) Järnvägar:Ta ett tåg till Srilanka
Nu för testscenarierna: Att resa från Mumbai-stranden till Colombo-stranden är en funktion som ska testas.
Testscenarierna inkluderar:
- Resa med Airways,
- Resa med vattenvägar eller
- Resa med järnvägar.
Dessa testscenarier kommer att ha testfall.
Testfall som kan skrivas för ovanstående testscenarier inkluderar:
Testscenario: Resa med flygvägar
Testfall kan innehålla scenarier som:
- Flygningen sker enligt planerad tid.
- Flygningen är inte enligt planerad tid.
- En nödsituation har uppstått (kraftigt regn och storm).
På samma sätt kan en separat uppsättning testfall skrivas för andra återstående scenarier.
Låt oss nu komma till de tekniska testscenarierna.
Allt som kan testas är ett testscenario. Således kan vi konstatera att alla programvarufunktioner som testas och kan delas in i flera mindre funktioner och kan betecknas som ”testscenario”.
Innan du levererar någon produkt till kunden måste produktens kvalitet utvärderas och utvärderas. Testscenariot hjälper till att bedöma den funktionella kvaliteten på en programvara som överensstämmer med företagets krav.
Tester-scenario är en process där testaren testar programvara från ett slutanvändarperspektiv. Programvarans applikationers prestanda och kvalitet utvärderas noggrant innan de implementeras i produktionsmiljön.
Betydelsen av testscenariot
- Ett testscenario kan ha flera ”testfall”. Det kan ses som en stor panoramabild och testfall är de små delarna som är viktiga för att komplettera panorama.
- Det är en enda rad uttalande och testfall består av stegvis beskrivning för att slutföra syftet med testscenariouttalandet.
- Exempel:
Testscenario: Gör betalningen för hytttjänsten.
Detta kommer att ha flera testfall som anges nedan:
(i) Betalningsmetod som ska användas: PayPal, Paytm, kredit- / betalkort.
(ii) Betalningengjort är framgångsrikt.
(iii) Betalningen är misslyckad.
(iv) Betalningenprocessen avbröts däremellan.
(v) Det går inte att komma åt betalningsmetoder.
(vi) Ansökanbryts ner emellan.
- Testscenarier hjälper således till att utvärdera programvaran enligt de verkliga situationerna.
- Testscenarier när de är bestämda, hjälp med att dela upp testningens omfattning.
- Denna förgrening kallas för prioritering som hjälper till att bestämma de viktiga funktionerna i programvaran.
- Prioriterad testning av funktionerna hjälper till i stor utsträckning vid framgångsrik implementering av programvaran.
- Eftersom testscenarierna prioriteras kan de viktigaste funktionerna lätt identifieras och testas på prioritet. Detta säkerställer att majoriteten av de avgörande funktionerna fungerar bra och defekter relaterade till den fångas upp och rättas på rätt sätt.
- Testscenarier bestämmer mjukvarans affärsprocessflöde och därmed är det möjligt att testa applikationen helt och hållet.
Skillnaden mellan testscenario och testfall
hur öppnar jag bin-filer
Testscenario | Testfall |
---|---|
Korta dokumentationer krävs. | Detaljerad dokumentation krävs. |
Testscenario är ett koncept. | Testfall är lösningarna för att verifiera det konceptet. |
Testscenario är en hög funktionalitet. | Testfall är detaljerade procedurer för att testa funktionaliteten på hög nivå. |
Testscenarier härrör från krav / användarberättelser. | Testfall härleds från testscenarier. |
Testscenario är ”Vilken funktionalitet ska testas” | Testfall är ”Hur man testar funktionaliteten”. |
Testscenarier har flera testfall. | Testfall kan eller kanske inte associeras med flera testscenarier. |
Enstaka testscenarier är aldrig repeterbara. | Enstaka testfall kan användas flera gånger i olika scenarier. |
Brainstorming-sessioner krävs för att slutföra ett testscenario. | Detaljerad teknisk kunskap om programvaran krävs |
Tidsbesparing eftersom minutdetaljer inte krävs. | Tidsödande eftersom varje minuts detalj måste tas om hand. |
Underhållskostnaden är låg eftersom de resurser som krävs är låga. | Underhållskostnaderna är höga eftersom de resurser som krävs är höga |
Varför är testscenarier oumbärliga?
Testscenarier härrör från krav eller användarberättelser.
- Ta exemplet på ett testscenario för hyttbokning.
- Scenarierna kan vara som bokningsalternativ för hytt, betalningsmetoder, GPS-spårning, vägkarta visas korrekt eller inte, hytt- och förardetaljer visas korrekt eller inte, etc, alla listas i testscenariomallen.
- Antag nu att testscenariot är att kontrollera om platstjänsterna är påslagna, om de inte är påslagna, visa meddelandet ”Slå på platstjänster”. Detta scenario saknas och listas inte i testscenarimallen.
- ”Platstjänst” -scenariot ger upphov till andra testscenarier relaterade till det. Dessa kan vara:
- Platstjänst nedtonad.
- Platstjänsten aktiverad men inget internet.
- Begränsningar för platstjänster.
- Fel plats visas.
- Saknar ett enda scenario kan innebära att man går miste om många andra avgörande scenarier eller testfall . Detta kan ha en stor negativ påverkan medan du implementerar programvaran. Detta resulterar i en kraftig förlust av resurser (deadlines).
- Testscenarier hjälper till i stor utsträckning i undvika uttömmande testning . Det säkerställer att alla viktiga och förväntade affärsflöden testas, vilket ytterligare hjälper i slutet till slutet av testningen av applikationen.
- Dessa är tidsbesparare. Det krävs inte heller en mycket detaljerad beskrivning enligt testfallet. En one-liner-beskrivning specificeras om vad som ska testas.
- Testscenarier skrivs efter brainstorming sessioner av lagmedlemmarna. Därför är sannolikheten för att missa något scenario (avgörande eller mindre) minimal. Detta görs med tanke på de tekniska egenskaperna och även affärsflödet för programvaran.
- Dessutom kan testscenarierna godkännas antingen av affärsanalytiker eller klient eller båda som har den uttryckliga kunskapen om applikationen som testas.
Testscenarier är alltså en oumbärlig del av SDLC.
Implementering av testscenarier
Låt oss se implementeringen av testscenarier eller hur man skriver testscenarier-
- Epics / Business-krav skapas.
- Exempel på Epic : Skapa ett Gmail-konto. Epic kan vara huvudfunktionen i en applikation eller ett affärsbehov.
- Epics är uppdelade i mindre användarberättelser över sprints.
- Användarberättelser härrör från Epics. Dessa användarberättelser måste baseras och godkännas av intressenter.
- Testscenarier härrör från användarberättelser eller BRS (Business Requirement Document), SRS (System Requirement Specification Document) eller FRS (Functional Requirement Document) som är slutförd och baslinjerad.
- Testare skriver testscenarierna.
- Dessa testscenarier är godkända av Team Lead, Business Analyst eller Project Manager beroende på organisation.
- Varje testscenario måste kopplas till minst en användarberättelse.
- Såväl positiva som negativa testscenarier måste identifieras.
- Användarberättelser består av Godtagningskriterier som :
- Godtagningskriterier är en lista med villkor eller avsiktstillstånd för kundens krav. Kundens förväntningar och missförstånd beaktas när man skriver acceptanskriterierna.
- Dessa är unika för en användarberättelse och varje användarberättelse måste ha minst ett acceptanskriterium som ska kunna testas oberoende av varandra.
- Godtagningskriterier hjälper till att avgöra vilka funktioner som är inom räckvidden och vilka som är utanför räckvidden för ett projekt. Dessa kriterier bör inkludera funktionella såväl som icke-funktionella funktioner.
- Affärsanalytiker skriver godkännandekriterierna och produktägaren godkänner dem.
- Eller i vissa fall kan produktägaren själv skriva kriterierna.
- Testscenarier kan erhållas från acceptanskriterierna.
Exempel på testscenarier
# 1) Testscenarier för Kindle-appen
Kindle är appen som gör det möjligt för sina e-läsare att söka efter e-böcker online, ladda ner och köpa dem. Amazon Kindle ger e-bokläsaren den verkliga upplevelsen att hålla en bok i handen och läsa den. Även sidvisningen simuleras snyggt i appen.
Låt oss nu notera testscenarierna. ( Notera: Begränsade scenarier listas nedan för att få en allmän uppfattning om hur man skriver testscenariot. Det kan finnas flera testfall härledda från det).
Testscenarier # | Testa scenarier |
---|---|
7 | Kontrollera att nedladdningsfunktionen fungerar korrekt. |
1 | Kontrollera om Kindle-appen startar ordentligt. |
två | Kontrollera att skärmupplösningen justeras enligt olika enheter efter applansering. |
3 | Kontrollera att texten som visas är läsbar. |
4 | Kontrollera att zooma in och zooma ut fungerar. |
5 | Kontrollera att kompatibla filer som importeras i Kindle-appen är läsbara. |
6 | Verifiera lagringskapaciteten i Kindle App. |
8 | Verifiera att sidsvängsimulering fungerar korrekt |
9 | Verifiera kompatibiliteten med eBook-format med Kindle-appen. |
10 | Verifiera teckensnitt som stöds av Kindle-appen. |
elva | Kontrollera batteriets livslängd som används av Kindle-appen. |
12 | Verifiera prestanda för Kindle beroende på nätverksanslutning (Wi-Fi, 3G eller 4G). |
Flera testfall kan härledas från varje testscenario som anges ovan.
# 2) Godkännandekriterier för Google Dokument
”Google docs” är en webbaserad applikation för att skapa, redigera och dela orddokument, kalkylark, bilder och formulär. Alla filer kan nås online via en webbläsare som har en internetanslutning.
De skapade dokumenten kan delas som en webbsida eller ett utskriftsfärdigt dokument. Användaren kan ställa in begränsningar för vem som kan visa och redigera dokumenten. Ett enda dokument kan delas och bearbetas tillsammans av olika individer från olika geografiska platser.
Begränsade testscenarier nämns nedan för allmän förståelse. Djupgående testscenarier för Google-dokument kan vara ett helt separat ämne.
Acceptanskriterier # | Acceptanskriterier |
---|---|
7 | Flera användare kan arbeta på ett dokument. |
1 | Word, Sheets eller Forms kan öppnas utan fel. |
två | Mallar finns för dokument, ark och bilder. |
3 | Tillgängliga mallar är tillgängliga för användare. |
4 | Mall som används kan redigeras (t.ex. teckensnitt, teckenstorlek, lägga till text, radera text, infoga bild). |
5 | Om internetanslutning inte är tillgänglig tillfälligt kan filen lagras lokalt och laddas upp efter tillgänglighet av internetanslutning. |
6 | Ändringar som görs av flera användare skrivs inte över. |
8 | Det utförda arbetet lagras om internetanslutningen går förlorad när du laddar upp en fil. |
9 | Delningsbegränsningar tillämpas korrekt. |
10 | Visningsbegränsningsanvändare kan inte göra några ändringar av dokumenten. |
elva | Dokument kan publiceras på internet för allmänheten. |
12 | Ändringar gjorda i dokument sparas med tidsstämpel och författardetaljer. |
Antalet testscenarier kommer att vara flera och mycket stora för Google Docs. I sådana fall generellt sett är endast acceptanskriterierna fastställda och godkända av intressenter, och teammedlemmarna arbetar med dessa acceptanskriterier. Att skriva testfall för eller snarare testscenarier kan vara den uttömmande uppgiften för stora applikationer.
Dessa acceptanskriterier spelar en viktig roll i iterativ processplanering och bör aldrig förbises. Att definiera dem i förväg och i förväg undviker överraskningar eller chocker i slutet av sprints eller släpp
Given en förutsättning.
När att göra en handling.
Sedan det förväntade resultatet.
Formaten för given, när och sedan är användbara för att specificera acceptanskriterier.
Exempel på testscenarimall
Använd Story ID # | Testscenario-ID # | Version # | Testa scenarier | # Antal testfall | Betydelse |
---|---|---|---|---|---|
USID12.1 | TSID12.1.1 | Kin12.4 | Kontrollera om Kindle-appen startar ordentligt. | 4 | Hög |
USID12.1 | TSID12.1.2 | Kin12.4 | Verifiera lagringskapaciteten i Kindle App. | 3 | Medium |
Slutsats
I alla programvarutestningar är livscykelförståelse och fastställande av testscenarier ett mycket viktigt element. Kvaliteten på programvaran kan förbättras genom att ha en bra grund för testscenarier. Ofta kan användningen av testfall och testscenarier bytas ut.
Tumregeln är dock att testscenariot används för att skriva flera testfall eller vi kan säga att testfall härrör från testscenarier. Väl definierade testscenarier säkerställer mjukvara av god kvalitet.
Rekommenderad läsning
- Exempel på programvara Testplanmall med format och innehåll
- Exempel på testfallsmall med exempel på testfall (Ladda ner)
- Exempelmall för godkännandeprovrapport med exempel
- Mallar i C ++ med exempel
- Python DateTime-handledning med exempel
- Klipp kommandot i Unix med exempel
- Testscenario mot testfall: Vad är skillnaden mellan dessa?
- Blazemeter-plugin och Jmeter-mall