Kravene er gjerne beskrivelser av hva som skal utvikles og hvilke egenskaper det ferdige produktet skal eller bør ha. De kan være alt fra svært vage og generelle til veldig detaljerte. Det kan noen ganger være forretningssiden som selv skriver dem, andre ganger blir de til innad i utviklingsteamet mens vi går. Siden det gjerne er oss testere som har oppgaven å vise at kravene er møtt, vil vi ofte føle ansvaret for at kravene er gode. Men hva er gode krav? Og hvordan skal vi forholde oss til «dårlige» krav? Trenger vi egentlig krav?
Levere riktig
Bestillinger inn til utviklingsteamet kommer gjerne i form av behov for en endring eller en nyutvikling, som igjen skal gi en verdi for organisasjonen. Hvordan kravene settes opp og hvordan de styrer utviklingen varierer derimot mye. Uansett er det ofte underforstått at de er ment til å hjelpe oss å utvikle det riktige produktet og kunne levere noe som har nytte. Kravene kan være funksjonelle, som at en bruker skal kunne logge inn, eller de kan være ikke-funksjonelle som at applikasjonen skal være sikker og brukervennlig. I fossefallmetodikk er de gjerne (men ikke nødvendigvis) nøye utmeislet over lang tid og i god tid før en eneste kodelinje er skrevet. I mer smidige tilnærmelser har utviklerne startet å kode uten å vite hva sluttproduktet egentlig blir gjennom løsere definerte user stories. Noen metodikker ønsker å knytte teamet nærmere gjennom dialog om krav som i metodikkene Acceptance Test Driven Development og Behavior-Driven Development. Dermed forholder vi oss ulikt til kravene, og kravene tar mange formater. Kan vi si noe om hva som er et «godt krav»?
Kravene må være …
Spør du en tester hva som er et godt krav, vil du kanskje få svar som at det må være
- forståelig
- testbart
Her kan listen forlenges, og egenskapene med gode krav vil avhenge av situasjonen og konteksten de er i. Ikke minst vil synet på gode krav endre seg med tiden – og ut fra rollen til den som bedømmer dem. En forretningsressurs kan jo være fornøyd med kravene slik de er ved utviklingens start, mens utvikler og tester savner avklaringer og spesifiseringer. Etter hvert som produktet tar form, vil jo også nye krav komme til – og kanskje vil vi måtte endre på de vi hadde tidligere.
Så da kan vi ikke si noe om hva som er gode krav, annet enn at «det avhenger»?
Vel, en artikkel publisert på nettstedet reqexperts.com lister opp fire egenskaper. Kravet
1) løser et reelt behov. Hvis det ikke leveres, så får mangelen konsekvenser.
2) kan verifiseres. Hvordan vet du at det er levert? Noen tenker her akseptansekriterier.
3) er oppnåelig. Det må være teknisk mulig å levere på det, samtidig som tidsplan og budsjett m.m. respekteres.
4) er klart beskrevet. Hold innholdet enkelt og konsist, og unngå at det kan misforstås.
Hvem har ansvaret?
Men hvem har da ansvaret for at kravene er gode? En måte å svare på, er å si at det er kravstiller (f.eks. forretningssiden) som har ansvaret for å sette opp kravene og forvalte dem under utviklingsperioden helt frem til kravstiller selv avsjekker om de er levert på.
Men slik er det ikke alltid i IT-verden. Forretningsressurser har ikke den tekniske innsikten til å forutsi hvilke valg og konsekvensene av dem som kan skje underveis. Likeså er det ikke alltid like lett for utvikler og tester å sette seg inn i forretningens hverdag. I praksis får ofte testleder og testere jobben med å rapportere på om kravene er møtt og hvilke avvik som er funnet. Mangler og feil med kravene blir da tegn på kvaliteten til leveransen, som kan risikere å utsettes eller stanses. Underveis i arbeidet med å sette opp tester dukker det ofte opp spørsmål om hva som egentlig menes med kravet, og dialogen med forretning og utvikler starter. Dermed kan vi vel si at ansvaret ligger hos alle i teamet, selv om noen vil protestere på dette.
Ta det du får!
Testere vet smertelig godt at det ikke er nok å teste basert på kravene.
For det første så kan vi ikke anta at alle kravene er nedskrevet i leveransen. Det kan godt hende det burde vært andre, færre eller flere krav til produktet. Kanskje har vi glemt en brukerkategori? Tok vi høyde for GDPR? Hva med det neste prosjektet som skal bygge videre på denne koden?
For det andre kan endringen gi uforutsette konsekvenser for både den nye leveransen og eksisterende funksjonalitet og kvalitetsegenskaper. Testfokuset da må heller være et helhetlig syn på brukeren, applikasjonen og systemet.
Dermed har vi testere ikke bare kravene, gode som dårlige, å forholde oss til. Vi må vurdere kvaliteten til helheten til leveransen.
