Effektivt samarbete mellan krav och test

Fredrik Scheja berättar om “Hur man bäst kan nyttja sig oss av testarens sinne”.

En kravorganisations uppgift är att förstå beställaren och användarens förväntningar på slutprodukten så väl att de kan producera kravspecifikationer. Dessa krav utgör sedan en viktig beståndsdel för andra delar av utvecklingsorganisationen så som arkitekter, utvecklare, testare m.fl.

Problemställningen som jag vill ta upp är varför det är viktigt att samtliga parter som arbetar med slutproduktens utveckling är medveten om att kraven endast utgör en modell, en avspegling av användarens och beställarens förväntningar på produkten. Modellen kan aldrig fullständigt avspegla verkligheten fullständigt.

Det kommer alltid att finnas förväntningar på produkten som vi inte tagit med i våra kravspecifikationer och för att visualisera detta brukar jag tänka på en klassificering av krav som jag lånat från Ulf Ericsson i hans bok ”Test och kvalitetssäkring av IT-system” där han tar upp en trestegsmodell.

Normala (eller dokumenterade) krav – Dessa krav är de krav som på något vis dokumenteras och lämnas vidare för utveckling av organisationen. Det är dessa krav som sålunda kommer att bli designade, utvecklade och testade.

Förväntade krav – Dessa krav är svårare att komma åt initialt. Det är krav som beställaren och slutanvändaren tagit för givet och således inte kunnat kommunicera ut som ett tydligt krav på produkten. Det kan vara en bild av ett trevligt användargränssnitt eller en sådan sak som prestandakrav, som användaren bara förväntar sig att produkten ska klara av i slutändan.

Sensationella krav (eller wow-funktionalitet) – Denna kategori av krav är bland de svåraste att definiera. Dessa krav är inte beställaren eller användaren medvetna om att de vill ha förrän de har fått känna på det. Det kräver alltså en hel del innovation av utvecklingsorganisationen och dessutom krävs en god förmåga att sätta sig in i produktens användningsområde och olika situationer som kan uppstå för slutanvändaren.

Ett exempel vi kan ta är den hypotetiska utvecklingen av ett nytt flygledarsystem. Det finns rigorösa krav på flygledarsystem, som är väldokumenterade. Detta är de normala kraven. Men flygledare som arbetat länge i branschen kan vara vana vid att viss funktionalitet ”bara ska finnas” såsom vissa snabbkommandon, genvägar och hjälpfunktioner genom systemet eller liknande. Det kan då vara väldigt svårt för en kravinsamlare att få svar på frågor likt ’Vad är det för krav du har på systemet som du inte berättat för mig sedan innan?’. Ett sätt att komma åt dessa krav är en kombination av kravinsamlingstekniker såsom djupintervjuer och att sitta bredvid en flygledare i tjänst. Dessa kravinsamlingstekniker är dessutom användbara när det gäller att se om det går att finna några sensationella krav vi kan implementera i det nya systemet. Här prövas innovationsförmågan och uppfinningsrikedomen hos organisationen som ska utveckla det nya systemet.

Varför är det viktigt att samtliga som jobbar med utveckling av system är medvetna om denna klassificering av krav? Jo, det är väldigt lätt att under utvecklingens gång tappa bort överblicken kring att kraven endast är en modell över de verkliga förväntningarna hos produkten. Glöms detta bort blir de normala kraven snabbt ett facit som alla arbetar mot, men slutkunden behöver inte bli nöjd för det. Ponera att flygledaren ständigt kommer jobba med fem radarskärmar uppe samtidigt, men att produkten endast kan visa en i taget med bibehållen god prestanda i skärmuppdateringsfrekvens. Detta medför i slutändan att produkten anses fullständigt värdelös och en onödig konflikt uppstår. Hade istället en testare varit medveten om hur produkten används i en skarp situation hade detta kunnat uppmärksammas och åtgärdas i ett tidigare skede. Men detta kommer endast att fungera om samtliga roller i utvecklingsorganisationen känner till varför detta är viktigt. En utvecklare eller en projektledare kan lätt skjuta ner en risk eller ett orosmoment som en testare lyfter upp med ett ’Ja, men det står inte i kraven’, eller ’Ja, men det kommer en användare aldrig att göra, höhö’. Mitt standardsvar i sådana diskussioner är något jag lärt mig från James Bach (www.satisfice.com): ’Nej, antagligen inte en användare som tänker som du har föreställt dig’. Tänk på att en konkurrent eller illvillig hackare kan utnyttja svagheterna i produkten så att det blir en säkerhetsrisk eller publicitetsskandal.

