Från användarberättelser till färdigtestat system

Denna artikel publicerades ursprungligen av Konsultbolag1. Sedan 2020 har verksamheten gått ihop med inUse (part of AFRY). Vi har sedan dess kunnat erbjuda ett spännande urval av kurser inom de samspelande områdena kravhantering, test, design och effektkartläggning under inUse Academy.

Krav kan skrivas i form av användarberättelser som fångar behoven utifrån användarnas behov. Användarberättelserna kan vidareutvecklas till användningsfall och testfall och baserat på dessa kan systemet byggas. Genom att samla in krav med agila metoder och inkludera testningen i arbetet ökar möjligheten att lyckas rejält! Erfarenheterna baseras bland annat på utveckling av ReQtest, ett krav- och testadministrativt verktyg.

Skriv krav i form av användarberättelser

Användarberättelser (user stories) är en kravdokumentationsteknik som utgår från användarens sätt att uttrycka sina behov. De skrivs enligt en mall som ofta ser ut så här: som en <roll> vill jag <mål> så att jag <motivering>.

En stor fördel med användarberättelser är att de skrivs efter en mall som tvingar författaren att tala om för vem man gör kravet och varför det ska göras. Detta är något som ofta saknas helt när krav skrivs i traditionell utveckling. Alternativt drunknar informationen bland detaljerna, exempelvis i ett alltför omfattande användningsfall.

Exempel på beståndsdelar i en användarberättelse:

Formulerat som en användarberättelse blir det: Som en handläggare vill jag kunna ändra adress på en kund som har flyttat så att jag slipper ta bort kunden och lägga upp den igen.

Användarberättelser fungerar mycket bra för att beskriva krav på den översta detaljnivån.

Det leder till fokus på vad som behövs istället för hur det ska lösas, behov i stället för lösning, det vill säga inga tekniska detaljer för tidigt. Vi får även testfall tidigt genom ett indirekt iterativt arbete som även inkluderar automatisk granskning av användarberättelsen.

Ibland nämns det som en nackdel att användarberättelser blir tjatiga eftersom alla ser ut på samma sätt. Det man måste komma ihåg är att vi inte är ute efter att skriva berättelser, vi är ute efter att skriva krav som tolkas på samma sätt av alla som läser dem. Om krav skrivs på annat sätt fylls de av subjektiva ordalydelser som går att tolka på olika sätt av olika läsare.

En potentiell nackdel med användarberättelser är att de är för kortfattade. Det ryms inga komplicerade verksamhetsregler eller processbeskrivningar i en användarberättelse. Vi rekommenderar att man ser användarberättelser som bas för samtliga krav och kompletterar dem när det behövs.

Komplettera användarberättelserna

Varje användarberättelse blir mycket kortfattad. Detta är en stor fördel eftersom läsaren inte drunknar i detaljer som ofta gör förvaltningsarbetet svårare. Användarberättelser räcker i många fall, speciellt om de kompletteras med prototyper. Den andra sidan av myntet är att användarberättelser kan innehålla alltför få detaljer och därmed bli för oprecisa. En användarberättelse bör därför kompletteras med en dokumentation av den dialog som uppstår mellan utvecklaren och den som skrivit kravet. Dessutom ska varje användarberättelse kompletteras med det antal testfall som behövs för att bekräfta att kravet är uppfyllt. En användarberättelse i kombination med dess testfall och dialog utgör det underlag som utvecklaren arbetar utifrån.

Om man jämför en användarberättelse med ett användningsfall, så innehåller det senare ett huvudflöde och ett antal alternativa flöden. Det är inte nödvändigt att beskriva basala funktioner på detta sätt och då räcker användarberättelsens form utmärkt. Om man känner sig begränsad av att det är för få detaljer i en användarberättelse kan man med fördel komplettera användarberättelsen med användningsfall, vanliga krav eller beslutstabeller. En beslutstabell är praktisk när kravet är beroende av komplicerade verksamhetsregler. I en beslutstabell ställs verksamhetsreglerna upp i separata kolumner och varje kolumn blir sedan ett testfall.

Ett alternativ är att direkt detaljera användarberättelserna till uppgifter. Exempel på uppgifter är designa databas, utforma användargränssnitt eller skriva dokumentation. Varje användarberättelse kan detaljeras till ett antal uppgifter.

Skriv testfallen parallellt med kraven

