Share
Een veel voorkomend probleem bij het documenteren van vereisten is om vanuit het systeemperspectief een standpunt in te nemen om te beschrijven wat nodig is en te vergeten dat het de gebruiker is die in het middelpunt van de interacties staat. Gebruikersverhalen, geïntroduceerd door Agile, pakken dit probleem aan door van de gebruiker het middelpunt van de vereiste te maken, en Gedragsgestuurde ontwikkeling (BDD) gaat een stap verder en biedt een raamwerk waarin het gedrag van de gebruiker de ontwikkeling stimuleert.
Door BDD-technieken te gebruiken om gebruikersverhalen te maken, kunnen documentatievereisten gemakkelijker worden geschreven en gelezen. Het biedt ook extra hulpmiddelen om de beoogde gebruikerservaring van een ontwerp te communiceren, dat ontwerpers, ontwikkelaars en QA-technici kunnen gebruiken om een deel van hun werk snel te volgen en zelfs te automatiseren. In dit artikel zal ik deze aanpak onderzoeken en laten zien hoe je het kunt gebruiken om je eigen ontwerpen te documenteren, van kleine verhalen tot het organiseren van die verhalen voor het communiceren van volledig functionele kenmerken.
Er moet een belangrijk onderscheid worden gemaakt tussen UI-vereisten (ook bekend als specificaties) en UX-vereisten. Aan de ene kant zijn UI-vereisten technische documenten met specifieke informatie over de gebruikersinterface, waaronder lettertypen, kleuren, afmetingen en lay-out van elementen. Een goed voorbeeld van dit soort documentatie zijn Living Style Guides.
De UX-vereisten beschrijven daarentegen wat de ervaring zou moeten zijn voor een specifiek gebruiker, aangezien deze gebruiker in een specifiek scenario een specifieke actie uitvoert. Een gebruikersverhaal kan een UX-vereiste op een zeer beknopte manier vastleggen. Bijvoorbeeld:
Dit verhaal geeft eerst de rol van de gebruiker aan, wat deze gebruiker wil bereiken en legt vervolgens de reden erachter uit. Dit is geweldig want het geeft ontwikkelaars en testers inzicht in wat het uiteindelijke doel is: te voldoen aan de behoefte van een gebruiker. Merk op dat de vetgedrukte woorden de sjabloon zijn die wordt gebruikt om het verhaal te schrijven. Er is altijd een gebruiker die iets wil doen, zodat ze een specifiek doel kunnen bereiken. Je kunt deze tips volgen voor het schrijven van goede gebruikersverhalen.
Met dit verhaal in gedachten kan het ontwerpteam besluiten dat een "goedkeuringsactie" nodig is om het doel van de gebruiker te bereiken. Vervolgens kunt u specifieke informatie opgeven over hoe dit daadwerkelijk werkt. U kunt de syntaxis van Gherkin gebruiken. Dit is een BBD-tool voor het schrijven van door bedrijven leesbare vereisten. De syntaxis van Gherkin lijkt op agile gebruikersverhalen omdat het een manier biedt om eisen te schrijven die ook als sjabloon kunnen worden gebruikt. Het voordeel is dat u meer in detail kunt treden, door scenario's en acties te bieden die de gebruiker zou nemen zonder in te gaan op hoe de implementatie zou moeten worden uitgevoerd. Laten we er eens goed naar kijken.
De basis van een verhaal met behulp van Gherkin Syntax kan in deze delen worden samengevat:
Een kenmerk is een plaats om de algemene bedrijfswaarde van de implementatie te beschrijven. Het kan ook worden gebruikt om aanvullende informatie te verstrekken, zoals bedrijfsregels of iets dat de functie gemakkelijker te begrijpen maakt (zoals koppelingen naar prototypen of gebruikersvereisten).
Een scenario beschrijft de specifieke omstandigheden waarin de gebruiker zich bevindt. Vanuit het perspectief van een gebruikersontwerp maken scenario's het mogelijk om de meerdere variabelen van een ontwerp te communiceren en hoe de gebruikersinterface deze moet verwerken, volgens de gebruiker.
Een voorwaarde helpt bij het opbouwen van het scenario en verwijdert elke dubbelzinnigheid. In een scenario dat een eerste gebruiker beschrijft die een bepaald scherm opent, kan de voorwaarde bijvoorbeeld verduidelijken dat de gebruiker is aangemeld.
Een actie geeft precies aan wat de gebruiker in de interface doet, en is meestal een "trigger", zoals op een knop klikken, een formulier verzenden of naar een andere plaats navigeren..
Een uitkomst is het gevolg van de actie en zou altijd iets moeten zijn dat kan worden getest.
Laten we met deze delen in gedachten een gebruikersverhaal schrijven voor de functie die we eerder hebben beschreven:
Met Gherkin Syntax zou dit verhaal er als volgt uitzien:
| Voorzien zijn van | Sta toe dat uitgevers artikelen beoordelen voordat ze definitief worden gepubliceerd en stempelen hun goedkeuring daarop. |
| Scenario | Een artikel goedkeuren dat gereed is voor publicatie. |
| eerste vereiste |
|
| Actie |
|
| Resultaat |
|
U kunt zien hoe het eerste verhaal verandert in een meer gedetailleerde stroom die de gebruiker kan volgen en daarom kan dat worden getest. Merk ook op dat de vetgedrukte woorden de sleutelwoorden zijn die software zoals komkommer gebruikt om de uitvoering van tests te automatiseren. Ik zal hier later meer over vertellen, maar voor nu wil ik erop wijzen dat deze zoekwoorden ook zeer nuttig zijn voor het schrijven van het verhaal omdat ze helpen om de verschillende delen van het verhaal te onderscheiden..
Iets anders om op te wijzen is dat hoewel het verhaal meer details geeft over de gebruikersstroom, de interface niet wordt beschreven. De reden hiervoor is dat het beschrijven van de UI het verhaal snel in UI-vereisten kan veranderen, wat een groot probleem vormt, omdat ze nogal snel verouderd kunnen raken. Als het verhaal bijvoorbeeld beschrijft hoe de succeswaarschuwing eruit ziet en wat de specifieke boodschap zou moeten zeggen, dan kan het verhaal niet meer synchroon lopen als een van deze wijzigingen verandert, waardoor het potentieel van mislukkende tests ontstaat.
Het is dus de kunst om voldoende details te bieden, zonder dat daarvoor meer geschikte hulpmiddelen nodig zijn, zoals ontwerpmodellen, prototypen en stijlgidsen. In dit opzicht zult u merken dat de actie wel aangeeft "goedkeuren" te selecteren versus alleen "goedkeuren" te gebruiken. "Goedkeuren selecteren" is niet specifiek over hoe dit besturingselement eruit ziet (het kan een knop zijn, een knop die eruit ziet als een koppeling of een vak dat kan worden aangeklikt), maar het betekent wel dat een element in de gebruikersinterface wordt geactiveerd. Het geeft ook aan dat dit element erin is geschreven "goedkeuren". Dit is een grijs gebied waar u gezond verstand moet gebruiken, omdat u in sommige gevallen dit specifiek wilt zijn, zodat acties van anderen kunnen worden onderscheiden. Als er bijvoorbeeld een andere manier is om een artikel op dezelfde pagina goed te keuren, geeft dit aan dat de gebruiker in dit scenario het moet 'selecteren', de differentiatie mogelijk maakt.
Naast de doordachte syntax die Gherkin biedt, is een van de dingen die ik het handigst vind het gebruik van het gedeelte "scenario's". Scenario's zijn krachtig omdat ze kunnen worden gebruikt om het ontwerp te testen en ervoor te zorgen dat alle bases worden gedekt.
Meestal beginnen ontwerpen van welke aard dan ook met het "gelukkige pad", wat betekent wat er gebeurt als alles goed gaat in de interface en hoe dit van toepassing is op de meeste gebruikers. In ons vorige voorbeeld hadden we:
| Scenario | Een artikel goedkeuren dat gereed is voor publicatie. |
Omdat we weten dat artikelen over publicatiedatums beschikken, kunnen we ook vermelden: dit is ons eerste scenario omdat in de meeste gevallen artikelen die moeten worden goedgekeurd, gereed moeten zijn voor publicatie. Maar dit brengt de vraag: wat gebeurt er wanneer een artikel niet gereed is voor publicatie en de uitgever er toegang toe heeft? Mochten ze zelfs toegang hebben tot die artikelen?
Al deze vragen maken deel uit van het ontwerpproces en hoogstwaarschijnlijk, tegen de tijd dat u de documentatievereisten ingaat, kent u de antwoorden. Het goede nieuws is dat het gebruik van scenario's in uw verhaaldocument u zal helpen bij het structureren ervan en in veel gevallen zal helpen om uw eigen ontwerpen te QA, ervoor te zorgen dat er een ontwerp en stroom is voor elk van hen.
Laten we eens kijken hoe ons verhaal vorm krijgt met de aanvullende scenario's:
| Voorzien zijn van | Sta toe dat uitgevers artikelen beoordelen voordat ze definitief worden gepubliceerd en stempelen hun goedkeuring daarop. |
| Scenario 1 | Een artikel goedkeuren dat gereed is voor publicatie.
|
| scenario 2 | Toegang tot een artikel dat niet gereed is voor publicatie.
|
| scenario 3 | Een artikel goedkeuren dat een vervaldatum heeft
|
| scenario 4 | Niet-goedkeuring van een artikel met een publicatiedatum in de toekomst
|
| scenario 5 | Een artikel dat is gepubliceerd niet meer goedkeuren
|
Afhankelijk van de functie kunnen er veel verschillende scenario's worden overwogen. Het belangrijkste is om ze kort te houden, zodat je ze gemakkelijk kunt beschrijven en testen. Je kunt ook proberen ze te groeperen, gebruikmakend van gemeenschappelijke noemers. Als een paar scenario's bijvoorbeeld dezelfde randvoorwaarde hebben, kunt u dit inkapselen in een 'achtergrond' die door meerdere scenario's kan worden gebruikt. Bijvoorbeeld:
| Achtergrond | De schrijver heeft een artikel voor publicatie ingediend en de uitgever heeft de weergave van het artikel bekeken. |
| Scenario 1 | Een artikel goedkeuren dat gereed is voor publicatie.
|
| Scenario 2 | Een artikel goedkeuren dat een vervaldatum heeft.
|
| Scenario 3 | Niet-goedkeuring van een artikel met een publicatiedatum in de toekomst.
|
Een veel voorkomende uitdaging die zich voordoet bij het documenteren van vereisten, is bij het bepalen van de volgorde. De reden is dat in de meeste gevallen alles in aanbouw is, wat het moeilijk maakt om een interactie te testen wanneer de delen van de interacties nog niet zijn gebouwd. In de eenvoudige interactie van het 'goedkeuren' van een artikel moeten bijvoorbeeld veel dingen gereed zijn:
Een benadering voor het documenteren van vereisten voor elk van deze afhankelijkheden om ze op te nemen als verschillende functies die vervolgens kunnen worden geprioriteerd op basis van hun bedrijfswaarde.
| Voorzien zijn van | Omschrijving | Prioriteit |
|---|---|---|
| Waarschuwingssysteem | De gebruikersinterface moet een succesbericht en een foutbericht kunnen retourneren in het geval er een probleem met het systeem is | 2 |
| Tagging-systeem | De gebruikersinterface moet artikelen kunnen 'taggen' als goedgekeurd | 4 |
| Publicatiesysteem | De gebruikersinterface zou het artikel moeten kunnen weergeven volgens de "gepubliceerde" bedrijfslogica | 1 |
| Meldingen Systeem | Systeemmeldingen moeten worden ingeschakeld, zodat schrijvers kunnen worden gewaarschuwd wanneer de goedkeuring plaatsvindt | 3 |
Dan kun je een "integratie" -verhaal maken om ze allemaal bij elkaar te brengen. Een gebruikersverhaal voor het tagingsysteem zou bijvoorbeeld dit kunnen:
| Voorzien zijn van | Gebruikers en het systeem toestaan artikelen te taggen volgens een bepaalde staat (niet gepubliceerd, goedgekeurd, gepubliceerd of gearchiveerd). |
| Scenario 1 | Een artikel labelen als niet gepubliceerd.
|
| Scenario 2 | Een artikel labelen als goedgekeurd.
|
| Scenario 3 | Een artikel labelen zoals gepubliceerd.
|
| Scenario 4 | Een artikel labelen als gearchiveerd.
|
In het integratieverhaal kunt u verwijzen naar het tagging-verhaal, in het geval dat de details voor dat scenario opnieuw moeten worden geverifieerd of als u gewoon wilt weten of die gevallen al zijn geverifieerd.
| Voorzien zijn van | Sta toe dat uitgevers artikelen beoordelen voordat ze definitief worden gepubliceerd en stem hun goedkeuring daarop toe. |
| Scenario 1 | Een artikel goedkeuren dat gereed is voor publicatie.
|
Het gaat erom herhalende documentatie te voorkomen die niet alleen onnodig veel tijd kost, maar ook niet synchroon loopt.
We hebben gezien hoe bruikbaar Gedrag Gedreven Gebruikersverhalen kunnen zijn voor het schrijven van vereisten die gericht, beknopt maar ook grondig en beschrijvend zijn. Vanaf de ontwerpfase kan deze tool een goede inleiding geven voor QA-engineers voor het schrijven van echte testcases.
Naast deze grote voordelen kunnen Gedrag Gedreven Gebruikersverhalen feitelijk worden omgezet in functionele tests met behulp van software zoals Komkommer of Sla. Het basisidee is dat zodra de verhalen zijn geschreven met de syntaxis van Gherkin, je ze in een .voorzien zijn van bestand in uw app en voer ze vervolgens uit als tests om te zien of ze succesvol waren of niet. Voor een uitgebreide tutorial over het gebruik van Lettuce voor een Python-implementatie, bekijk de tutorial van David Sale:
Het schrijven van gebruikersverhalen met behulp van de principes van BDD kan dienen om gedetailleerd te communiceren over bedrijfs- en ontwerpvereisten, met een gebruikersgerichte aanpak, terwijl een taal wordt gebruikt die leesbaar, maar uitbreidbaar is voor software-interpretatie. Daarnaast kan het worden gebruikt om te testen:
Dit betekent meer lagen voor fouten om door te nemen, hiaten in het ontwerp te voorkomen en uw toepassing verder te beschermen tegen bug-fouten.
Accentsconagua