Hannes Lindblom

Testbarhet - Röj upp innan du dammsuger

2018-10-03 Blogg Test Läst 277 gånger

Tänk dig att du ska städa ett rum. Hur går du tillväga? De flesta jag känner skulle nog börja med att plocka undan alla lösa grejer som ligger på golvet. Det ligger också nära till hands att tända lampan i rummet för att lätt kunna se om det blir rent. Vi kan nog vara överens om att det är betydligt svårare och krångligare att dammsuga ett mörkt, rörigt rum än ett välbelyst undanplockat sådant. Vi kan säga att det senare rummet är mer städbart än det tidigare. Att förbereda dammsugningen på detta vis faller sig ganska naturligt för de flesta av oss, men konstigt nog så är detta inte alls lika självklart när det kommer till test av mjukvara. Den så kallade testbarheten glöms ofta bort, eller blir en eftertanke.

Testbarhet är ett brett begrepp som innefattar många olika aspekter, men sammanfattningsvis handlar det om hur lätt det är att testa ett system (se t.ex. Heuristics of software testability eller Dimensions of software testability, s 31). I detta inlägg tänkte jag dock fokusera på egenskaper hos systemet som testas, det som på engelska kallas intrisic testabillity. Som jag ser det finns det tre huvudkomponenter i detta:

  • Observerbarhet - Hur lätt är det att få ut information ur systemet?
  • Kontrollerbarhet - Hur lätt är det att påverka systemet i den riktning man behöver för testningen?
  • Tillgänglighet - Hur lätt är det att få tillgång till systemet?

Observerbarhet

Vi går tillbaka till dammsugningen och konstaterar att rummet bör vara välbelyst så att vi kan upptäcka dammet. Om den vanliga takbelysningen i rummet inte når in under sängen kanske vi behöver ställa dit en extra golvlampa medan städningen pågår. Det bör inte heller ligga massor av saker på golvet som skymmer sikten eller döljer damm. På samma vis behöver vi när vi testar kunna få återkoppling på vilka effekter våra handlingar mot systemet har. En testare som använder ett webgränssnitt för att registrera en ny kund behöver kunna verifiera att informationen om kunden lagrades korrekt, om det inte finns inbyggt i systemets funktionalitet behöver testaren kanske tillgång till systemets databas. Testaren behöver också lätt kunna inse om något går fel, så tillgång till systemloggar eller andra verktyg bör ligga högt på testarens önskelista. Ett system med många kända problem blir också mer svårtestat då det kan vara svårt att förstå om ett problem beror på ett tidigare känt problem eller är nytt. Vi får mer brus i den information vi försöker tolka.

Kontrollerbarhet

I vårt städexempel kan vi konstatera att det viktigt att kunna komma åt överallt med dammsugaren. Ibland krävs olika munstycken för att kunna attackera olika typer av ytor, eller för att komma åt i alla skrymslen. Ligger det saker i vägen försvåras dessutom arbetet ytterligare. Testare kan behöva använda systemet både på vanliga och ovanliga vis. Ibland går det att använda samma gränssnitt som användarna, men i många fall kan det krävas tillgång till administratörsgränssnitt eller speciallösningar som byggs in av utvecklarna för att kunna täcka relevanta scenarion. Ett system som innehåller massor av kända problem blir dessutom mer svårtestat då dessa problem kan sakta ned eller helt omöjliggöra vissa scenarion.

Tillgänglighet

Det är svårt att dammsuga ett rum som man bara har tillgång till ett fåtal timmar i veckan. Metaforen kanske blir lite långsökt här, men å andra sidan kan jag tänka mig att denna problematik existerar, speciellt för de med barn i tonåren. I testvärlden är detta dock ett väldigt påtagligt problem på många håll. Integrerade testmiljöer är dyra att sätta upp och underhålla och finns därför ofta i begränsad mängd och tillgängligheten blir därför därefter. Att kunna utföra nödvändiga tester utan att vara beroende av en integrerad miljö är dock en av två faktorer som är starkt kopplade till högpresterande team enligt den utmärkta boken Accelerate. Så detta bör verkligen vara ett fokusområde för den som satsar på att kunna leverera effektivare framöver.   

Som jag nämnde i början är testbarhet något som lätt förbises, trots att testbarheten ofta är det bakomliggande svaret på frågan: "Varför tar testningen så lång tid?". Kanske behöver vi som har testperspektivet bli bättre på att jobba för detta? Det är förstås alltid bra att lyfta upp de problem som försvårar testningen, men ännu bättre är att tänka på detta i tidiga skeden, redan innan koden skrivits. “Tänk test tidigt” är en gammal devis som definitivt även bör innefatta testbarhetsaspekten. Har du svårt att övertyga andra i din närhet om relevansen i detta så kan du alltid släppa loss dem med dammsugaren i en mörkt, stökigt rum.

(Att släppa loss en robotdammsugare ställer ännu högre krav på förberedelserna, men mer om detta i ett framtida blogginlägg om automatiserbarhet).

Dela artikeln