Ett vanligt problem i traditionell utveckling är att testfallen skrivs alltför sent, ofta när systemet är helt eller delvis färdigt. Resultatet blir att brister i kraven upptäcks sent, ibland så sent att det inte går att åtgärda problemen eftersom det skulle vara för dyrt och/eller komplext. När man skriver krav i form av användarberättelser ser man testfallen som en del av kravet. Resultatet blir att testfallen är klara att användas när kraven är färdigskrivna. Testfallen fungerar också som nästa detaljeringsgrad under kravnivån.

Ofta upptäcker man luckor i kraven först när man skriver testfallen. Genom att tvingas skriva testfall samtidigt som kraven skrivs blir kraven automatiskt granskade på ett tidigt stadium. Granskning av kraven blir en integrerad del i arbetet och mindre tungrott än i traditionellt arbete.

Luckra upp rollerna

I förvaltning är det naturligt att den som skriver kraven också är med och testar. De agila teknikerna stödjer detta, bland annat genom att testfallen skrivs samtidigt som kraven skrivs. Ofta gör det att den som skriver krav även skriver testfall och testar i stället för att kraven skrivs av en roll och testerna skrivs och utförs av en annan roll. Detta ställer större krav på de personer som arbetar med förvaltning. Det räcker inte att vara bra på en av uppgifterna utan man behöver både kunna skriva krav och testa. De agila teknikerna gör att test involveras tidigare och kravledarens roll kan även omfatta att skriva testfall.

Effektivisera testerna

I agilt arbete finns det en risk att det skrivs för lite testdokumentation. Det är inte praktiskt möjligt att skriva testplaner för varje iteration. En testplan omfattar ofta ett tiotal sidor och om varje iteration är en månad lång, blir det ett tiotal testplaner per år. Det innebär inte att testplanering inte behövs utan alternativa lösningar behövs. En möjlighet är att skriva kortare testplaner, en annan är att ta fram en teststrategi för varje system. Teststrategin beskriver sådant som inte ändras från iteration till iteration. Typiska exempel är testmiljö, testdata och beskrivning av syftet med olika tester. En dokumenterad teststrategi är en trygghet att luta sig mot då tveksamheter uppstår under testgenomförandet.

Utför användningstester för bättre användbarhet

Ett vanligt problem är att man vid leverans av ny funktionalitet upptäcker att beställaren egentligen ville ha något annat. För att minimera detta problem kompletterar vi våra krav med prototyper när vi utvecklar ReQtest. Vi kombinerar dessa med så kallade användningstester som går ut på att en användare utför en verklig uppgift i systemet och berättar högt för en testledare om sådant som är svårt att förstå eller på annat sätt är otydligt. Ofta hittar vi saker som behöver förbättras och tack vare att vi har så korta iterationer kan vi ofta åtgärda problemen till dagen därpå. Vi kan sedan upprepa testet med en annan användare ytterligare någon dag senare.

Användningstester kan göras på bildskärmsskisser eller med prototyper i det halvfärdiga systemet. Utvecklarna uppskattar att de får snabb återkoppling i stället för att de behöver korrigera problemen mycket senare. Prototyperna fungerar som en kvittens mellan utvecklare och beställaren. Genom att beställaren tidigare förstår vad som kommer att levereras underlättas kravdialogen och kraven förtydligas på så sätt iterativt.

Ytterligare tekniker

Det finns förstås många andra agila tekniker som fungerar bra i traditionellt utvecklingsarbete.

Planning poker är ett bra sätt att estimera tid för alla slags utvecklingsaktiviteter inklusive krav och test. Arbetssättet är iterativ och demokratiskt, alla får komma till tals. Dessutom är startsträckan kort.

Det är viktigt att visualisera arbetet för att förbättra kommunikationen, exempelvis med teknikerna burn down chart och scrum-tavlan.

Rätt möten med rätt deltagare, vilket i princip innebör 90 % korta möten och 10 % långa möten med 5-7 deltagare. Mötena hålls gärna i form av ståmöten.

Sammanfattning

Skriv kraven i form av användarberättelser.
Komplettera dem vid behov.
Skriv testfallen samtidigt som kraven skrivs.
Skriv en teststrategi för att undvik att upprepa testplanen gång på gång.
Användningstester leder till bättre användbarhet.
Visualisera arbetet, t ex med en burn down-chart.

Läs allt om kurserna på inUse Academy här!