verduidelijking van de eisen van de stakeholder is een doelstelling op hoog niveau. Om de doelen van AC duidelijker te maken, laten we ze opsplitsen.
functie scope detalisatie. AC definieer de grenzen van gebruikersverhalen. Ze bieden nauwkeurige details over de functionaliteit die het team helpen begrijpen of het verhaal is voltooid en werkt zoals verwacht.
beschrijft negatieve scenario ‘ s. Yor AC kan het systeem vereisen om onveilige wachtwoordinvoer te herkennen en te voorkomen dat een gebruiker verder gaat., Ongeldig wachtwoordformaat is een voorbeeld van een zogenaamd negatief scenario wanneer een gebruiker ongeldige invoer doet of zich onverwacht gedraagt. AC definieer deze scenario ‘ s en leg uit hoe het systeem hierop moet reageren.
communicatie instellen. Acceptatiecriteria synchroniseren de visies van de klant en het ontwikkelingsteam. Ze zorgen ervoor dat iedereen een gemeenschappelijk begrip heeft van de vereisten: ontwikkelaars weten precies wat voor soort gedrag de functie moet laten zien, terwijl stakeholders en de klant begrijpen wat er van de functie wordt verwacht.
stroomlijning acceptatietest., AC zijn de basis van de gebruiker verhaal acceptatie testen. Elk acceptatiecriterium moet onafhankelijk testbaar zijn en dus een duidelijk ‘pass’ – of ‘fail’ – scenario hebben. Ze kunnen ook worden gebruikt om het verhaal te verifiëren via geautomatiseerde tests.
schatting van de functie. Acceptatiecriteria bepalen wat precies door het team moet worden ontwikkeld. Zodra het team nauwkeurige eisen heeft, kunnen ze gebruikersverhalen splitsen in taken die correct kunnen worden geschat.
acceptatiecriteria typen en structuren
AC kunnen in verschillende formaten worden geschreven., Er zijn twee meest voorkomende formaten, en de derde optie is om uw eigen formaat te ontwikkelen:
- scenario-georiënteerd (gegeven/wanneer/toen)
- regel-georiënteerd (checklist)
- aangepaste formaten
aangezien de eerste en de tweede formaten zeer specifieke structuren hebben, zullen we ons voornamelijk op hen richten. Echter, u kunt vinden dat andere formaten passen bij uw product beter, dus we zullen kort op hen ook.
Scenariogeoriënteerde acceptatiecriteria
Scenariogeoriënteerde opmaak van het schrijven van AC staat bekend als het gegeven/wanneer / toen (GWT) type.,
- gegeven een preconditie
- wanneer ik een actie
- doe dan verwacht ik een resultaat
Deze aanpak is overgenomen van behavior-driven development (BDD) en biedt een consistente structuur die testers helpt te bepalen wanneer een bepaalde functie moet beginnen en eindigen. Het vermindert ook de tijd besteed aan het schrijven van testcases als het gedrag van het systeem vooraf wordt beschreven.,
elke acceptatiecriteria geschreven in dit formaat heeft de volgende verklaringen:
- Scenario — de naam voor het gedrag dat zal worden beschreven
- gegeven — de begintoestand van het scenario
- wanneer — specifieke actie die de gebruiker maakt
- dan — de uitkomst van de actie in “wanneer”
- en — gebruikt om een van de drie eerdere verklaringen
voort te zetten wanneer gecombineerd deze verklaringen alle acties die een gebruiker neemt om een taak te voltooien en ervaar de uitkomst.
laten we eens kijken naar enkele voorbeelden.,
Voorbeeld 1
gebruikersverhaal: als gebruiker wil ik het wachtwoord van mijn account kunnen herstellen, zodat ik toegang kan krijgen tot mijn account als ik het wachtwoord ben vergeten.,gekoppeld aan de login pagina
wanneer: de gebruiker geselecteerd wachtwoord vergeten optie
en: een geldige e-mail ingevoerd om een link te ontvangen voor wachtwoordherstel
dan: het systeem stuurde de link naar de ingevoerde e-mail
gegeven: de gebruiker ontving de link via de e-mail
wanneer: de gebruiker genavigeerd door de link ontvangen in de e-mail
dan: het systeem stelt de gebruiker in staat om een nieuw wachtwoord in te stellen
Voorbeeld 2
user story: als gebruiker wil ik het geld van mijn account in ATM kunnen opvragen, zodat ik het geld snel en op verschillende plaatsen van mijn account kan ontvangen.,alid
En: de dispenser bevat cash
Wanneer: de klant het geld
Vervolgens: zorg ervoor dat de rekening wordt gedebiteerd
En: zorg voor contant geld wordt afgeschaft
En: zorg ervoor dat de kaart wordt geretourneerd
acceptatiecriteria 2:
Gegeven: dat de rekening een negatief saldo
En: de kaart is geldig
Wanneer: de klant het geld
Vervolgens: zorg ervoor dat de afwijzing bericht wordt weergegeven
En: zorg ervoor dat geld is niet afgegeven
Regel-georiënteerde acceptatie criteria voor indeling
In sommige gevallen, het is moeilijk aan te passen criteria voor acceptatie in de Gegeven/Als/Dan structuur., Bijvoorbeeld, GWT zou nauwelijks nuttig zijn voor de volgende gevallen:
- u werkt met gebruikersverhalen die de functionaliteit op systeemniveau beschrijven die andere methoden van kwaliteitsborging nodig heeft.
- de doelgroep voor acceptatiecriteria heeft geen nauwkeurige details van de testscenario ‘ s nodig.
- GWT-scenario ‘ s passen niet bij het beschrijven van ontwerp-en gebruikerservaringsbeperkingen van een functie. Ontwikkelaars kunnen een aantal kritische details missen.
u kunt deze gevallen aanpakken met het REGELGEORIËNTEERDE AC-formaat.,
De regelgeoriënteerde vorm houdt in dat er een set regels is die het gedrag van een systeem beschrijven. Op basis van deze regels kunt u specifieke scenario ‘ s tekenen.
gewoonlijk zien criteria samengesteld met behulp van dit formulier eruit als een eenvoudige opsomminglijst. Laten we een voorbeeld bekijken.
voorbeeld
gebruikersverhaal: als gebruiker wil ik een zoekveld gebruiken om een stad, naam of straat in te typen, zodat ik overeenkomende hotelopties kan vinden.,
basis zoekinterface acceptatiecriteria
- het zoekveld wordt op de bovenste balk geplaatst
- zoeken begint zodra de gebruiker op “Zoeken”
- klikt het veld bevat een plaatshouder met een grijskleurige tekst: “Where are you going?”
- de plaatshouder verdwijnt zodra de gebruiker begint te typen
- zoeken wordt uitgevoerd als een gebruiker typt in een stad, hotelnaam, straat of alle gecombineerde
- zoeken is in het Engels, Frans, Duits en Oekraïens
- de gebruiker kan niet meer dan 200 symbolen
- typen de zoekopdracht ondersteunt geen speciale symbolen (tekens)., Als de gebruiker een speciaal symbool heeft getypt, toont u de waarschuwing: “Zoekinvoer kan geen speciale symbolen bevatten.”
andere formaten
De meeste gebruikersverhalen kunnen worden behandeld met twee bovengenoemde formaten. U kunt echter uw eigen acceptatiecriteria uitvinden, aangezien ze hun doel dienen, duidelijk in gewoon Engels zijn geschreven en niet verkeerd kunnen worden geïnterpreteerd. Sommige teams gebruiken zelfs platte tekst.
soms kunnen uw criteria worden opgegeven als voorbeeld van systeemgedrag: