B: Buggar och avvikelser

- när är det egentligen ett fel?

Av Charlotta Carlsson 2020-08-20

En ganska jobbig och tidsslukande del av acceptanstestarbete är när det uppstår oenigheter mellan beställare och systemleverantör om vad som ska betraktas som fel och inte. Jag säger "när" och inte "om", för sådana situationer uppstår i stort sett alltid. 

Kort och gott: det ligger i beställarens intresse att de problem man hittar i testerna betraktas som fel som leverantören ska åtgärda inom överenskommen tids- och kostnadsram, medan leverantören i oklara lägen gärna vill hävda att problemet inte är ett fel utan ett nytt önskemål som de behöver extra tid och pengar för att åtgärda. Hur tacklar man det? En del tips finns vid bokstaven A: Avvikelsehantering - en gemensam process. I resten av det här inlägget tänkte jag ägna mig åt problematiken med själva felen som gör att tvisterna uppstår.

En del vänner av ordning brukar hävda att om det inte är solklart i acceptanstesterna vad som är ett fel (avvikelse) och inte så har man gjort ett dåligt kravarbete eller så har man ett otydligt avtal. När denna tes kommer upp så tänker jag (men vågar oftast inte säga rent ut) att vederbörande behöver nyansera och verklighetsförankra sin bild. Krav måste vara tydliga sägs det - men kan de vara kompletta in i minsta detalj? Enligt min erfarenhet är det näst intill en omöjlighet och inte heller önskvärt. För många decennier sedan trodde många att det var möjligt men det har motbevisats tillräckligt många gånger i IT-historien som havererade projekt. Framgångsfaktorn för att träffa rätt med leveransen, och därmed undvika att hitta problem sent i ett projekt, är istället att inom ett visst övergipande scope (högnivåkrav) som avtalats, bedriva utvecklingsarbetet iterativt, med användarmedverkan, där den detaljerade utformningen av produkten kommer successivt. (Läs gärna mer i detta inlägg.)

Andra ytterligheten av vänner av ordning är de som nu hävdar att genom ett väl genomfört utvecklingsarbete med moderna metoder där Kommunikationen ständigt står i centrum så kommer man inte att hamna i några tvister om rätt eller fel. Allt hanteras gemensamt på vägen genom ett agilt förhållningssätt. Behovet av acceptanstest som en särskild aktivitet kan till och med helt falla bort. Dessa åsikter tycker jag ligger närmare sanningen än de kravtydlighetsförespråkande. Ju mer kompetent krav- och utvecklingsarbete, desto färre negativa överraskningar uppstår i acceptanstester och därmed färre felrapporter som man behöver bråka om. MEN: de perfekta solskenshistorierna finns nästan aldrig i verkligheten, inte ens med den bästa av ambition och aldrig så kompetenta medarbetare hos alla parter. Tidspress, underskattade tidsuppskattningar, ändringar i förutsättningarna av olika slag kan ligga bakom, men man får också vara ödmjuk för att det man håller på med kanske faktiskt är komplicerat och ingen kan tänka på precis precis allt, inte ens tillsammans.

Dessa typer av problem kan bli föremål för oenigheter:

1. Användbarhetsproblem som hittas först i acceptanstest
   Under utvecklingsarbetet har du som acceptanstestare förmodligen fått en del demos och skriftliga beskrivningar av funktionen. Men om det är först i acceptanstesten som du fått möjlighet att själv köra systemet, finns det stor risk att det inte stödjer ditt arbetssätt effektivt. Många klick för en enkel åtgärd, viktig information som saknas på viss skärmbild, behov av viss sorteringsordning, svårbegriplig navigering och inkonsekvent namnsättning är några exempel där det kanske inte finns skriftliga exakta krav, utan användbarhetsfokus hade behövts i utvecklingen.
   
   
