Als tester opkomen voor de testability: hoe dan?

De eerste keer dat ik iemand de automatiseringstool Selenium zag gebruiken, dacht ik het zeker te weten: Selenium gaat al mijn test-ergernissen oplossen. Al die kleine handmatige regressietesten, no more! Ik ga ze allemaal automatiseren.

Geïnspireerd door wat ik had gezien, startte ik de Selenium plug-in voor Firefox. Ik klikte de menu’s open, ging naar een subsectie van de site en begon enthousiast met het invullen van het formulier dat ik moest testen. Na een kwartiertje een mooie test gemaakt te hebben, drukte ik vol verwachting op de play-knop. En er gebeurde… niets! Huh? Dat was het moment dat ik tegen een van de grootste belemmeringen van automatisch testen aanliep, te vangen onder de term testability.

Testability
Testability, of toetsbaarheid, is een eis dat er een verwachting is van een resultaat van een hypothese of theorie die gecontroleerd kan worden (1). Dit is bij softwaretesten zeer belangrijk. Denk hierbij aan testabillity van requirements en acceptatiecriteria. Maar er komt een tweede betekenis van testability om de hoek kijken, namelijk de mate waarin een softwareproduct het testen ondersteunt. Het is een niet-meetbare eigenschap die belangrijk is voor het proces. En hoe lager de testability, hoe waarschijnlijker het is dat er onderdelen of requirements onvoldoende getest kunnen worden.

The devil’s advocate
Testability is dus een belangrijk onderwerp. Het is iets waarmee het hele team rekening moet houden; tijdens het ontwerp van de software, de ontwikkeling én deployment. Als testers zijn wij bij uitstek advocaten van de duivel op het gebied van testabillity.

Wat betreft testbaarheid zijn er verschillende aspecten te onderscheiden (2):
• Manipuleerbaarheid: in hoeverre kan ik als tester de software manipuleren? Kan ik bijvoorbeeld zelf users, gebruikers of klanten toevoegen? Kan ik bepaalde eigenschappen gebruiken die mijn tests interessant maken? Kan ik een bericht manipuleren dat normaal gesproken vanaf een ander systeem komt? Kan ik de stekker eruit trekken en kijken wat er gebeurt? Of de tijd vooruit- of terugzetten en zo de effecten daarvan over langere tijd zien?
• Controleerbaarheid: kan ik de resultaten van mijn tests zelf controleren? Kan ik in de logging of database kijken hoe een actie verwerkt wordt? Kan ik zelf resultaten, zoals brieven of e-mails, creëren, zodat ik zie wat de output is van een testgeval?
• Isoleerbaarheid: ben ik voldoende in staat om onderdelen van de software op zichzelf staand te testen, zodat het duidelijk is wat ik precies heb getest? Of zijn de onderdelen zo verweven dat onduidelijk is waar een bevinding vandaan kan komen?
• Separation of Concerns: een term uit de softwareontwikkeling die ook voor ons testers belangrijk is. Het gaat om de mate waarin een softwarecomponent één duidelijke en afgebakende taak heeft. Dit betekent bij het testen dat je niet allerlei ongerelateerde tests hoeft uit te voeren, en dat een bevinding op één plek niet allerlei onverwachte consequenties kan hebben.
• Begrijpbaarheid: in hoeverre kan documentatie of de helderheid van ontwerpen bijdragen om het proces te begrijpen? Wat doet de software, hoe doet de software dit en wat zou de uitkomst moeten zijn? Dit helpt ons met het ontwerpen van tests (denk aan het vinden van grenswaarden, unhappy flows en het inleven in de gebruiker).
• Automatiseerbaarheid: zijn testen met het systeem te automatiseren? Kan ik bijvoorbeeld op een webpagina alle elementen aanspreken, omdat ze een naam of id hebben? En blijft deze ook hetzelfde tussen verschillende sessies? Is de software betrouwbaar genoeg om te automatiseren (voorkomen van flaky tests)? Als ik een set aan controles kan automatiseren, blijft er meer tijd over voor handmatige tests die meer de diepte in gaan.
• Heterogeniteit: hoe heterogeen is de verzameling aan gebruikte technologieën? Hoeveel testtools en -technieken moet ik gebruiken om het geheel te testen? Denk bijvoorbeeld aan een product met een web-front-end, dat gebruikmaakt van API’s om te communiceren met een database. Dit kan al betekenen dat ik drie tools en drie technieken nodig heb om het geheel te testen.

Als goed over deze aspecten wordt nagedacht tijdens het ontwerpen en ontwikkelen van software, zorgt dit ervoor dat ik de minder standaard testcases kan uitvoeren. Ik kan dan namelijk makkelijker standaard testcases automatiseren en precies daar testen waar het nodig is. Dit is belangrijk, want het gaat hier om situaties die niet vaak voorkomen, maar als ze gebeuren wel voor grote problemen kunnen zorgen. Het is zonde als deze niet getest worden omdat ze “lang duren”, “niet te testen zijn” of “toch niet gebeuren”. Daarnaast zorgt het goed toepassen van de aspecten ervoor dat ik minder afhankelijk ben van de ontwikkelaars, beheerders en aangrenzende systemen voor mijn tests, waardoor ik sneller kan werken.

Bijkomende voordelen
Deze aspecten zijn niet alleen goed voor de testability van een product. Enkele aspecten zijn ook standaard aspecten van goed programmeren en zorgen in het algemeen voor een beter product. Producten die goed te automatiseren zijn, bijvoorbeeld webapplicaties met consistent gebruikte id’s, namen en labels zijn ook beter toegankelijk voor mensen met een visuele beperking die spraaksoftware gebruiken.

Als softwaretesters is het onze taak om tijdens het hele proces de testability in de gaten te houden. Zo maken we ons eigen werk makkelijker en kunnen we al vroeg in het proces de kwaliteit vergroten.

(1) Michael Leezenberg en Gerard de Vries, Wetenschapsfilosofie voor geesteswetenschappen (Amsterdam: AUP, 2007).
(2) De lijst met aspecten is geïnspireerd op de lijst in het Wikipedia artikel “Software Testability”, bezocht op 8 mei 2017.

Deze blog verscheen eerder op www.centric.eu/craft
Sara Raap-van Bussel is werkzaam bij Centric en actief als Craft Expert.