What is user Story and Acceptance Criteria (Examples)

een perfecte Gids Voor User Story Acceptance Criteria met real-life scenario ‘s:

in de Software ontwikkeling industrie, het woord’ Requirement ‘ definieert wat ons doel is, wat de klanten precies nodig hebben en wat ons bedrijf zal maken om zijn activiteiten uit te breiden.

of het nu een productbedrijf is dat softwareproducten maakt of een dienstverlenend bedrijf dat diensten aanbiedt op verschillende softwaregebieden, de belangrijkste basis voor al deze producten is de eis en het succes wordt bepaald door hoe goed aan de eisen wordt voldaan.,

De term “vereiste” heeft verschillende namen in verschillende projectmethodologieën.

in Waterfall wordt het aangeduid als ‘vereiste / specificatie Document’, in Agile of SCRUM wordt het aangeduid als’ Epic’,’User Story’.

onder Waterfall-model zijn de vereiste documenten enorme documenten van 200 of meer pagina ‘ s omdat het hele product in één fase wordt geïmplementeerd. Maar dit is niet het geval met Agile/SCRUM omdat in deze methodologieën de vereisten worden gegeven voor kleine functionaliteiten of functies als het product stap voor stap wordt voorbereid.,

in dit artikel heb ik mijn best gedaan om al mijn 4 jaar ervaring met het werken met gebruikersverhalen en de bijbehorende acceptatiecriteria te delen, samen met eenvoudige en eenvoudige real-life scenario ‘ s voor een beter begrip.

laten we eerst de fundamentals opnieuw bezoeken.

Wat is een gebruikersverhaal?

een gebruikersverhaal is een vereiste voor elke functionaliteit of functie die is opgeschreven in een of twee regels en maximaal 5 regels. Een verhaal van de gebruiker is meestal de eenvoudigste mogelijke eis en gaat over een en slechts één functionaliteit (of een functie).,

het meest gebruikte standaardformaat voor het maken van een verhaal van een gebruiker wordt hieronder vermeld:

als een <rol van de gebruiker/klant, Ik wil < doel dat moet worden bereikt> zodat ik <reden van het doel>.

voorbeeld:

als WhatsApp-gebruiker wil ik dat een camerapictogram in het schrijfveld van de chat foto ’s opneemt en verstuurt, zodat ik mijn foto’ s tegelijkertijd kan klikken en delen met al mijn vrienden.

Wat zijn acceptatiecriteria?,

een acceptatiecriterium is een reeks geaccepteerde voorwaarden of bedrijfsregels waaraan de functionaliteit of functie moet voldoen om door de eigenaar/Stakeholders van het Product te worden aanvaard.

Dit is een zeer belangrijk onderdeel van de voltooiing van het verhaal van de gebruiker en het moet zeer zorgvuldig worden bestudeerd door de eigenaar van het Product en Business Analist, omdat het missen van een enkel criterium veel kan kosten. Dit is een eenvoudige genummerde of opsommingsteken lijst.

het formaat is als volgt:

“gegeven een voorwaarde als ik wat actie doe dan verwacht ik het resultaat”.

voorbeeld (w.r.,t tot boven gebruikersverhaal):

• laten we overwegen dat ik aan het chatten ben met een vriend en dat ik in staat zou moeten zijn om een foto vast te leggen.
• wanneer ik op een afbeelding Klik, zou ik een bijschrift aan de afbeelding moeten kunnen toevoegen voordat ik het verstuur.
• als er een probleem is met het starten van mijn telefooncamera, kan een foutmelding als ‘Camera kon niet worden gestart’worden gegeven. etc., moet dienovereenkomstig worden aangetoond.

daarom definieert het gebruikersverhaal de eis voor elke functionaliteit of functie, terwijl de acceptatiecriteria de ‘definitie van gedaan’ voor het gebruikersverhaal of de eis definiëren.,

als een QA is het zeer belangrijk om het verhaal van de gebruiker en de acceptatiecriteria grondig te begrijpen, zonder zelfs maar een enkele twijfel over te houden aan de ‘start van het testen’. Laten we begrijpen waarom het uiterst belangrijk is om ‘diep’ te graven in de verhalen van gebruikers en acceptatiecriteria.

diep graven in gebruikersverhalen

