Testbaarheid en Automatiseerbaarheid

6 juli 2021 | Okto Wahjuwibowo

De rol van Test Automation Engineer wordt veel gezocht, omdat testautomatisering steeds belangrijker wordt bij het ontwikkelen van software. De hoeveelheid van (test)werk neemt toe door de Agile methoden die breed worden ingezet bij organisaties. De focus van de huidige Agile werkwijze ligt op (test)automatisering. Door korte iteraties bij de Agile manier van werken, is het niet meer haalbaar om bij elke iteratie steeds dezelfde test handmatig uit te voeren.

Geautomatiseerd testen is een automatische uitvoering van specifieke testen. Denk hier aan een aantal regressietesten en het opzetten van testdata sets. Door het automatiseren wordt feedback sneller ontvangen, wordt er minder tijd gespendeerd aan ‘eenvoudig’ herhalende taken en wordt er meer aandacht gebracht aan de risico’s van nieuw toegevoegde functionaliteit. Hierdoor gaat de kwaliteit van het product omhoog.   

In de praktijk zijn er veel obstakels bij het implementeren van testautomatisering. Om deze obstakels te overwinnen, kun je beginnen met het analyseren van je testbaarheid. Daarna kijk je goed naar je automatiseerbaarheid. Op basis van deze twee aspecten maak je een model van het testproces die specifiek betrekking heeft op de applicatie die wordt getest. Het doel is om een manier te vinden om je testproces te ondersteunen door middel van een testtool.

Testbaarheid is het gemak en de snelheid waarmee kenmerken van het systeem (na iedere aanpassing) kunnen worden getest¹. Waarom is de testbaarheid belangrijk²? Het geeft de diepte van je testuitvoering aan, de nauwkeurigheid van het testproces, de onderhoudbaarheid van het testontwerp, de duidelijkheid van testrapportage, de zichtbaarheid van de dekkingsgraad, de snelheid van de feedback en de automatiseerbaarheid.

De testbaarheid moet altijd in een context gegeven worden. Context zijn alle factoren die invloed hebben op de testproblemen en testoplossingen binnen de scope van de testuitvoering. James Bach³ schrijft over de vijf praktische testbaarheden.

1.      Project gerelateerd testbaarheid: wijzigen van de condities van de te testen applicatie. Bijvoorbeeld: door het afstemmen met de ontwikkelaar kan ik mijn test beter opstellen.
2.      Waard gerelateerd testbaarheid: wijzigen van de kwaliteit, standaard of onze kennis van de te testen applicatie. Bijvoorbeeld: de testuitvoering is makkelijker in samenwerking met de gebruiker van de applicatie.
3.      Subjectief testbaarheid: wijzigen van de tester of het test proces. Bijvoorbeeld: na het leren van Javascript is het testen van een webapplicatie makkelijker geworden
4.      Intrinsiek testbaarheid: wijzigen van het product. Bijvoorbeeld: het nieuwe niveau van het log bestand schrijft alles op wat ik doe bij de testuitvoering.
5.      Epistemisch testbaarheid: de afstand tussen wat we weten en wat we moeten weten of de status van de te testen applicatie. Bijvoorbeeld: leven kritische software is moelijker te testen.  

Dus de testbaarheid van het testtraject kan bepaald worden door de externe factoren, het project op zich, de gebruikers of de belanghebbenden, de tester als persoon, het product of de te testen applicatie en de kennis en onbekendheid. De testbaarheid heeft te maken met de menselijke interacties, met andere woorden, de heuristische testuitvoering. Als de tester de applicatie kan testen is in principe de applicatie testbaar.

1. Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon. TMap Next voor resultaatgericht testen (‘s-Hertogenbosch: Uitgeverij Tutein Nothenius, 2006), 275. 
2. Richard Bradshaw & Mark Winteringham, Automation in Testing. V1.2. 2019
3. James Bach, Satisfice, Inc. Heuristics of Software Testability. Version 2.3, 2015 (https://www.satisfice.com/) 

Het analyseren van de automatiseerbaarheid is de volgende stap van de implementatie van testautomatisering. In tegenstelling tot de testbaarheid heeft de automatiseerbaarheid te maken met de interactie van de applicatie. Dat wil zeggen de testscript en de te testen applicatie. Dit script volgt bepaalde stappen en vergelijkt de resultaten tegen de bekende verwachtingen. 

Automatiseerbaarheid is het gemak waarmee bestaande kenmerken van het systeem kunnen geobserveerd, getoetst of gemanipuleerd worden door een testscript. Het testscript ondersteunt de testuitvoering in het algemeen voor herhalende teststappen. Denk hierbij aan het aanmaken van data, het draaien van een aantal SQL scripts, het checken van resultaten.

Een testautomatisering script op de UI van het bovenstaande voorbeeld kan falen op elk punt in elke laag, terwijl het script wil checken of bijvoorbeeld de applicatie een juiste verwerking toepast op basis van een specifieke input. Dit script is minder betrouwbaar omdat veel factoren invloed kunnen hebben op de werking van het script. Het is een goed idee om het testscript te implementeren op de API laag zodat het script gericht is op de te testen functionaliteit.  

Elke stip die te zien is in het proces van de klantrapportage voorbeeld hierboven is een potentiële geautomatiseerde check. Kijk goed naar welk onderdeel van het proces geautomatiseerd kan worden. Bespreek met een collega om de juiste tool/framework te vinden die bij de technologie van de applicatie past. Het doel is om een manier te vinden doe de testuitvoering makkelijker maakt.

We weten nu de testbaarheid en automatiseerbaarheid van onze applicatie. Hoe kunnen we verder met de implementatie van de testautomatisering? 

Maak een logische model met de onderdelen van de te testen applicatie. Richard Bradshaw en Mark Winteringham⁴ geven een model aan als richtlijnen van het maken van geautomatiseerde check: TRIMS – (T)argeted, (R)eliable, (I)nformative, (M)aintainable, (S)peed. Op basis van dit model doe je een controle of je geautomatiseerde check TRIMS is.

Vervolgens voer je een taakanalyse uit op het testproces. Het is een belangrijke activiteit in een testaanpak. De taakanalyse kijkt naar het risico van het systeem wat belangrijker is dan de dekkingsgraad. Beschrijf wat de applicatie doet tot component niveau. Stel vragen aan de ontwikkelaar om informatie te vergaren. Als de tester niet in detail weet wat de software doet, is het niet mogelijk om de automatische check op te bouwen. Denk hier aan de backend unit check, Javascript unit check, data transformatie logica check, enz. 

 Aan de hand van het resultaat van de taakanalyse bepaal je de gerichte checks. Gebruik de technologie die bij de te testen applicatie past, voor bijvoorbeeld het opzetten van de testdata als input, het draaien van de applicatie, en/of het checken van de resultaten. Stel dat in het bovengenoemde voorbeeld de Java technologie wordt gebruikt. Dan zijn er verschillende tools en technieken beschikbaar geschikt voor Java technologie. Denk aan Jmeter, JUnit en Fitnesse die gekozen kunnen worden als testtool om de testuitvoering te ondersteunen. 

Plaats en verbind deze geautomatiseerde checks in je vertrouwde keten van de regressietest. Dit is je testsuite, een collectie van de testscripts die je de testuitvoering ondersteunt. Je kunt ook de testsuite zelf bouwen met Windows scripting of Linux Bash scripting. Daarnaast zijn er diverse open-source frameworks beschikbaar die onder andere Fitnesse framework of Robot framework ondersteunen voor je regressietest suite. Je testsuite moet het juiste component testen, betrouwbaar zijn, belangrijk informatie geven, makkelijk te onderhouden zijn  en snel feedback geven.

De geautomatiseerde test vervangt niet de handmatige test. De testbaarheid van de handmatige test is juist verhoogd door de testautomatisering tool. De automatisch testuitvoering en handmatig testuitvoering moet parallel draaien. Uiteindelijk is de handmatig testuitvoering verbeterd door de automatisch testtool.
 
4. Automation in Testing. V1.2. 2019