acceptance testing documentation with real time scenarios
Documentatie van acceptatietests (deel II):
Vorige tutorial VOLGENDE zelfstudie
Deze tutorial is de voortzetting van onze vorige tutorial waarin we hebben besproken wat acceptatietesten zijn, wanneer het moet worden gedaan, wie het doet, het belang, de soorten, het proces, de impact op verschillende teams, enz.
pl sql interviewvragen en antwoorden voor ervaren pdf
Documenten spelen een zeer belangrijke rol bij acceptatietesten en eventuele problemen met betrekking tot het document hebben een enorme negatieve impact. Als er geen goede controle wordt uitgeoefend, kan dit zelfs leiden tot het falen van het product.
Klik hier voor een complete serie testplannen
In deze tutorial zullen we meer leren over de verschillende documentatie die betrokken is bij acceptatietesten, dwz acceptatietestplan, testplanbeoordelingschecklist, acceptatietestsjabloon, voorbeelden op basis van realtime scenario's, hoe acceptatietests kunnen worden geïdentificeerd en geschreven, enz. .
Wat je leert:
- Acceptatietestplan
- Acceptatietestplan sjabloon
- Herziening van het acceptatietestplan
- Acceptatietests
- Acceptatietests beoordelen
- Gevolgtrekking
- Aanbevolen literatuur
Acceptatietestplan
Net als elk ander testplan omvat het acceptatietestplan ook enkele componenten zoals toepassingsgebied, aanpak, testomgeving, bronnen, verantwoordelijkheden, referenties van acceptatietests, toegangscriteria, exitcriteria, tools, enz.
Het enige dat een acceptatietestplan onderscheidt van een regulier testplan, zijn de factoren die resulteren in een zakelijke beslissing. Acceptatietestplan is een van de essentiële documentatie die richtlijnen biedt voor het uitvoeren van acceptatietests voor een bepaald project.
Het acceptatietestplan moet worden herzien en goedgekeurd voordat de acceptatietest wordt uitgevoerd. Alle daaropvolgende wijzigingen moeten opnieuw een evaluatie- en goedkeuringsproces ondergaan en moeten in de track zijn.
Beoordeling van acceptatietestplannen wordt meestal gedaan door managers / bedrijfsanalisten / klanten.
Belangrijkste punten waarmee rekening moet worden gehouden bij het ontwerpen van een acceptatietestplan:
- Het zou moeten zijn Gedetailleerd en specifiek. Moet alleen bevatten wat nodig is voor testen en welke informatie nodig is voor het team om testen uit te voeren.
- Het zou moeten zijn Duidelijk en beknopt Geen dubbelzinnigheid. Als er iets is dat tot verwarring kan leiden, werk het dan uit, maar houd het kort en effectief.
- Elk onderdeel in het document moet worden geschreven door alleen de Business Requirements in gedachten te houden.
- Betrouwbaar en aanpasbaar - Het zou moeten kunnen worden bijgewerkt zoals vereist in de toekomstige releases.
- Consequent - Het zou in de toekomst niet meer moeten veranderen.
- Volg het sjabloon dat door de organisatie of klant is verstrekt.
Acceptatietestplan sjabloon
Hier zullen we een algemene sjabloon voor een acceptatietestplan bekijken dat verder kan worden aangepast volgens de projectvereisten.
Titel
Objectief
Revisiegeschiedenis / wijzigingslogboek
< Dit moet in tabelvorm zijn met de onderstaande informatie:
- Datum - De datum waarop het document is gewijzigd.
- Aangepast door - Wie heeft de inhoud van het document gewijzigd.
- Doel - Waarom is het document gewijzigd?
- Versie - Huidige versie van het document na aanpassingen (gaat als 1.0, 1.1, 1.2, 1.3,… voor een bepaalde uitgave. Volgende uitgave start vanaf 2, 2.1, 2.2, 2.3,…, de lijst gaat maar door).
- Goedgekeurd door - Wie heeft de aangebrachte wijzigingen goedgekeurd (betekent impliciet dat het document is beoordeeld en goedgekeurd).
De allereerste rij in deze tabel zouden de details van het document moeten zijn. Daarna volgt de details van de aangebrachte wijzigingen.>
Inhoudsopgave
Referenties
Reikwijdte
Invoering
Testobjecten
Functies die moeten worden getest
Functies die niet moeten worden getest
Nadering
Details testomgeving
Toelatingscriteria
Tests - Als er geen aparte Acceptatietests zijn geschreven
Elke test moet het volgende bevatten:
- Test #.
- Een beschrijving van wat er wordt getest ( Voorbeeld : Controleer of een gebruiker met succes een account kan aanmaken).
- Bedrijfsbehoefte waaraan deze test is gekoppeld ( Traceerbaarheid Matrix ) - Erg belangrijk.
- Randvoorwaarden:
- Staat van het product voordat de test wordt gestart (de gebruiker moet met succes zijn geregistreerd maar het account niet hebben geactiveerd, de gebruiker moet minimaal 30 dagen geleden toegang hebben gehad tot het product, enz.)
- Eventuele servervoorwaarden - Mocht de server enige tijd niet werken.
- Teststappen: Gedetailleerde genummerde stroom ( Voorbeeld: zie hieronder
- Open de applicatie.
- Probeer in te loggen met geldige inloggegevens met het selectievakje Onthoud mij aangevinkt).
- verwacht resultaat : Wat is het verwachte gedrag van de stap>
Acceptatietests - Als er afzonderlijke acceptatietests zijn geschreven
Criteria afsluiten
Middelen
Rollen en verantwoordelijkheden
Gereedschap
Zakelijke beslissingsfactoren
Afmeldingsprocedure
Contactpunt
Acceptatietestplan wordt beschouwd als het Master testplan voor de fase
Herziening van het acceptatietestplan
Zodra het plan klaar is, moet het worden herzien op volledigheid, niet-ambiguïteit, duidelijkheid, kwaliteit, enz. Ongetwijfeld moet de volledige inhoud van het Acceptatietestplan grondig worden herzien voor de juiste informatie, maar het moet worden beoordeeld tegen enkele andere punten, laten we zeggen checklist-punten.
Laten we hier de inhoud categoriseren en de checklist-punten tegen hen bekijken.
| Categorie | Checklist punten |
|---|---|
| Acceptatietests | Zijn de tests genummerd Zijn de randvoorwaarden genummerd Zijn de teststappen duidelijk om te begrijpen? Zijn de teststappen voltooid? Is het verwachte resultaat compleet Is er een open vraag in de tests (indien aanwezig, follow-up en voltooi deze) Is de verwijzing naar Acceptatietests (indien apart geschreven) geldig en bestaand Is de traceerbaarheid correct Is er een zakelijke vereiste gemist om de test te dekken? |
| Titel | Komt de titel overeen met de projecttitel zoals overal wordt verwezen Is de titel volgens de naamgevingsconventies van Project? |
| Revisiegeschiedenis, inhoudsopgave | Wordt elke versiewijziging correct bijgehouden voor het plan Heeft elke versiewijziging de juiste beoordeling ondergaan en wordt vermeld Is de versieconventie correct Komt de inhoudsopgave overeen met de daadwerkelijke inhoud van het plan? Is het paginanummer voor elke inhoud correct? Wordt het paginanummer bijgewerkt als de wijzigingen in het plan het paginanummer van de inhoud hebben gewijzigd |
| Referenties | Zijn de referenties bestaand en geldig Komen ze overeen met de reikwijdte Zijn ze compleet en komen ze in aanmerking voor identificatie van tests? |
| Testitems, functies die moeten worden getest, functies die niet moeten worden getest | Zijn ze genummerd Valt elke functie / module / submodule onder de scope? Kan het geplande schema alle geïdentificeerde testitems omvatten |
| Ingangscriteria, uitgangscriteria | Zijn ze genummerd Wordt elk criterium in detail genoemd |
| Details testomgeving | Heeft het alle vereiste configuraties genoemd Is de versie voor elke configuratie specifiek of de laatste waarmee rekening moet worden gehouden? Bestaan de VM's, de omgeving bestaat (zo niet, vermeld de mogelijke datum voor de beschikbaarheid) Wordt de methode voor het delen van inloggegevens voor een bepaalde omgevingstoegang genoemd |
| Middelen, rollen en verantwoordelijkheden | Zijn de verantwoordelijkheden voor elke rol genummerd Kunnen de verantwoordelijkheden worden bereikt Is de geïdentificeerde hulpbron in staat om met genoemde verantwoordelijkheden om te gaan? |
| Gereedschap | Zijn alle tools genoemd Zijn alle gereedschappen genummerd Zijn alle tools versienummer Heeft een van de tools een licentie nodig of de bestaande licentie die geldig is tijdens de fase Is de begeleiding bij het gebruik van het gereedschap correct en voldoende? |
| Zakelijke beslissingsfactoren | Heeft alle genoemde factoren Zijn alle factoren genummerd |
| Afmeldingsprocedure | Is de procedure geldig Is de procedure acceptabel? Is de procedure duidelijk te begrijpen |
| Contactpunt | Is de resource geïdentificeerd als aanspreekpunt beschikbaar in de organisatie tijdens de fase Is de geïdentificeerde bron in staat de fase aan te pakken? |
Elk testplan dat aan het bovenstaande checklistdocument voldoet, zal ook dienen als een sterk document voor interne audits.
Acceptatietests
Acceptatietests waren voorheen bekend als Functionele tests. Om de naam beter geschikt te maken voor de Acceptatietestfase en het doel te dienen, is deze hernoemd naar Acceptatietests. Soms wordt het ook wel aangeduid als Klantentests.
Acceptatietesten zijn altijd afgeleid van user stories, acceptatiecriteria en use cases. Dit zijn black-box-systeemtests en vertegenwoordigen alleen die bedrijfstests die moeten worden geverifieerd. Deze moeten voornamelijk bedoeld zijn voor productgedrag, gebruik en stromen.
De ontworpen acceptatietests kunnen ook in aanmerking worden genomen voor de systeemtestfase in de regressiecycli om vertrouwen te krijgen in het product voordat het wordt overgedragen aan de acceptatietestfase.
Belangrijkste punten die u moet onthouden voordat u acceptatietests schrijft:
- Bewaar alle referentiedocumenten op hun plaats: Specificatie van softwarevereisten, document met zakelijke vereisten, gebruiksscenario's, gebruikersverhalen, datamatrix (in geval van logica) enz.
- Focus alleen op zakelijke vereisten (testbare zakelijke vereisten).
- Verwijder op zijn vroegst alle twijfels, vragen over de zakelijke vereisten.
- Zorg ervoor dat er in ieder geval geen wijzigingen zijn in de vereisten voor de huidige release.
Algemene en eenvoudige sjabloon om acceptatietests te schrijven:
Deze sjabloon kan opnieuw worden aangepast volgens de projectbehoeften en met meer informatie om op te nemen.
Laten we nu enkele veelvoorkomende scenario's bekijken en kijken hoe acceptatietestscenario's erop kunnen worden geschreven.
Geval 1: afhandeling van gebruikersaccounts
Dit is het scenario waarin de gebruikers hun account kunnen maken, bekijken, bijwerken en deactiveren. Over het algemeen is het een CRUD-bewerking (maken, lezen, bijwerken en verwijderen). We krijgen dus direct 4 grote scenario's om te testen.
Daarnaast hebben we bij het real-time afhandelen van gebruikersaccounts veel gebieden als het gaat om bekijken en bijwerken.
Doorgaan met het schrijven van acceptatietests:
Test 1: Registratie / Aanmelden / Account aanmaken, controleer of een gebruiker in staat is om:
- Maak het account aan.
- Activeer het account.
- Activeer het account slechts één keer (hier moet de activeringslink worden getest voor 2ndHoewel dit een negatieve test is, is het een van de belangrijkste verificatiepunten waarmee rekening moet worden gehouden).
Test 2: Om accountinformatie te openen en te bekijken, controleert u of een gebruiker in staat is om:
- Log in op het account.
- Bekijk verschillende secties in het profiel (als de sectie Profiel gecategoriseerd is, dan zou elke categorie zichtbaar moeten zijn).
- Controleer of de gegevens die in het profiel worden weergegeven, correct zijn volgens de invoer van de gebruiker.
Test 3: Om accountinformatie bij te werken, controleert u of een gebruiker in staat is om:
- Accountgegevens bijwerken (profiel):
- Werk elke categorie van het profiel bij.
- Controleer of de update-informatie correct wordt weergegeven in het profiel.
- Controleer of de gebruiker de informatie in het profiel niet kan bijwerken (in sommige toepassingen mogen voornaam, achternaam, gebruikersnaam, enz. Niet worden bijgewerkt. Hoewel dit een negatieve test is, is het een van de belangrijkste verificatiepunten te worden overwogen).
- Annuleer de updatestroom (hoewel dit een negatieve test is, is het ook een van de belangrijkste verificatiepunten waarmee rekening moet worden gehouden).
Test 4: Als de-activering van het account is toegestaan, controleer dan of een gebruiker in staat is om:
- Schakel het account uit.
- Annuleer de activeringsstroom (hoewel dit een negatieve test is, is het een van de belangrijkste verificatiepunten waarmee rekening moet worden gehouden).
- Toegang tot account na het annuleren van de activering.
Test 5: Als verificatie vereist is voor een e-mailadres of telefoonnummers, controleer dan of een gebruiker in staat is om:
hoe u .swf-bestanden op Windows opent
- Werk het e-mailadres bij naar het andere geldige adres.
- Verifieer ”bijgewerkt e-mailadres.
- Controleer of het geüpdatete en 'geverifieerde' e-mailadres verder wordt beschouwd - Stuur enkele e-mails van de applicatie en controleer of het aankomt op het bijgewerkte e-mailadres. De oude zou geen e-mails moeten ontvangen.
- Voeg het nieuwe telefoonnummer toe.
- Verifieer het toegevoegde telefoonnummer via Bellen.
- Verifieer het toegevoegde telefoonnummer via sms.
- Controleer of het toegevoegde en ‘geverifieerde’ telefoonnummer wordt weergegeven in het account.
- Werk het telefoonnummer bij.
- Verifieer het bijgewerkte telefoonnummer via Bellen.
- Verifieer ”bijgewerkt telefoonnummer via sms.
- Controleer of het geüpdatete en 'geverifieerde' telefoonnummer in het account voorkomt.
Geval 2: Aankoopproduct
De aankoop van het product verloopt meestal via de algemene stroom.
Enkele algemene scenario's waar eindgebruikers naar kijken, worden hier vermeld:
Voorwaarde: De gebruiker moet zijn aangemeld bij de applicatie.
Test 1: Productdetails, controleer of een gebruiker in staat is om:
- Bekijk de pagina met productdetails.
- Bekijk alle subsecties op de pagina met productdetails (beschrijving, kenmerk, merkinformatie, enz.).
- Selecteer de hoeveelheid van het product, kleur, maat, etc. zoals beschikbaar op de pagina met productdetails.
- Navigeer naar de categorie- en subcategoriepagina's vanaf de pagina Productdetails (indien beschikbaar op de pagina Productdetails).
- Navigeer naar de detailpagina van het andere product (indien aanwezig relevant productgedeelte).
- Bekijk opmerkingen en beoordelingen over het product.
- Sorteer opmerkingen over het product op basis van beoordelingen.
- Bekijk de algemene beoordeling van het product.
- Voeg commentaar toe op het product.
- Werk zijn / haar opmerking over het product bij.
- Verwijder zijn / haar opmerking over het product (indien aanwezig).
Test 2: toevoegen aan winkelwagen, controleer of een gebruiker:
- Kan het product aan winkelwagen toevoegen:
- Via de pagina met productdetails.
- Via de productlijstpagina.
- In staat om de benodigde hoeveelheid aan de winkelwagen toe te voegen (1 tot max limiet ingesteld).
- Kan het product niet aan de winkelwagen toevoegen als het niet op voorraad is.
Test 3: Controleer op de winkelwagenpagina of een gebruiker in staat is om:
- Bekijk het product in de winkelwagen met prijsinformatie voor extra hoeveelheid.
- Update hoeveelheid (1 tot max limiet ingesteld).
- Verwijder het product uit de winkelwagen.
- Navigeer terug naar winkelen.
- Ga verder naar afrekenen.
- Bekijk lege winkelwagen wanneer er geen product is toegevoegd,
Test 4: Controleer op de pagina met accountgegevens of een gebruiker in staat is om:
- Ga verder met de bestaande verzendgegevens.
- Update verzendadres.
- Voeg een nieuw afleveradres toe.
- Ga verder met het bestaande telefoonnummer.
- Update telefoonnummer voor de bestelling.
- Voeg een nieuw telefoonnummer toe voor de bestelling.
- Navigeer terug naar de winkelwagenpagina.
- Navigeer naar de betalingspagina.
Test 5: Controleer op de pagina Betalingen of een gebruiker in staat is om:
- Controleer de juistheid van het te factureren bedrag.
- Verwerk de bestelling met alle beschikbare opties (één optie voor elke afzonderlijke bestelling).
- Verwerk de transactie met succes. Ga naar de Orderbevestigingspagina.
- Transactiefout (hoewel dit een negatieve test is, moet het als een belangrijk scenario worden beschouwd).
- Coupons toepassen:
- Geldige coupons - Succes. Controleer hier de wijziging in het te factureren bedrag.
- Ongeldige coupons - Mislukt
- Verlopen kortingsbonnen - Mislukt.
- Navigeer terug naar de pagina Accountdetails.
Acceptatietests beoordelen
Het beoordelen van acceptatietests is een belangrijke taak, aangezien deze correct en to-the-point moet zijn met betrekking tot de zakelijke vereisten. Aangezien deze door klanten zelf en / of eindgebruikers kunnen worden uitgevoerd, is het zeer noodzakelijk om volledig, niet-dubbelzinnig, correct en gedetailleerd genoeg te zijn zodat iedereen deze kan begrijpen en uitvoeren.
Herziening Acceptatietests moeten worden gedaan door Business Analisten, klanten en eventuele opmerkingen over beoordelingen moeten hoge prioriteit krijgen.
Op het individuele testniveau moet de beoordeling worden uitgevoerd op basis van het onderstaande:
- Of de test de zakelijke vereisten dekt of niet.
- Zijn de randvoorwaarden duidelijk?
- Zijn de teststappen gemakkelijk te begrijpen en gedetailleerd?
- Is het verwachte resultaat correct en duidelijk?
- Is het gekoppeld aan de zakelijke vereisten voor traceerbaarheid?
- Is de test compleet genoeg om de specifieke stroom of het specifieke gebruik te dekken?
- Is de specifieke test vereist als onderdeel van acceptatietests.
- Is er een verificatiepunt dat niet nodig is voor acceptatietesten?
- Is het puur functioneel of valt een GUI er onder (het zou alleen functioneel moeten zijn).
- Zijn de speciale invoergegevens nodig? Zo ja, is het voorzien van bijzonderheden?
Over het algemeen moet de volledige beoordeling van de acceptatietestsuite betrekking hebben op:
- Bi-directionele traceerbaarheid: Zakelijke vereisten voor tests EN tests voor zakelijke vereisten.
- Is aan elke zakelijke behoefte voldaan?
- Wordt elke zakelijke vereiste gedekt door een of meer tests?
- Zijn de bedrijfsregels gedekt?
- Wordt het speciale gegevensgeval afgehandeld?
- Hoeveel tests zijn er geschreven om elke vereiste of regel te dekken?
- Kunnen de tests worden gegroepeerd en geclassificeerd voor stromen.
- Zijn de tests correct gerangschikt, zodat de uitvoering efficiënt is?
Gevolgtrekking
Kort samengevat, zoals eerder vermeld, spelen documenten een zeer ingrijpende rol bij Acceptatietesten.
Daarom moet elke schriftelijke acceptatietest goed gestructureerd zijn en meegaan met het gebruik ervan, zodat de acceptatietesters geïnteresseerd blijven in wat ze testen en hoe ze het doen. Dit zou op zijn beurt automatisch succes opleveren.
Bezoek hier voor een complete serie testplannen
Vorige tutorial VOLGENDE zelfstudie
Blijf op de hoogte en bekijk de komende tutorial over acceptatietesten om meer te weten te komen over acceptatietestrapporten en enkele algemene sjablonen. Laat het ons ook weten als u nog vragen heeft.
Aanbevolen literatuur
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Positieve tests: betekenis en verdiensten verklaard met echte testscenario's
- Primer eBook downloaden testen
- TimeShiftX vrijgegeven om Time Shift-testen te vereenvoudigen
- Wat is acceptatietesten (een complete gids)
- Voorbeeldsjabloon voor acceptatietestrapport met voorbeelden
- Bent u een expert op het gebied van handmatige of automatiseringstests? Werk parttime voor ons!
- Laadtests met HP LoadRunner-zelfstudies