Hur kan då krav- och testorganisationen hjälpas åt att täppa till de flesta hålen i kravmodellen, så att den blir tillräckligt överensstämmande med de verkiga förväntningarna? De viktigaste tillfällena under en produkts utveckling som dessa grupper bör samarbeta anser jag vara vid en kravgranskning i början av produktutvecklingen samt vid felrapporteringen under utvecklingens gång projektet. Men om det är möjligt, försök att hålla en kontinuerlig kontakt under hela produktlivscykeln.

Vid kravgranskningen bör testarens fokus ligga på att försöka hitta de krav som kan förväntas, men inte dokumenterats. I likhet med en professionell kravställare har en professionell testare en stor mängd personlig erfarenhet och en verktygslåda med checklistor att utgå ifrån, såsom olika typer av krav: funktionella, prestanda, datasäkerhet, osv. Testaren bör titta på kravspecifikationen med den utgångspunkten att kravspecifikationen inte är fullständig och leta efter det som kan tänkas saknas. Dessutom hör det till testarens uppgift att själv sätta sig ner och utföra en riskanalys av vad dessa brister kan medföra. Alltför ofta ser jag kravgranskningsprotokoll där granskarna endast påpekat brister i sidnumreringar, marginalavstånd, felstavningar osv. Dessa granskningsaktiviteter medför i slutändan inte en bättre slutprodukt och en nöjdare kund, och således blir hela idén med en kritisk granskning av kraven förkastade. Men om en kravgranskning görs rätt blir istället aktiviteten till ett stöd för kravställaren när han eller hon ska bestämma vilka krav som bör läggas till och vilka som borde tas upp i diskussion med kunden. Alla krav kommer aldrig att kunna dokumenteras, hela arbetet bör utgå från målet att dokumentera tillräckligt många krav utifrån den situationen och kontext organisationen befinner sig i för tillfället. Att bygga en fullständig och felfri kravspecifikation är lika omöjligt som att bygga en felfri produkt.

Under testningens gång när produkten börjar utvecklas kommer situationer uppstå där testaren hittar testfall som produkten inte klarar av att utföra, men som inte utgör ett regelrätt brott mot kravspecifikationen. Det är då upp till kravorganisationen att ta upp dessa och utföra en riskanalys på dessa. Gör detta produkten oanvändbar? Riskerar slutanvändaren att förlora viktig användardata? Sådana frågor bör vägas in i arbetet för att sedan utgöra beslutsunderlaget kring om detta bör medföra en ändring i kravspecifikationerna eller inte. Om testorganisationen även utför användartester med riktiga slutanvändare blir denna process ännu viktigare.

Oavsett vilken arbetsprocess organisationen jobbar efter när de utvecklar denna produkt kan detta tankesätt appliceras, oavsett om processen kallas SCRUM, RUP, eller XP. Det är viktigt att kravorganisationen är öppen för förändringar och inte motarbetar arbetet för en bättre slutprodukt för risken ökar då markant att användaren eller beställaren inte blir nöjd i slutändan. Detta är en av hörnstenarna i agila utvecklingsprocesser, där förändringar är en del av det naturliga flödet. (Responding to change over following a plan, http://www.agilemanifesto.org/)