![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.](https://image.slidesharecdn.com/testochcheck-komplexochkomplicerad-130412051207-phpapp02/85/Test-och-check-komplex-och-komplicerad-1-320.jpg)
![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/](https://image.slidesharecdn.com/testochcheck-komplexochkomplicerad-130412051207-phpapp02/85/Test-och-check-komplex-och-komplicerad-4-320.jpg)
Test och check komplex och komplicerad
- 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/