Wat zijn gebruikersverhaal en acceptatiecriteria (voorbeelden)

Voorbeeld:

Als WhatsApp-gebruiker wil ik een camerapictogram in het chatschrijfvak om foto's te maken en te verzenden, zodat ik kan klikken en mijn foto's tegelijkertijd kan delen met al mijn vrienden.

Wat is een acceptatiecriterium?

Een acceptatiecriterium is een reeks geaccepteerde voorwaarden of bedrijfsregels waaraan de functionaliteit of feature moet voldoen en voldoen om geaccepteerd te worden door de Product Owner / Stakeholders.

Dit is een zeer belangrijk onderdeel van het afronden van gebruikersverhalen en het moet zeer nauwgezet worden bestudeerd door de Product Owner en Business Analist, omdat het missen van één criterium veel kan kosten. Dit is een eenvoudige genummerde lijst of een lijst met opsommingstekens.

Het formaat is als volgt:

​ Gegeven een voorwaarde als ik iets doe, verwacht ik het resultaat ​

beste software voor het herstellen van verwijderde bestanden

Voorbeeld (t.o.v. bovenstaand gebruikersverhaal):

• Laten we eens bedenken dat ik aan het chatten ben met een vriend en dat ik een foto zou moeten kunnen maken.
• Als ik op een afbeelding klik, zou ik een bijschrift aan de afbeelding moeten kunnen toevoegen voordat ik deze verstuur.
• Als er een probleem is met het starten van de camera van mijn telefoon, verschijnt er een foutmelding als ‘Camera kan niet worden gestart’. enz., moeten dienovereenkomstig worden weergegeven.

Daarom definieert het gebruikersverhaal de vereiste voor elke functionaliteit of functie, terwijl de acceptatiecriteria de ‘Definition of done’ voor het gebruikersverhaal of de vereiste definieert.

Als QA is het erg belangrijk om het gebruikersverhaal en de acceptatiecriteria ervan grondig te begrijpen, zonder dat er ook maar één twijfel overblijft bij het ‘begin van het testen’. Laten we voor de toekomst begrijpen waarom het buitengewoon belangrijk is om ‘diep’ te graven in gebruikersverhalen en acceptatiecriteria.

Diep graven in gebruikersverhalen

Laten we om te beginnen eerst het belang begrijpen van een ‘diepgaande’ studie van een fundamenteel en fundamenteel ding, d.w.z. Gebruikersverhalen.

De volgende gevallen zijn mijn eigen echte ervaringen.

Zaak 1:

Vóór 3 jaar werkte ik aan een mobiel applicatieproject en het product was een applicatie die was ontworpen voor bezorgers.

U zou een bezorger naar uw plaats hebben zien komen om te bezorgen. En ze hebben een gsm waarop ze je na levering vragen om je handtekening te zetten. Deze handtekening komt terug op het portaal van de koeriersdienstverleners zoals DTDC, FedEx etc.

Laten we ons voorstellen dat de mobiele app net is gelanceerd en dat hun portals al bestaan ​​en in gebruik zijn.

Probleem​ Voor een Sprint heeft uw Product owner een gebruikersverhaal voor deze mobiele app 'Als portaalbeheerder zou ik de handtekening moeten kunnen zien die door de bezorger is genomen op het moment van bezorging' ​Hier wordt de portal (webapp) gewijzigd en dienovereenkomstig bijgewerkt om de handtekening weer te geven.

Als QA moet u controleren of de handtekening die in de mobiele app is vastgelegd, overeenkomt met zoals verwacht in de portal.

Als je naar dit gebruikersverhaal kijkt, ziet het er eenvoudig uit, maar er is hier een verborgen vereiste: 'Voor historische leveringen was er geen functionaliteit voor het reflecteren van handtekeningen, dus wat moet er gebeuren als de portaalmannen historische leveringen bekijken?' Moeten historische gegevens worden weggevaagd? Moeten we crashes of fouten voor dergelijke gegevens toestaan?

Helemaal niet, dit moet gracieus worden behandeld.

