Agilt eller inte

2009-02-11 Artikelbanken Test Läst 9779 gånger

Ofta beskrivs de agila metoderna som en helt annan värld jämfört med traditionell utveckling. Många av de tekniker som används i agil utveckling går dock utmärkt att tillämpa i det som vi vanligtvis ser som traditionellt krav- och testarbete. Den här artikeln ger konkreta tips som visar hur modellerna kan samverka baserat på erfarenheter både från projektet där vi utvecklar verktyget ReQtest enligt Scrum och från våra kunder.

Användarberättelser som grund för både krav och test

Ett vanligt problem i traditionell utveckling är kravens omfattning. Visst finns det de som skriver för få krav, men jag upplever att det är minst lika vanligt och allvarligt att skriva alltför omfattande kravdokumentation. Med för lite dokumentation uppstår osäkerhet om vad som ska levereras och testas. För mycket dokumentation å andra sidan gör att läsaren drunknar i detaljer. Det blir också svårare att hantera förändringar om en stor mängd dokumentation behöver uppdateras varje gång och då ökar förvaltningskostnaderna. Det man bör sträva efter är att dokumentationen ska vara tillräckligt bra för ändamålet, därmed undviker man att överarbeta dokumentationen.

I agila metoder dokumenteras kraven ofta i form av användarberättelser (user stories), där de övergripande kraven ofta bara är någon eller några få rader långa. Varje användarberättelse bryts ner i detaljer som specificeras i testfall. Dessutom dokumenteras den dialog som uppstår mellan utvecklaren och intressenten. Användarberättelsen i kombination med dess testfall och dialogen utgör det underlag som utvecklaren arbetar utifrån. 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 i krav i traditionell utveckling, eller som drunknar bland detaljerna.

En användarberättelse dokumenteras ofta enligt en mall som liknar denna:
Som en [roll] vill jag [mål] så att jag kan [anledning].

Exempel på användarberättelse:
Som en projektledare vill jag se status för alla utvecklingsuppdrag så att jag kan bedöma om vi kommer att bli klara i tid.

Exempel på testfall för denna användarberättelse:
En lista över alla uppdrag där status framgår. Det ska gå att sortera listans samtliga kolumner.

Komplettera kravdokumentationen när det behövs

Användarberättelser räcker i många fall, speciellt om de kompletteras med prototyper. Det är kanske inte nödvändigt att beskriva basala funktioner i form av användningsfall med huvudflöde och alternativflöden. Om man känner att det är för få detaljer i en användarberättelse kan man med fördel komplettera användarberättelserna med användningsfall, vanliga krav eller beslutstabeller. Vår rekommendation är att så långt det är möjligt använda testfall som detaljerade krav. Syftet är ungefär detsamma och en ytterligare fördel minskad komplexitet kring hantering av spårbarhet mellan olika kravnivåer och testdokumentation.

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 dem också 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 eller 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å och sedan upprepa testet med en annan användare. Användningstester kan göras på bildskärmsskisser, bilder ritade i ritprogram som Microsoft Visio 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.

Tänk test tidigare

Användarberättelser löser även ett testrelaterat problem. I traditionell utveckling är det vanligt att testfallen skrivs alltför sent. Resultatet blir att brister i kraven upptäcks sent, ofta så sent att det är för sent eller för dyrt att åtgärda problemen. Genom att författaren skriver testfallen parallellt med att kraven skrivs, blir resultatet att acceptanstestfallen är klara när kraven är klara. Testfallen fungerar som nästa detaljeringsgrad under kravnivån.

Ett problem som en del stöter på i agil utveckling är att man inte hinner regressionstesta tillräckligt mycket eftersom iterationen är alltför kort. En lösning är att genomföra några iterationer bestående av design, implementering och lågnivåtester. Därefter kompletterar man med en iteration som bara innehåller testaktiviteter. En sådan iteration kan ha olika syften, t ex fokus på systemtest, samband med andra system, regression eller prestanda. Därefter fortsätter man det agila arbetet med korta iterationer.

När man börjar arbeta agilt finns det en risk att man skriver för lite testdokumentation. Om iterationerna är ungefär en månad behövs inte en särskilt omfattande testplan. Testplanering behöver alltid göras. 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 genomförandet.

Effektivisera möten och kommunikationen

Kommunikation är ett vanligt problem. Det gäller att kommunicera så att inblandade vet status på aktiviteter och känner till eventuella problem. Det gäller också att regelbundet ta tillvara erfarenheter så att arbetsmetodiken utvecklas.

De agila metoderna argumenterar för att använda dagliga avstämningsmöten inom projekten. Detta är förstås något som alla projekt mår bra av. Det är ofta lämpligt att dagliga avstämningsmöten hålls i form av korta ståmöten för att inte de ska dra ut på tiden. Under ett avstämningsmöte går man igenom vad som gjorts sedan i går, vad som ska göras i dag och om det finns några problem som behöver diskuteras. Det är också bra att visualisera förloppet, exempelvis med en burn down chart.

Varje iteration bör inledas med ett planeringsmöte där varje utvecklings- och testaktivitet tidsestimeras. Iterationer bör avslutas med en utvärdering, det som i Scrum kallas retrospective. Syftet med dessa möten är att hitta förbättringsområden i processen. Det är alltför vanligt att hoppa över denna utvärdering i traditionell utveckling. Resultatet blir att man upprepar samma misstag igen och att man inte tar till sig goda exempel som man vill ska upprepas i nästa iteration. Planering och utvärderingen är exempel på längre möten. En bra tumregel är att möten ska involvera 5-7 personer och att en majoritet av mötena ska vara kortfattade.

Kommunikationen underlättas också av praktiska faktorer som möbleringen. En närhet mellan utvecklingsgruppen och beställare betonas i agila metoder, helst ska alla sitta i samma rum. Att sitta nära varandra kan tillämpas även i traditionell utveckling. Om det inte är möjligt att alltid sitta nära varandra kanske man kan göra det periodvis. Kommunikationen underlättas av närheten. Om man sitter långt från varandra är det lätt att det uppstår en känsla av ”vi och dom” mellan olika grupper som beställare, användare och utvecklare. Vid tillfällen då man är tvungen att sitta på olika platser, till exempel då leverantören eller kunden sitter på en annan ort, är det extra viktigt att få en gruppkänsla med hjälp av kick-off och andra aktiviteter. Det är också viktigt med täta avstämningar, exempelvis i form av veckomöten och kommunikation med e-post.

Sammanfattning

  1. Skriv användarberättelser och detaljera kraven i form av testfall
  2. Prototyper är ett bra sätt att förbättra kravdialogen och kvittera att rätt system byggs enligt kraven.
  3. Ha täta avstämningsmöten med rätt antal personer. Överväg att förkorta vissa möten.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln