Wat is een testscenario: testscenario-sjabloon met voorbeelden

what is test scenario

In deze zelfstudie wordt uitgelegd wat een testscenario is, samen met het belang, de implementatie, voorbeelden en sjablonen van testscenario's:

Elke softwarefunctie / -functie die kan worden getest, wordt beschouwd als een testscenario. Bij het schrijven van testscenario's wordt rekening gehouden met het perspectief van de eindgebruiker.

Deze tutorial helpt je bij het beantwoorden van de vragen: waarom testscenario's nodig zijn, wanneer testscenario's worden geschreven en hoe de testscenario's moeten worden geschreven.

Wat je leert:

• Wat is een testscenario?
  • Belang van testscenario
  • Verschil tussen testscenario en testcase
  • Waarom zijn testscenario's onmisbaar?
  • Implementatie van testscenario's
• Voorbeelden van testscenario's
  • # 1) Testscenario's voor de Kindle-app
  • # 2) Acceptatiecriteria voor Google Documenten
  • Voorbeeld van testscenario-sjabloon
• Gevolgtrekking
  • Aanbevolen literatuur

Wat is een testscenario?

Beschouw een hypothetische situatie: Er is een enorme oceaan. Je moet van de ene kust naar de andere over de oceaan reizen. Bijvoorbeeld, van Mumbai, India Seashore naar Colombo, Srilanka kust.

De manier van reizen die u kunt kiezen, zijn:

(i) Luchtwegen: Neem een ​​vlucht naar Colombo

(ii) Waterwegen:Liever een schip om naar Colombo te reizen

(iii) Spoorwegen:Neem een ​​trein naar Srilanka

Nu voor de testscenario's: Reizen van de kust van Mumbai naar de kust van Colombo is een functionaliteit die moet worden getest.

De testscenario's omvatten:

• Reizen per vliegtuig,
• Reizen via waterwegen of
• Reizen met de spoorwegen.

Deze testscenario's hebben testcases.

Testcases die kunnen worden geschreven voor de bovenstaande testscenario's zijn onder meer:

Testscenario: Reizen per vliegtuig

Testcases kunnen scenario's bevatten zoals:

1. De vlucht is volgens de geplande tijd.
2. De vlucht is niet volgens de geplande tijd.
3. Er is een noodsituatie ontstaan ​​(zware regenval en storm).

Op dezelfde manier kan een aparte set testcases worden geschreven voor andere resterende scenario's.

Laten we nu eens kijken naar de technologische testscenario's.

Alles dat kan worden getest, is een testscenario. We kunnen dus stellen dat elke softwarefunctionaliteit die wordt getest en kan worden onderverdeeld in meerdere kleinere functionaliteiten en kan worden aangeduid als ‘Testscenario’.

Voordat een product aan de klant wordt geleverd, moet de kwaliteit van het product worden beoordeeld en geëvalueerd. Testscenario helpt bij het beoordelen van de functionele kwaliteit van een softwareapplicatie die in overeenstemming is met de zakelijke vereisten.

Testerscenario is een proces waarin de tester de softwareapplicatie test vanuit het perspectief van de eindgebruiker. De prestaties en kwaliteit van de softwareapplicatie worden grondig beoordeeld voordat ze in de productieomgeving worden geïmplementeerd.

Belang van testscenario

• Een testscenario kan meerdere ‘testgevallen’ bevatten. Het kan worden voorgesteld als een groot panoramisch beeld en testcases zijn de kleine onderdelen die belangrijk zijn om het panorama te voltooien.
• Het is een verklaring van één regel en testgevallen bestaan ​​uit een stapsgewijze beschrijving om het doel van de testscenario-verklaring te voltooien.
• Voorbeeld:

Testscenario: Betaal voor de taxiservice waarvan u gebruik heeft gemaakt.

Dit heeft meerdere testcases, zoals hieronder vermeld:

(ik) Te gebruiken betalingsmethode: PayPal, Paytm, creditcard / betaalkaart.
(ii) De betalinggedaan is succesvol.
(iii) De uitgevoerde betaling is mislukt.
(iv) De betalingproces tussendoor afgebroken.
(v) Geen toegang tot betaalmethoden.
(wij) De applicatiebreekt tussendoor af.