Oplossing: Wanneer de respectieve databasetabellen worden bijgewerkt om een ​​nieuwe kolom voor de handtekeninglocatie toe te voegen, moeten de oude gegevens een NULL- of 0-waarde hebben die moet worden gecontroleerd en moet een bericht met de melding ‘Er bestaat geen handtekening’ worden weergegeven.

Dit is een misser van de Product Owner of Business Analist te noemen, maar dit moet wel. Het succesvol implementeren van een functie, maar er iets mee breken, is niet wenselijk door de klanten. Dit moet samen met hetzelfde gebruikersverhaal en in dezelfde sprint gebeuren.

Geval # 2

6 jaar geleden werkte ik aan een Retirement Planning Finance-applicatie (zonder BA), een wereldwijde applicatie waar Finance-mensen zoals CA en Finance-adviseurs het voor verschillende valuta's konden gebruiken om de investeringsplannen, besparingen, enz. grote periode aan hun klanten.

Probleem​ De Product Owner geeft je dat een User Story “Als adviseur wil ik het rapport van mijn klant inzien op basis van de verstrekte financiële gegevens”.

Hier waren er 2 verborgen vereisten en ik zou het een onvolledig verhaal noemen omdat:

naar) De rapporten moeten rekening houden met de dagelijkse wisselkoers van de valuta en niet met de historische koers zoals in het laatst bekeken rapport en

b) Als de valuta wordt gewijzigd nadat de financiële gegevens van de klant zijn verstrekt, moeten de rapporten in de gewijzigde valuta worden weergegeven.

Oplossing​ Ik heb deze bezorgdheid rechtstreeks bij onze Product Owner gemeld en hem ervan bewust gemaakt dat beide zaken zo snel mogelijk moesten worden gedaan. Hij was het met mij eens en creëerde 2 verschillende verhalen voor de komende sprints met prioriteit.

Afhalen​ Deze werden opgemerkt omdat we allemaal heel goed op de hoogte waren van de producten, hun ontwerp, structuur enz. Dergelijke kennis kan alleen worden verkregen door het product volledig te begrijpen, door de interoperabiliteit van modules te begrijpen en door het gebruikersverhaal grondig te bestuderen, zelfs als het een 2 voering.

Maak aantekeningen om dingen gemakkelijker te maken en bespreek hun ideeën met de BA's en de ontwikkelaars.

Een diepgaande blik op acceptatiecriteria

Het volledig begrijpen van de acceptatiecriteria en alle andere voorwaarden en regels is zelfs belangrijker dan een gebruikersverhaal te onderschatten. Want als een vereiste onvolledig of vaag is, kan deze in de volgende sprint worden opgepakt, maar als een acceptatiecriterium wordt gemist, kan het gebruikersverhaal zelf niet worden vrijgegeven.

Ik denk dat we allemaal wel eens gebruik zouden hebben gemaakt van internetbankieren en de meesten van ons gebruiken het elke dag en ik download mijn historische verklaringen veel. Als je het goed observeert, zijn er bepaalde specifieke opties beschikbaar om ze te downloaden.

Er is een optie om het type bestand te selecteren voor het downloaden van uw afschrift. Er is een optie om te kiezen of u alleen de Credits / Debit / beide wilt downloaden.

Stel je nu voor dat de Product Owner je dit gebruikersverhaal geeft: 'Als klant wil ik mijn rekeningoverzicht downloaden zodat ik al mijn transacties kan zien die voor een bepaalde periode zijn gedaan'.

Met de volgende acceptatiecriteria:

• Aangezien ik op de pagina Historische verklaring downloaden ben, moet ik de periode selecteren waarvoor ik de verklaring wil downloaden.
• Aangezien ik op de pagina Historische overzichten downloaden, moet ik het account selecteren waarvoor ik het overzicht wil downloaden.
• Aangezien ik op de pagina Historische verklaringen downloaden sta, zou ik de verklaring niet mogen downloaden voor toekomstige ‘Tot’ datum.
• Gezien het feit dat ik op de pagina Historische verklaringen downloaden sta, zou ik de ‘Van’ -datum 10 jaar later in het verleden niet mogen selecteren.
• Aangezien ik mijn afschrift download, zou ik het gedownloade bestand moeten kunnen bekijken.
• Aangezien ik op de pagina Historische verklaringen downloaden sta, zou ik mijn verklaring in doc-, Excel- en pdf-formaten moeten kunnen downloaden.

