Test och Check – Komplex och Komplicerad

checkingJames Bach och Michael Bolton har tillsammans precis skrivit en artikel om testning och checkning [1], där de utvecklar definitionerna av och distinktionen mellan de två termerna. Flera i den svenska testgemenskapen har varit delaktiga i processen och hjälpt James Bach att hamra ut definitionen ytterligare på SWET 5.

Även andra kända testare har skrivit kring begreppen den senaste tiden. Marcus Gärtner skrev en artikel som diskuterade behovet av både automatisering och utforskande testning och hur de kompletterar varandra. Hur automatisering kodifierar det vi redan vet och hur utforskande testning lär oss nya saker.[2]

Marcus artikel fick mig att fundera över hur testning och checkning kan kopplas till specifikationen eller kraven och hur all testning mer och mer detaljerar specifikationen genom att utforska okända scenarion och dokumentera hur produkten beter sig, medan checkning mer konfirmerar att specifikationen stämmer [4]. Egentligen bara en omformulering av Marcus tankar.

I denna diskussion är det så klart alltid viktigt att ha Cem Kaners ord i bakhuvudet [3]. Det handlar inte om automatisering och dess värde. Alla borde vara överens om att automatisering är önskvärt när det är effektivt och att skriva automatiska testfall är lika mycket test, och kräver lika stor förståelse för test, som någonting annat. Testning och checkning handlar inte om automatisering mot utforskande testning. Båda har sitt värde i olika sammanhang och båda kräver en extensiv kunskap inom test.

Frågan är om det finns ytterligare sätt att formulera skillnaden mellan testning och checkning. Inte som en alternativ definition, utan som en kompletterande eller omformulerad definition, som kanske i vissa fall kan vara användbar.  Detta är mitt försök till en sådan definition, som kanske har något värde för någon – åtminstone för mig själv.

Orden komplex och komplicerad har olika innebörd [5]. Ett magnifikt urverk är väldigt komplicerat, men också väldigt förutsägbart. Varje insignal, varje tillstånd, och varje utsignal är känd. Luffarschack kan också vara komplicerat, men med lite erfarenhet av spelet kan man implementera strategier som gör att man åtminstone aldrig kan förlora. Varje drag är förutsägbart.

Även fullständigt slumpmässiga händelseförlopp är förutsägbara. De är förutsägbart slumpmässiga.

När någonting är förutsägbart så kan det antingen uppföra sig som det borde göra, eller ha ett felaktigt beteende. Då finns det goda möjligheter att skriva ner och exekvera ett automatiskt testfall, eller ett skriptat manuellt testfall, som säkrar att beteendet följer prediktionerna. Detta är vad jag definierar som en check.

En människa, till skillnad från ett urverk, är långt ifrån förutsägbar. Insignaler är oklara, tillstånden dunkla, och utsignalerna överraskande. Människan är en komplex varelse. Detsamma gäller tyvärr för många av de system som vi jobbar med idag. En mobiltelefon med sina miljoner rader kod, interagerande subsystem, komplicerade hårdvaruplattformar, mängder av kopplingar till omgivningen, oklara beroenden, integrerad kod från tredje part, och så vidare, blir också omöjlig att förutsäga. Ett komplext system, om än inte lika komplext som en människa.

I vissa fall kan man avgränsa sitt testobjekt från den omliggande osäkerheten i systemet. Om man bara kör ett detaljerat komplicerat testfall steg för steg utan att bry sig om vad som händer runt omkring, så har man utfört en check. Det samma gäller om man exekverar ett redan skapat automatiskt testfall. Man bryr sig inte om komplexiteten runt omkring, utan följer ett icke-komplext scenario som man exekverar. Man väljer att begränsa systemet man betraktar till någonting icke-komplext och förutsägbart. Det har definitivt sitt värde, men någon gång måste man ta sig an systemets komplexitet. Det är när man gör detta som man utför tester.

Det kan vara när man noggrant designar automatiska tester för att nå insikt i hur systemet reagerar på dem, det kan vara när man exekverar utforskande tester för att kartlägga systemets komplexitet, eller när man kör ett skriptat testfall utan att begränsa sig till de teststeg som finns, utan låter systemets komplexitet skölja över en.

Man kan kombinera användandet av checker och tester genom att t.ex. först använda sig av ett set med checker för att identifiera vilka områden som inte möter grundläggande förväntningar, för att sen övergå till tester för att kartlägga komplexiteten och systemets beteende.

Slutsats

Så vad leder resonemanget ovan mig till?

Check – Systemet på vilket aktiviteten utförs, är enkelt eller komplicerat, men förutsägbart

Test – Systemet på vilket aktiviteten utförs är komplext och oförutsägbart

Ofta utförs dock tester och checker på samma komplexa system. För att kunna göra en check måste man därför då medvetet begränsa den del av systemet man betraktar, och inte ta hänsyn till många av de variabler och utfall som gör systemet så komplext.

Hoppas detta resonemang har väckt några tankar hos läsaren, som i sin tur kanske genererar ytterligare en kompletterande definition av testning och checkning som jag kan se fram emot att läsa.

About Johan Hoberg

Johan Hoberg är en testspecialist på Sony Mobile som driver förbättringsarbete och utbildningssatsningar, samt är involverad som projektarkitekt i olika telefonprojekt. Han tycker om allt som har med test att göra - utforskande testning, testautomatisering, testledning, kompetensutveckling, testinnovation, teststrategi, osv. Just nu driver han två projekt inom testautomatisering och testinnovation. På sin fritid uppskattar han att läsa fackliteratur inom en mängd olika områden; historia, psykologi, filosofi, ekonomi, teknik, etc.. Han har även svart bälte i judo och ett livslångt intresse för kampsport. Han pluggade elektroteknik och nationalekonomi i Lund med fokus på datorgrafik respektive offshore outsourcing.