1. Test och Check – Komplex och Komplicerad
James 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.

2. Ä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.

3. 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.
Johan Hoberg

4. Referenser
[1] Testing and Checking Redefined
http://www.satisfice.com/blog/archives/856
[2]Automated vs. Exploratory
http://www.shino.de/2013/03/21/automated-vs-exploratory-we-got-it-wrong/
[3] The Insapience of Anti-Automationism
http://context-driven-testing.com/?p=69
[4] Testing vs. Checking Rephrased
http://www.slideshare.net/JohanHoberg/testing-vs-checking-rephrased/
[5] Komplexitet
http://sv.wikipedia.org/wiki/Komplexitetsteori
Christer Hoberg – Komplexitetsmax
http://kth.diva-portal.org/smash/record.jsf?searchId=1&pid=diva2:10395
Tor Nörretranders – Märk Världen
http://www.bokus.com/bok/9789100570705/mark-varlden/