• Testscenario's helpen dus bij het evalueren van de softwareapplicatie volgens de praktijksituaties.
• Testscenario's, indien bepaald, helpen bij het splitsen van de testomvang.
• Deze bifurcatie wordt prioritering genoemd, die helpt bij het bepalen van de belangrijke functionaliteiten van de softwareapplicatie.
• Geprioriteerde testen van de functionaliteiten, helpen in hoge mate bij de succesvolle implementatie van de softwareapplicatie.
• Naarmate de testscenario's prioriteit krijgen, kunnen de belangrijkste functionaliteiten eenvoudig worden geïdentificeerd en op prioriteit worden getest. Dit zorgt ervoor dat de meeste van de cruciale functionaliteiten goed werken en dat daarmee verband houdende defecten naar behoren worden opgevangen en verholpen.
• Testscenario's bepalen de bedrijfsprocesstroom van de software en daarmee is end-to-end testen van de applicatie mogelijk.

Verschil tussen testscenario en testcase

Waarom zijn testscenario's onmisbaar?

Testscenario's zijn afgeleid van vereisten of gebruikersverhalen.

• Neem het voorbeeld van een testscenario voor het boeken van taxi's.
• De scenario's kunnen zijn zoals taxiboekingsopties, betalingsmethoden, gps-tracking, wegenkaart correct weergegeven of niet, cabine- en chauffeursgegevens correct weergegeven of niet, enz. Worden allemaal vermeld in het testscenario-sjabloon.
• Stel nu dat het testscenario is om te controleren of de locatieservices zijn ingeschakeld, zo niet, geef dan het bericht ‘Locatiediensten inschakelen’ weer. Dit scenario wordt gemist en wordt niet vermeld in de sjabloon voor testscenario's.
• Het ‘Locatieservice’ -scenario leidt tot andere testscenario's die ermee verband houden. Deze kunnen zijn:
  • Locatieservice wordt grijs weergegeven.
  • De locatieservice is ingeschakeld, maar geen internet.
  • Beperkingen voor locatiediensten.
  • De verkeerde locatie wordt weergegeven.
• Een enkel scenario ontbreekt kan betekenen dat u vele andere mist cruciale scenario's of testcases ​Dit kan geweldig zijn negatieve impact tijdens het implementeren van de softwareapplicatie. Dit resulteert in een groot verlies aan middelen (deadlines).
• Testscenario's helpen in hoge mate bij het vermijden van uitgebreide tests ​Het zorgt ervoor dat alle cruciale en verwachte bedrijfsstromen worden getest, wat verder helpt bij het testen van de applicatie.
• Dit bespaart tijd. Ook is een veel gedetailleerde beschrijving volgens de testgevallen niet vereist. Er wordt een one-liner-beschrijving gegeven over wat er moet worden getest.
• Testscenario's worden daarna geschreven brainstormsessies van de teamleden. Daarom is de kans om een ​​scenario (cruciaal of klein) te missen minimaal. Hierbij wordt rekening gehouden met de technische details en ook met de zakelijke stroom van de softwareapplicatie.
• Bovendien kunnen de testscenario's worden goedgekeurd door Business Analyst of Client, of beide die de expliciete kennis hebben van de te testen applicatie.

Testscenario's zijn dus een onmisbaar onderdeel van SDLC.

Implementatie van testscenario's

Laten we eens kijken naar de implementatie van testscenario's of hoe testscenario's te schrijven-

• Epics / Business Requirements worden gevormd.
  • Voorbeeld van Epic : Maak een Gmail-account. Episch kan het belangrijkste kenmerk van een applicatie of een zakelijke vereiste zijn.
• Epics zijn onderverdeeld in kleinere gebruikersverhalen over sprints.
• Gebruikersverhalen zijn afgeleid van Epics. Deze gebruikersverhalen moeten worden gebaseerd op en goedgekeurd door belanghebbenden.