Als je deze acceptatie doorloopt, ontbreken hier 3 dingen:

• Naam en indeling van de bestandsnaam die zal worden gedownload.
• Welke informatie (kolomnamen) moet in het bestand worden weergegeven.
• De lijst met opties om te selecteren wat voor soort transactie de klant wil, d.w.z. alleen afschrijving of alleen afschrijving of beide.

Dergelijke gevallen kunnen af ​​en toe voorkomen, maar bestudeer nog steeds goed over elk acceptatiecriterium en probeer het te visualiseren met verwijzing naar het gebruikersverhaal. Hoe meer u de voorwaarden en bedrijfsregels grondig bestudeert, hoe meer uw kennis over de functie zal zijn.

Bugs gevonden in de beginfase kosten niets vergeleken met wat ze kunnen kosten in de ‘testfase’.

Belang van het vinden van verschillen in gebruikersverhaal / acceptatiecriteria

Het is altijd belangrijk om al in een vroeg stadium diep in de user stories en acceptatiecriteria te duiken, nog voordat de ontwikkeling of het testen begint.

Omdat het gaat om:

# 1) Tijdverspilling:

Als de discrepanties of fouten in het gebruikersverhaal / acceptatiecriteria worden gevonden wanneer de ontwikkeling aan de gang is of het testen aan de gang is, dan moet er mogelijk veel herwerk worden gedaan in de resterende sprinttijd.

Het gebeurt niet dat zelfs als de Product Owner weinig dingen heeft gemist, hij het user story naar de komende sprint zal verplaatsen. De kans is 95% dat ze het team vragen om de nodige implementatie te doen en deze in dezelfde sprint vrij te geven.

Daarom wordt het een nachtmerrie voor het team omdat ze extra tijd moeten doorbrengen, in het weekend moeten komen of 's avonds laat moeten werken. Dit kan worden voorkomen door de user story / acceptatiecriteria in een zo vroeg mogelijk stadium te bestuderen en te bespreken.

# 2) Verspilling van inspanningen:

De ontwikkelaars en QA moeten de geïmplementeerde code en testcases opnieuw bekijken. Updaten, toevoegen en verwijderen volgens vereiste is geen gemakkelijke taak. Het wordt te pijnlijk omdat er al een druk is om op tijd te leveren.

In zo'n situatie is er kans op fouten in de ontwikkel- of testfase. Als je een dergelijke situatie tegenkomt, ga dan voor ‘DevQA Pairing’. Als kers op de taart krijgt u mogelijk geen vergoeding voor het extra werk.

Gevolgtrekking

Een diepgaand begrip van User Story en acceptatiecriteria kan alleen worden bereikt door enorm veel tijd te besteden aan het bestuderen ervan.

Er is geen specifieke tool of cursus op de markt om dit voor u te doen, aangezien het allemaal gaat om logisch denken, ervaring en kennis over het product.

Actief deelnemen aan Pre-plan meeting, praten met de BA, alleen studeren kan je alleen maar helpen om dit te bereiken. Hoe meer inspanningen u levert, hoe meer u leert en groeit.

Of het nu de QA's of ontwikkelaars zijn, iedereen moet op dezelfde pagina zijn over de gebruikersverhalen en hun acceptatiecriteria, alleen dan kunnen de verwachtingen van de klant met succes worden bereikt.

Heeft u iets nieuws met ons te delen over uw ervaringen met het werken met gebruikersverhalen? Geef hieronder uw mening weer !!

Aanbevolen literatuur

• MongoDB Maak een gebruiker en wijs rollen toe met voorbeelden
• Voorbeeldsjabloon voor acceptatietestrapport met voorbeelden
• Gebruikersauthenticatie in MongoDB
• Parametrering van JMeter-gegevens met behulp van door de gebruiker gedefinieerde variabelen
• Unix-machtigingen: bestandsmachtigingen in Unix met voorbeelden
• Wat is acceptatietesten (een complete gids)
• Wat is het testen van gebruikersacceptatie (UAT): een complete gids
• Python DateTime-zelfstudie met voorbeelden