om te beginnen, laten we eerst het belang begrijpen van een ‘diepgaande’ studie van een fundamenteel en fundamenteel ding, namelijk gebruikersverhalen.

de volgende gevallen zijn mijn eigen echte ervaringen.,

geval # 1:

voor 3 jaar werkte ik aan een project voor mobiele toepassingen en het product was een toepassing die was ontworpen voor de bezorgers.

u zou een bezorger naar uw plaats hebben zien komen voor levering. En ze hebben een mobiele telefoon waarop ze u vragen om uw handtekening te geven na levering. Deze handtekening reflecteert op het portaal van koeriersdiensten zoals DTDC, FedEx etc.

stel je voor dat de mobiele app net is gestart en hun portals al bestaan en omhoog.,

probleem: voor een Sprint heeft uw producteigenaar een gebruikersverhaal voor deze mobiele app dat “als Portaalbeheerder, ik in staat zou moeten zijn om de handtekening te bekijken die de bezorger op het moment van levering heeft genomen”. Hier wordt de portal (web app) aangepast en bijgewerkt om de handtekening weer te geven.

Als QA moet u controleren of de handtekening die in de mobiele app is vastgelegd, wordt weergegeven zoals verwacht in het portaal.,

als je naar dit gebruikersverhaal kijkt, ziet het er eenvoudig uit, maar er is hier een verborgen eis dat “Voor historische leveringen, er geen Signature reflectie functionaliteit was, dus wat moet er gebeuren als de portal jongens historische leveringen bekijken?”Moeten Historische gegevens worden weggevaagd? Moeten we crashes of fouten voor dergelijke gegevens toestaan?

natuurlijk niet, dit moet vriendelijk worden behandeld.,

oplossing: wanneer de respectieve DB-tabellen worden bijgewerkt om een nieuwe kolom toe te voegen voor de Handtekeninglocatie, moeten de oude gegevens een NULL-of 0-waarde hebben die moet worden gecontroleerd en moet een bericht met de vermelding “geen handtekening bestaat” worden getoond.

dit kan worden genoemd als een misser van de producteigenaar of Business Analist, maar dit moet worden gedaan. De uitvoering van een functie met succes, maar het breken van iets samen met het is niet wenselijk door de klanten. Dit moet worden gedaan samen met dezelfde gebruiker verhaal en in dezelfde sprint.,

Case # 2

6 jaar geleden werkte ik aan een financieringsaanvraag voor pensioenplanning (zonder BA), een wereldwijde toepassing waarbij financiële mensen zoals CA, financiële adviseurs het konden gebruiken voor verschillende valuta ‘ s om investeringsplannen, spaargelden, enz.te projecteren., over een grote periode aan hun klanten.

probleem: de eigenaar van het Product geeft u een gebruikersverhaal dat “als adviseur wil ik het rapport van mijn klant bekijken op basis van de verstrekte financiële gegevens”.,

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

a] de rapporten moeten rekening houden met de dagelijkse wisselkoers van de valuta en niet de historische zoals in het laatst bekeken rapport en

b] Als de valuta wordt gewijzigd na het verstrekken van de financiële gegevens van de klant, moeten de Rapporten worden weergegeven in de gewijzigde valuta.

oplossing: Ik heb deze bezorgdheid rechtstreeks aan de orde gesteld bij onze producteigenaar en hem erop gewezen dat beide zo snel mogelijk moeten worden gedaan. Hij was het met me eens en creëerde 2 verschillende verhalen voor de komende sprints met prioriteit.,

Take Away: deze werden gevangen omdat we allemaal zeer goed op de hoogte waren van de producten, hun ontwerp, structuur etc. Dergelijke kennis kan alleen worden bereikt door het product volledig te begrijpen, door de interoperabiliteit van modules te begrijpen en door het verhaal van de gebruiker grondig te bestuderen, zelfs als het een 2 liner is.

Maak notities om het makkelijker te maken en bespreek met de BA ‘ s en de ontwikkelaars over hun denken.,

grondig kijken naar acceptatiecriteria

inzicht in de acceptatiecriteria en alle andere voorwaarden& regels uitputtend is nog belangrijker dan het understateren van een gebruikersverhaal. Want als een vereiste onvolledig of vaag is, kan het worden opgenomen in de volgende sprint, maar als een acceptatiecriterium wordt gemist, dan kan het verhaal van de gebruiker zelf niet worden vrijgegeven.

