Leestijd: 7 minuten

succes van een project hangt af van het vermogen van een ontwikkelingsteam om aan de behoeften van hun cliënt te voldoen. De communicatie tussen de klant en het ontwikkelingsteam speelt een cruciale rol bij het leveren van een oplossing die past bij product-en marktvereisten., De problemen ontstaan als klanten uit te leggen hun behoeften te vaag en het team kan niet begrijpen duidelijke eisen en uiteindelijk het zakelijke probleem achter hen. Stel je voor dat je je team vraagt om gebruikers in staat te stellen om te zoeken naar een product in een online boekhandel per categorie. U verwacht een duidelijke interface met categorie links om op te klikken (bijvoorbeeld Fantasie, non-fictie, historisch, enz.) Na twee weken van ontwikkeling, ontvangt u een zoekbalk functie waar gebruikers moeten typen in de categorie waarin ze geïnteresseerd zijn, in plaats van het bladeren vooraf vermelde categorieën., Hoewel dit ook werkt, je oorspronkelijke doel was om alle beschikbare categorieën bloot te stellen en gebruikers verder te laten verkennen.

Dit is wanneer hoogwaardige softwaredocumentatie het probleem kan helpen voorkomen. Gebruikersverhalen en acceptatiecriteria (AC) als de belangrijkste formaten voor het documenteren van vereisten. Een gebruikersverhaal is een natuurlijke taalbeschrijving van een functie. Het gaat meestal gepaard met acceptatiecriteria.

Acceptance criteria (AC) zijn de voorwaarden waaraan een softwareproduct moet voldoen om door een gebruiker, een klant of een ander systeem te worden geaccepteerd., Ze zijn uniek voor elk gebruikersverhaal en definiëren het gedrag van de functie vanuit het perspectief van de eindgebruiker. Goed geschreven acceptatiecriteria helpen onverwachte resultaten te voorkomen aan het einde van een ontwikkelingsfase en zorgen ervoor dat alle belanghebbenden en gebruikers tevreden zijn met wat ze krijgen.

acceptatiecriteria zijn de laagste functionele eisen

acceptatiecriteria hoofddoelen

verduidelijking van de eisen van de stakeholder is een doel 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:

1. Scenario – de naam voor het gedrag dat zal worden beschreven
2. gegeven – de begintoestand van het scenario
3. wanneer – specifieke actie die de gebruiker maakt
4. dan – de uitkomst van de actie in “wanneer”
5. 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.,deksel

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:

een eenvoudige set AC voor sterke wachtwoorden door Mark Levison voor agilepainpainrelief.com

Deze aanpak biedt duidelijke richtlijnen voor het testen van wachtwoordfuncties.

rollen verantwoordelijk en hoe acceptatiecriteria worden gemaakt

sommige criteria worden gedefinieerd en geschreven door de producteigenaar wanneer hij of zij de product achterstand aanmaakt. En de anderen kunnen verder worden gespecificeerd door het team tijdens gebruikersverhalen discussies na sprint planning., Er zijn geen strikte aanbevelingen voor het kiezen van de persoon die verantwoordelijk is voor het schrijven van de criteria. De klant kan ze documenteren als hij of zij beschikt over voldoende technische en productdocumentatie kennis. In dit geval onderhandelt de klant met het team over de criteria om Wederzijdse misverstanden te voorkomen. Anders worden de criteria gemaakt door een producteigenaar, business analist, requirements analist, of een projectmanager.,

het proces begint met het prioriteren van het verhaal van de gebruiker en eindigt met het onderhandelen over details met het hele team

belangrijkste uitdagingen en best practices van het schrijven van acceptatiecriteria

acceptatiecriteria lijken zeer eenvoudig te schrijven. Ondanks hun simplistische formaten, het schrijven vormt een uitdaging voor veel teams. Laten we eens een diepere blik op de best practices die helpen voorkomen dat veel voorkomende fouten.

Document criteria voor ontwikkeling. Acceptatiecriteria moeten worden gedocumenteerd voordat de daadwerkelijke ontwikkeling begint., Op deze manier zal het team waarschijnlijk van tevoren alle behoeften van de klant vastleggen. In het begin is het voldoende om de criteria voor een klein aantal gebruikersverhalen in te stellen om de achterstanden voor twee sprints op te vullen (als je Scrum of een soortgelijke methode beoefent). Zij moeten door beide partijen worden goedgekeurd. Vervolgens worden de gedocumenteerde acceptatiecriteria door ontwikkelaars gebruikt om het technische proces te plannen.

maak AC niet te smal. Acceptatiecriteria kunnen veel te specifiek leven weinig tot geen manoeuvre opties voor ontwikkelaars. Om dit te voorkomen, vergeet niet dat AC de bedoeling moet overbrengen, maar niet een definitieve oplossing., Bovendien, smalle AC kan worden beroofd van meerdere gebruikers gedrag dat niet worden gedekt.

Houd uw criteria haalbaar. Dit punt kruist nauw met het vorige punt. Effectieve acceptatiecriteria bepalen het redelijke minimum aan functionaliteit dat u kunt leveren. Maar in het geval je bezwijkt voor het beschrijven van alle kleine details, is er een risico dat uw team zal vast komen te zitten met honderden kleine taken.

houd AC meetbaar en niet te breed. Brede acceptatiecriteria maken een gebruikersverhaal vaag., Effectieve acceptatiecriteria moeten de reikwijdte van het werk schetsen, zodat de ontwikkelaars hun inspanning goed kunnen plannen en inschatten.

vermijd technische details. Zoals we al zeiden, moeten acceptatiecriteria in gewoon Engels worden geschreven. Dit maakt ze duidelijk en gemakkelijk te begrijpen voor iedereen: uw stakeholders of managers hebben mogelijk geen technische achtergrond.

bereiken consensus. Hetzelfde probleem kan anders worden opgelost door een team en stakeholders, afhankelijk van hun standpunten. Zorg ervoor dat u uw AC aan stakeholders hebt gecommuniceerd en tot een wederzijds akkoord bent gekomen., Hetzelfde geldt voor teamleden. Iedereen moet het AC controleren en bevestigen dat ze elke lijn begrijpen en ermee instemmen.

testbare AC schrijven. Hierdoor kunnen testers controleren of aan alle eisen is voldaan. Anders, ontwikkelaars zullen niet begrijpen als de gebruiker verhaal is voltooid.

laatste woord

negeer de acceptatiecriteria niet omdat ze – eenvoudig en aanspreekbaar – meerdere problemen tegelijk oplossen., Ze documenteren de verwachtingen van de klant, bieden een eindgebruiker perspectief, verduidelijken eisen en voorkomen dubbelzinnigheid, en uiteindelijk helpen kwaliteitsborging controleren of de ontwikkelingsdoelstellingen werden gehaald. Ongeacht of u Agile methoden gebruiken of niet, zorg ervoor dat u het beste formaat kiezen of experimenteren met uw eigen. Verschillende soorten gebruikersverhalen en uiteindelijk functies kunnen verschillende fromats vereisen en het testen van de nieuwe die voor u werken is een goede praktijk.