• Testscenario's zijn afgeleid van user stories of BRS (Business Requirement Document), SRS (System Requirement Specification Document), of FRS (Functional Requirement Document), dat is afgerond en baseline.
• Testers schrijven de testscenario's.
• Deze testscenario's zijn goedgekeurd door teamleider, bedrijfsanalist of projectmanager, afhankelijk van de organisatie.
• Elk testscenario moet worden gekoppeld aan ten minste één gebruikersverhaal.
• Zowel positieve als negatieve testscenario's moeten worden geïdentificeerd.
• Gebruikersverhalen bestaan ​​uit Acceptatiecriteria zoals ​
  • Acceptatiecriteria zijn een lijst met voorwaarden of de staat van intentie voor de eisen van de klant. Bij het schrijven van de acceptatiecriteria wordt rekening gehouden met de verwachtingen van de klant en ook met de misverstanden.
  • Deze zijn uniek voor één user story en elk user story moet minimaal één acceptatiecriterium hebben dat onafhankelijk toetsbaar moet zijn.
  • Acceptatiecriteria helpen bij het bepalen welke functies binnen de scope van een project vallen en welke niet. Deze criteria moeten zowel functionele als niet-functionele kenmerken omvatten.
  • Business Analisten schrijven de acceptatiecriteria en de Product Owner keurt ze goed.
  • Of in sommige gevallen kan de producteigenaar zelf de criteria schrijven.
  • Testscenario's kunnen worden verkregen uit de acceptatiecriteria.

Voorbeelden van testscenario's

# 1) Testscenario's voor de Kindle-app

Kindle is de app waarmee e-readers online naar e-books kunnen zoeken, ze kunnen downloaden en kopen. Amazon Kindle geeft de e-booklezer de real-life ervaring om een ​​boek in de hand te houden en het te lezen. Zelfs het omslaan van pagina's wordt mooi gesimuleerd in de app.

Laten we nu de testscenario's noteren.​ Notitie: Beperkte scenario's worden hieronder vermeld om een ​​algemeen idee te krijgen voor het schrijven van het testscenario. Er kunnen meerdere testgevallen van worden afgeleid).

Van elk hierboven vermeld testscenario kunnen meerdere testcases worden afgeleid.

# 2) Acceptatiecriteria voor Google Documenten

‘Google docs’ is een webtoepassing om Word-documenten, spreadsheets, dia's en formulieren te maken, bewerken en delen. Alle bestanden zijn online toegankelijk via een webbrowser met een internetverbinding.

De gemaakte documenten kunnen worden gedeeld als een webpagina of een afdrukklaar document. De gebruiker kan beperkingen instellen voor wie de documenten kan bekijken en bewerken. Een enkel document kan gezamenlijk worden gedeeld en bewerkt door verschillende individuen uit verschillende geografische locaties.

Beperkte testscenario's worden hieronder vermeld voor algemeen begrip. Diepgaande testscenario's voor Google-documenten kunnen helemaal een apart onderwerp zijn.

Het aantal testscenario's zal veelvoudig zijn en erg groot voor Google Documenten. In dergelijke gevallen worden over het algemeen alleen de acceptatiecriteria vastgesteld en goedgekeurd door belanghebbenden, en werken de teamleden aan deze acceptatiecriteria. Het schrijven van testcases voor of liever testscenario's kan de uitputtende taak zijn voor enorme applicaties.

Deze acceptatiecriteria spelen een belangrijke rol bij iteratieve procesplanning en mogen nooit over het hoofd worden gezien. Door ze vooraf en vooraf te definiëren, worden verrassingen of schokken aan het einde van sprints of releases vermeden

Gegeven een voorwaarde.
Wanneer om een ​​actie uit te voeren.
Vervolgens het verwachte resultaat.

De formaten Gegeven, Wanneer en Dan zijn nuttig voor het specificeren van acceptatiecriteria.

Voorbeeld van testscenario-sjabloon

Gevolgtrekking

Bij elke softwaretestcyclus is het begrijpen en vastleggen van de testscenario's een zeer belangrijk element. De kwaliteit van de software kan worden verbeterd door een goede basis te hebben voor testscenario's. Vaak kan het gebruik van testcases en testscenario's worden afgewisseld.

hoe u een .swf-bestand uitvoert

De vuistregel is echter dat het testscenario wordt gebruikt om meerdere testcases te schrijven of we kunnen zeggen dat testcases zijn afgeleid van testscenario's. Goed gedefinieerde testscenario's zorgen voor software van goede kwaliteit.

Aanbevolen literatuur

• Voorbeeld van een softwaretestplan-sjabloon met indeling en inhoud
• Voorbeeldtestcase-sjabloon met testcasevoorbeelden (Download)
• Voorbeeldsjabloon voor acceptatietestrapport met voorbeelden
• Sjablonen in C ++ met voorbeelden
• Python DateTime-zelfstudie met voorbeelden
• Snijd Commando in Unix met voorbeelden
• Testscenario versus testcase: wat is het verschil tussen deze twee?
• Blazemeter-plug-in en Jmeter-sjabloon