In deze tutorial wordt uitgelegd wat een testscenario is en wat het belang, de uitvoering, de voorbeelden en de sjablonen van een testscenario zijn:
Elke softwarefunctionaliteit/functie die kan worden getest, wordt een Testscenario genoemd. Bij het schrijven van testscenario's wordt rekening gehouden met het perspectief van de eindgebruiker.
Deze tutorial helpt u 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 is een testscenario?
Beschouw een hypothetische situatie: Er is een grote oceaan. Je moet over de oceaan reizen van de ene kust naar de andere. Bijvoorbeeld, van Mumbai, India Seashore naar Colombo, Srilanka Seashore.
De manieren van reizen die u kunt kiezen zijn:
(i) Vliegtuigen: Neem een vlucht naar Colombo
(ii) Waterwegen: Geef de voorkeur aan een schip om naar Colombo te reizen.
(iii) Spoorwegen: Neem een trein naar Srilanka.
Nu de testscenario's: Reizen van Mumbai seashore naar Colombo seashore is een functionaliteit die getest moet worden.
De testscenario's omvatten:
- Reizen per vliegtuig,
- Reizen over waterwegen of
- Reizen per spoor.
Deze testscenario's zullen testgevallen bevatten.
Testgevallen die voor bovenstaande testscenario's kunnen worden geschreven, zijn onder meer:
Testscenario: Reizen per vliegtuig
Testgevallen kunnen scenario's omvatten zoals:
- De vlucht is volgens de geplande tijd.
- De vlucht is niet volgens schema.
- Er is een noodsituatie ontstaan (zware regenval en storm).
Op dezelfde manier kan een aparte reeks testgevallen worden geschreven voor andere resterende scenario's.
Nu de technologische testscenario's.
Alles wat getest kan worden is een Testscenario. We kunnen dus stellen dat elke softwarefunctionaliteit die wordt getest, kan worden onderverdeeld in meerdere kleinere functionaliteiten en een "testscenario" kan worden genoemd.
Voordat een product aan de klant wordt geleverd, moet de kwaliteit ervan worden beoordeeld en geëvalueerd. Het testscenario helpt bij de beoordeling van de functionele kwaliteit van een softwaretoepassing die in overeenstemming is met de zakelijke vereisten.
Een testerscenario is een proces waarbij de tester een softwareapplicatie test vanuit het perspectief van de eindgebruiker. De prestaties en de kwaliteit van de softwareapplicatie worden grondig beoordeeld voordat deze in de productieomgeving wordt geïmplementeerd.
Belang van testscenario's
- Een Testscenario kan meerdere 'Test Cases' hebben. Het kan worden voorgesteld als een groot panoramisch beeld en testcases zijn de kleine delen die belangrijk zijn om het panorama te voltooien.
- Het is een éénregelige verklaring en de testgevallen bestaan uit een stapsgewijze beschrijving om het doel van de testscenarioverklaring te voltooien.
- Voorbeeld:
Testscenario: Maak de betaling voor de gebruikte taxi service.
Dit zal meerdere testgevallen hebben zoals hieronder vermeld:
(i) Te gebruiken betalingsmethode: PayPal, Paytm, krediet/debetkaart.
(ii) De betaling is gelukt.
(iii) De betaling is mislukt.
(iv) Het betalingsproces is tussentijds afgebroken.
(v) Geen toegang tot betaalmethoden.
(vi) De toepassing gaat tussendoor kapot.
- Testscenario's helpen dus bij het evalueren van de softwaretoepassing volgens de praktijksituaties.
- Testscenario's helpen bij het opsplitsen van de reikwijdte van de tests.
- Deze opsplitsing wordt prioritering genoemd en helpt bij het bepalen van de belangrijke functies van de softwaretoepassing.
- Geprioriteerd testen van de functionaliteiten helpt in hoge mate bij de succesvolle implementatie van de softwareapplicatie.
- Door de testscenario's te prioriteren, kunnen de belangrijkste functionaliteiten gemakkelijk worden geïdentificeerd en op prioriteit worden getest. Dit zorgt ervoor dat het merendeel van de cruciale functionaliteiten goed werkt en dat defecten die ermee verband houden naar behoren worden opgevangen en verholpen.
- Testscenario's bepalen de business process flow van de software en zo is end-to-end testen van de applicatie mogelijk.
Verschil tussen testscenario en testcase
| Testscenario | Testgevallen |
|---|---|
| Testscenario is een concept. | Testgevallen zijn de oplossingen om dat concept te verifiëren. |
| Testscenario is een functionaliteit op hoog niveau. | Testgevallen zijn gedetailleerde procedures om de functionaliteit op hoog niveau te testen. |
| Testscenario's worden afgeleid van Requirements/ User Stories. | Testgevallen worden afgeleid van Testscenario's . |
| Testscenario is "Welke functionaliteit moet worden getest? | Test Cases zijn 'Hoe test je de functionaliteit'. |
| Testscenario's hebben meerdere testgevallen. | Het testgeval kan al dan niet aan meerdere testscenario's gekoppeld zijn. |
| Enkelvoudige testscenario's zijn nooit herhaalbaar. | Eén testgeval kan meerdere malen in verschillende scenario's worden gebruikt. |
| Korte documentaties vereist. | Gedetailleerde documentatie is vereist. |
| Brainstormsessies zijn nodig om een Testscenario af te ronden. | Gedetailleerde technische kennis van de softwaretoepassing is vereist |
| Tijdsbesparing omdat er geen details nodig zijn. | Tijdrovend omdat elk klein detail moet worden verzorgd. |
| De onderhoudskosten zijn laag omdat er weinig middelen nodig zijn. | De onderhoudskosten zijn hoog omdat er veel middelen nodig zijn |
Waarom zijn testscenario's onmisbaar?
Testscenario's worden afgeleid van requirements of user stories.
- Neem het voorbeeld van een testscenario voor het boeken van een taxi.
- De scenario's kunnen zijn: opties voor taxiboeking, betalingswijzen, GPS-tracering, wegenkaart al dan niet correct weergegeven, details van taxi's en chauffeurs al dan niet correct weergegeven, enz.
- Stel nu dat het testscenario is om te controleren of de locatiediensten zijn ingeschakeld, indien niet ingeschakeld, het bericht 'Schakel locatiediensten in' weer te geven. Dit scenario is gemist en niet opgenomen in het sjabloon voor testscenario's.
- Het scenario "Locatiedienst" geeft aanleiding tot andere daarmee samenhangende testscenario's.
Dit kunnen zijn:
- Locatiedienst grijs.
- De locatiedienst stond aan, maar geen internet.
- Beperkingen voor diensten op locatie.
- De verkeerde locatie wordt weergegeven.
- Een enkel scenario missen kan betekenen dat je veel andere cruciale scenario's of testgevallen Dit kan een grote negatief effect Dit resulteert in een groot verlies aan middelen (deadlines).
- Testscenario's helpen in hoge mate bij het vermijden van uitputtende tests Het zorgt ervoor dat alle cruciale en verwachte business flows worden getest, wat verder helpt bij het end-to-end testen van de applicatie.
- Dit bespaart tijd. Ook is een veel gedetailleerdere beschrijving volgens de testgevallen niet nodig. Er wordt een one-liner beschrijving gegeven van wat er getest moet worden.
- Testscenario's worden geschreven na brainstormsessies De kans dat een scenario (cruciaal of minder belangrijk) wordt gemist is dus minimaal. Hierbij wordt rekening gehouden met de technische aspecten en de business flow van de softwareapplicatie.
- Bovendien kunnen de testscenario's worden goedgekeurd door een Business Analyst Client of beiden die expliciete kennis hebben van de te testen applicatie.
Testscenario's zijn dus een onmisbaar onderdeel van SDLC.
Uitvoering van testscenario's
Laten we eens kijken naar de uitvoering van testscenario's of hoe je testscenario's schrijft:
- Epics/Business Requirements worden gevormd.
- Voorbeeld van Epic Maak een Gmail-account aan. Epic kan de belangrijkste functie van een applicatie of een bedrijfsvereiste zijn.
- Epics worden verdeeld in kleinere user stories over sprints.
- User stories worden afgeleid van Epics. Deze user stories moeten worden gebaseerd en goedgekeurd door stakeholders.
- Testscenario's worden afgeleid van user stories of BRS (Business Requirement Document), SRS (System Requirement Specification Document), of FRS (Functional Requirement Document) die worden afgerond en gebaseerd.
- Testers schrijven de testscenario's.
- Deze testscenario's worden goedgekeurd door Team Lead, Business Analyst of Project Manager, afhankelijk van de organisatie.
- Elk testscenario moet gekoppeld zijn aan ten minste één user story.
- Er moeten zowel positieve als negatieve testscenario's worden vastgesteld.
- Gebruikersverhalen bestaan uit Aanvaardingscriteria zoals :
- Acceptatiecriteria zijn een lijst van voorwaarden of de intentieverklaring voor de eisen van de klant. Bij het opstellen van de acceptatiecriteria wordt rekening gehouden met de verwachtingen van de klant en ook met misverstanden.
- Deze zijn uniek voor één user story en elke user story moet minstens één acceptatiecriterium hebben dat onafhankelijk testbaar moet zijn.
- Acceptatiecriteria helpen bij het bepalen welke features binnen en welke buiten de scope van een project vallen. Deze criteria moeten zowel functionele als niet-functionele features 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 Kindle App
Kindle is de app waarmee e-readers online e-books kunnen zoeken, downloaden en kopen. Amazon Kindle geeft de e-booklezer de levensechte ervaring van een boek in de hand houden en lezen. Zelfs het omslaan van pagina's wordt mooi gesimuleerd in de app.
Laten we nu de testscenario's noteren. ( Let op: Hieronder staan beperkte scenario's om een algemeen idee te krijgen voor het schrijven van het testscenario. Er kunnen meerdere testgevallen van worden afgeleid).
| Testscenario's # | Testscenario's |
|---|---|
| 1 | Controleer of Kindle App goed opstart. |
| 2 | Controleer of de schermresolutie wordt aangepast aan de verschillende apparaten, nadat de app is gestart. |
| 3 | Controleer of de weergegeven tekst leesbaar is. |
| 4 | Controleer of de in- en uitzoomopties werken. |
| 5 | Controleer of de in de Kindle-app geïmporteerde compatibele bestanden leesbaar zijn. |
| 6 | Controleer de opslagcapaciteit van Kindle App. |
| 7 | Controleer of de downloadfunctie correct werkt. |
| 8 | Controleer of de simulatie van Page Turn correct werkt |
| 9 | Controleer of de eBook formaten compatibel zijn met de Kindle app. |
| 10 | Controleer of lettertypen worden ondersteund door Kindle-app. |
| 11 | Controleer de batterijduur die Kindle-app gebruikt. |
| 12 | Controleer de prestaties van Kindle afhankelijk van de netwerkverbinding (Wi-Fi, 3G of 4G). |
Van elk van de bovengenoemde testscenario's kunnen meerdere testgevallen worden afgeleid.
#2) Acceptatiecriteria voor Google Docs
"Google docs" is een webapplicatie voor het maken, bewerken en delen van tekstdocumenten, spreadsheets, dia's en formulieren. Alle bestanden zijn online toegankelijk via een webbrowser met een internetverbinding.
De gecreëerde documenten kunnen worden gedeeld als webpagina of printklaar document. De gebruiker kan beperkingen instellen op wie de documenten kan bekijken en bewerken. Een enkel document kan gezamenlijk worden gedeeld en bewerkt door verschillende personen van verschillende geografische locaties.
Voor een algemeen begrip worden hieronder beperkte testscenario's genoemd. Diepgaande testscenario's voor Google-documenten kunnen een apart onderwerp zijn.
| Acceptatiecriteria # | Aanvaardingscriteria |
|---|---|
| 1 | Word, Sheets of Formulieren kunnen zonder fouten worden geopend. |
| 2 | Er zijn sjablonen beschikbaar voor documenten, sheets en dia's. |
| 3 | Beschikbare sjablonen zijn toegankelijk voor gebruikers. |
| 4 | De gebruikte sjabloon is bewerkbaar (bv. lettertypes, lettergrootte, tekst toevoegen, tekst verwijderen, dia invoegen). |
| 5 | Als de internetverbinding tijdelijk niet beschikbaar is, kan het bestand lokaal worden opgeslagen en geüpload als de internetverbinding beschikbaar is. |
| 6 | Wijzigingen door meerdere gebruikers worden niet overschreven. |
| 7 | Meerdere gebruikers kunnen aan één document werken. |
| 8 | Het gedane werk wordt opgeslagen als de internetverbinding tijdens het uploaden van een bestand wegvalt. |
| 9 | Deelbeperkingen worden correct toegepast. |
| 10 | Gebruikers met weergavebeperking kunnen de documenten niet bewerken. |
| 11 | Documenten kunnen worden gepubliceerd op internet voor het grote publiek. |
| 12 | Wijzigingen in documenten worden opgeslagen met tijdstempel en auteursgegevens. |
Het aantal testscenario's zal voor Google Docs veelvuldig en zeer groot zijn. In dergelijke gevallen worden meestal alleen de acceptatiecriteria vastgesteld en goedgekeurd door de belanghebbenden, en werken de teamleden aan deze acceptatiecriteria. Het schrijven van testgevallen voor of liever nog een testscenario's kan een uitputtende taak zijn voor enorme toepassingen.
Deze acceptatiecriteria spelen een belangrijke rol in de iteratieve procesplanning en mogen nooit over het hoofd worden gezien. Door ze vooraf en op voorhand 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.
Dan wordt het resultaat verwacht.
De formaten Gegeven, Wanneer en Dan zijn nuttig voor het specificeren van aanvaardingscriteria.
Voorbeeld van Testscenario Sjabloon
| Gebruik Verhaal ID # | Testscenario ID # | Versie # | Testscenario's | # Aantal testgevallen | Belang |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Controleer of Kindle App goed opstart. | 4 | Hoog |
| USID12.1 | TSID12.1.2 | Kin12.4 | Controleer de opslagcapaciteit van Kindle App. | 3 | Medium |
Conclusie
Bij het testen van software is het begrijpen van de levenscyclus en het vastleggen van testscenario's een zeer belangrijk element. De kwaliteit van de software kan worden verbeterd door een goede basis voor testscenario's. Vaak worden testgevallen en testscenario's door elkaar gebruikt.
De vuistregel is echter dat het testscenario wordt gebruikt om meerdere testgevallen te schrijven of we kunnen zeggen dat testgevallen zijn afgeleid van testscenario's. Goed gedefinieerde testscenario's zorgen voor software van goede kwaliteit.