2. Underförstådda krav
   Som acceptanstestare kan du råka ut för att systemleverantören dissar din felrapport med motiveringen att "det står inte i kraven". Likväl är det som du ser det helt nödvändigt att det åtgärdas för att användarna ska kunna arbeta effektivt. För dig är det så självklart att du inte tänkte på att säga något om det när du ombads dokumentera dina krav. Fiktivt exempel: Kravet som skrevs: Det ska gå att lägga in bilder. Lösningen som utvecklades: Bilderna går att spara och att sedan att titta på på men bara för den användare som lagt in dem. Felrapport: Inlagda bilder ska synas hos alla användare. Leverantören hävdar: Det står inte i kraven.
   
   
3. Ej dokumenterade, endast muntligt uttalade krav
   Fiktivt exempel: Du som acceptanstestare är säker på att du på något av de tidigare mötena med systemleverantören har sagt att knappen x måste tas bort. Nu säger leverantören att detta krav inte står någonstans. Du letar i gamla mötesanteckningar, men hittar det inte. Ord står mot ord, och det kommer troligtvis bli massa problem när dina kollegor efter produktionssättningen kommer att trycka på den riskabla knappen.
   
   
4. Detaljer eller varianter som ej hanterats i skriftliga krav
   Detta liknar nr 2. När du som kravställare dokumenterade dina krav från början var det på en övergripande nivå där verksamhetsbehoven beskrevs men inte den exakta detaljutformningen av systemet. Det är ju helt rätt eftersom lösningen är leverantörens uppgift att ta fram. Men om ni sedan i utvecklingsarbetet inte gått vidare gemensamt med detaljerna utan utvecklarna har "gissat" sig fram (det är sällan så extremt men ändå), så finns det stor risk att leveransen hamnar lite "bredvid" behovet. Fiktivt exempel: Kravet som skrevs: Det ska finnas en övergripande behörighetsstyrning via systemroller. Lösningen som utvecklades: Det går att lägga in behörigheter per roll men olika användargränssnitt använder sig av olika roller så behörigheterna måste läggas upp flera gånger. Felrapport: En och samma roll måste slå igenom i samtliga gränssnitt. (Här har detaljerna kring kravet "övergripande" inte varit detaljerade och hade behövt utredas innan utvecklingen gjordes.) 
   
   
5. "Ickefunktionella" kvalitetsproblem
   Här menar jag allt från instabilitet, prestandaproblem, otillräcklig dokumentation, säkerhet, underhållbarhet, portabilitet osv. I den mån dessa aspekter inte har kravställts tillsammans med konkreta acceptanskriterier blir det lätt en diskussion om vad som är fel och inte.

Däremot den här sortens avvikelser ger sällan upphov till oenigheter:

• Det som avviker från vad som finns otvetydigt beskrivet i krav och avtal. Å andra sidan kommer det sällan sådana felrapporter i acceptanstest eftersom systemleverantörer med stor sannolikhet har läst kraven och systemtestat utifrån dessa.
  
• Rena buggar där systemet t.ex. kraschar eller räknar fel. Men den typen av buggletning hör hemma i komponent- och systemtester och borde inte heller slinka igenom till acceptanstester. Fast det händer.
  

Jag tycker mig ha sett att de flesta felrapporter i vanliga acceptanstester gäller punkt 1-5. Tänk då vilken outnyttjad potential det finns hos acceptanstestarna som kan användas tidigare i projekten istället för att upptäcka problemen i acceptanstesten! Genom att vara medveten om risken att dessa problem kan uppstå kan man motverka dem i utvecklingsarbetet. Här vilar ansvaret tungt på systemleverantörer att driva utvecklingsarbetet med metoder som främjar acceptans under hela resan. Men även beställare har ett ansvar att arbeta kontinuerligt med kraven och att ta fram acceptanskriterier. Om hur det går till får jag skriva en annan gång...

Slutsats för bokstaven B:  Undvik tolkningstvister genom att arbeta med acceptans på andra sätt långt före acceptantesten.