Ik denk dat we allemaal op een gegeven moment net banking zouden hebben gebruikt en de meesten van ons gebruiken het elke dag en ik download Mijn historische statements veel., Als je het zorgvuldig te observeren, er zijn bepaalde specifieke opties beschikbaar voor het downloaden van hen.

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

stel je nu voor dat de eigenaar van het Product je dit gebruikersverhaal geeft: “als klant wil ik mijn rekeningafschrift downloaden, zodat ik al mijn transacties voor een specifieke periode kan bekijken”.,

met de volgende acceptatiecriteria:

• aangezien ik op de pagina Download Historical Statement sta, moet ik de periode selecteren waarvoor ik het statement wil downloaden.
• aangezien ik op de pagina Download Historical Statement sta, moet ik het account selecteren waarvoor ik het statement wil downloaden.
• aangezien ik op de pagina Download Historical Statement sta, mag ik het statement niet downloaden voor toekomstige ‘To’ – Datum.,
• aangezien ik op de pagina Download Historical Statement sta, mag ik in het verleden geen ‘From’ – datum 10 jaar later selecteren.
• aangezien ik mijn statement download, zou ik het gedownloade bestand moeten kunnen bekijken.
• aangezien ik op de Download Historical Statement-pagina sta, zou ik mijn statement in doc -, excel-en pdf-formaten moeten kunnen downloaden.

Als u door deze acceptatie gaat, ontbreken hier 3 dingen:

• naam en opmaak van de bestandsnaam die zal worden gedownload.,
• welke informatie (kolomnamen) moet in het bestand worden weergegeven.
• de optielijst om te selecteren welk soort transactie de klant wil, dat wil zeggen alleen afschrijvingen of alleen credits of beide.

dergelijke gevallen kunnen zich af en toe voordoen, maar bestudeer nog steeds goed over elke acceptatiecriteria en probeer het te visualiseren met verwijzing naar het verhaal van de gebruiker. Hoe meer je diep studeren over de Voorwaarden en zakelijke regels hoe meer zal uw kennis over de functie.

Bugs gevonden in de beginfase kosten niets vergeleken met wat het kan kosten in de testfase.,

belang van het vinden van discrepanties in gebruikersverhaal/acceptatiecriteria

het is altijd belangrijk om in een vroeg stadium diep in de gebruikersverhalen en acceptatiecriteria te duiken, zelfs voordat de ontwikkeling of het testen begint.

omdat het gaat om:

#1) verspilling van tijd:

als De discrepanties of fouten in het verhaal / acceptatiecriteria van de gebruiker worden gevonden wanneer de ontwikkeling aan de gang is of het testen aan de gang is, dan kan het nodig zijn om veel herwerking te doen in de resterende sprint tijd.,

het gebeurt niet dat zelfs als de producteigenaar een paar dingen miste, ze het gebruikersverhaal naar de komende sprint zullen verplaatsen. 95% kans is 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 vermeden door het bestuderen en bespreken van de gebruiker verhaal/acceptatiecriteria in de vroegst mogelijke fase.

#2) verspilling van inspanningen:

De ontwikkelaars en QA moeten de geà mplementeerde code opnieuw bekijken en cases opnieuw testen., Updaten, toevoegen en verwijderen als per eis is geen gemakkelijke taak. Het wordt te pijnlijk omdat er al druk is om op tijd te leveren.

In een dergelijke situatie is er kans op fouten in de ontwikkelings-of testfase. Als je zo ’n situatie tegenkomt, ga dan voor’DevQA Pairing’. Als kers op de taart krijg je misschien geen compensatie voor het extra werk.

conclusie

diep begrip van het verhaal van de gebruiker en acceptatiecriteria kan alleen worden bereikt door immense tijd te besteden aan het bestuderen ervan.,

er is geen specifieke tool of cursus beschikbaar in de markt om dit voor u te doen, omdat dit alles over logisch denken, ervaring en kennis over het product gaat.

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

of het nu de QA ‘ s of ontwikkelaars zijn, iedereen moet op dezelfde pagina staan over de verhalen van gebruikers en hun acceptatiecriteria, alleen dan kunnen de verwachtingen van de klant succesvol worden bereikt.,

wilt u iets nieuws met ons delen over uw ervaringen met het werken met gebruikersverhalen? Gelieve uw gedachten hieronder te uiten!!