1. Supporting testing over replicating testing

Het eerste principe stelt dat testautomatisering enkel succesvol is wanneer het (risk-based) softwaretesten ondersteunt. De ondersteuning gaat boven het repliceren van testen. Sterker nog, ondersteuning is zelfs het doel van AiT. Een kernonderdeel van de AiT training bestaat uit oefeningen voor de cursisten om te leren waarderen dat testautomatisering nooit het complete testvak zal overnemen. Zo leer je bijvoorbeeld te communiceren over welke tools wel en welke niet ondersteunend zijn voor testautomatisering. Als je testautomatisering op een juiste manier inzet, dan pas helpt het de softwaretester om sneller, beter en intelligenter te testen.

2. Testability over automatability

De vraag die voorafgaat aan principe nummer twee is: wat heb je nodig om goede testautomatisering te bereiken? Moet het softwareproduct dan testbaar of automatiseerbaar zijn? Daarvoor moeten we terug naar de basis. Als je het product niet succesvol kunt testen, dan wordt het ontzettend lastig om dit te automatiseren. Daarom is het van belang om de testbaarheid van je eigen producten te begrijpen. Als je al rekening kan houden met de testbaarheid vóór de bouw, pluk je daar later ook de vruchten van tijdens eventuele testautomatisering.

3. Testing expertise over coding expertise

Om goede testautomatisering toe te kunnen passen, heb je sterke testexpertise nodig. Zoals vaardigheden op het gebied van risicoanalyse, begrip van de context en de werking van het softwareproduct. Al de genoemde vaardigheden ontwikkel je door de jouw opgedane werkervaring toe te passen binnen de testautomatisering. Naarmate je testexpertise en je kennis van het testobject toeneemt, wordt de testautomatisering vanzelf gemakkelijker. Een goede automatiseerder, maar slechte tester automatiseert namelijk nog steeds slechte tests. Eventueel kun je ondersteuning vragen van developers in je team als je codeerervaring te laag is voor specifieke oplossingen.

4. Problems over tools

Een duivels dilemma: wat doe je als eerste bij het opstarten van de testautomatisering werkzaamheden? Kijk je eerst naar welke tools je gaat gebruiken of breng je eerste de situatie en het vraagstuk in beeld? Principe vier stelt dat je bij het starten van testautomatisering eerst het vraagstuk beoordeelt en helder hebt. Als je de context en het kader van het probleem kent, ben je in staat om de geschikte tool(s) te kiezen. Daarvoor moet je een gevulde toolbox hebben. Bijvoorbeeld: als je alleen een hamer hebt om uit te kiezen, is enkel de spijker jouw oplossing. De situatie bepaald welke tooling je het beste kan gebruiken. Dit kan betekenen dat je een POC of training nodig hebt om het probleem met het team te tackelen. Deze informatie over het vraagstuk is bepalend voor welke tool(s) je uiteindelijk gebruikt. Welke tool dit wordt, is weer bepalend voor het succes van je oplossing. Denk hierbij aan het volgende gezegde: ‘We inform our tools and our tools inform us’. Wanneer je in het begin de verkeerde tool kiest, zal je ook niet tot de juiste oplossing komen.

5. Focusing on risk over coverage

Principe nummer vijf levert vaak discussie op binnen de testwereld en het is daarom een interessante kwestie. Want, om waardevolle testautomatisering te leveren, focus je dan op testdekking of risico mitigatie? Je zou kunnen zeggen: “als ik probeer te focussen op risico migratie, dan probeer ik nog steeds testdekking te realiseren. Maar als ik focus op testdekking dan realiseer ik meestal geen risico mitigatie”. Maar uiteindelijk is het doel om altijd risico boven dekking te stellen en niet om altijd 100% testdekking op codes te krijgen. Meestal is de tijd er simpelweg niet om al het automatiseringswerk uit te voeren. Het streven naar 100% testdekking eindigt in onnodig veel werk. Beter is om je prioriteiten op het gebied van risico’s te stellen en die onderdelen te automatiseren.

6. Observability over understanding

Het laatste principe gaat over het observeren ofwel begrijpen van een systeem. Wat is precies het doel van testautomatisering? Gaat observeerbaarheid boven het begrijpen van een systeem? Het antwoord op deze vraag is: ja. Met observeren wordt bedoeld: het gebruik van tools om je testwerk te ondersteunen. Voornamelijk tools die jouw werk controleren. Zo bouwt Mark Winteringham bijvoorbeeld geautomatiseerde controlepunten in bij specifieke veranderingen in het systeem. Ze geven jou een melding wanneer er daadwerkelijk iets is veranderd. Een mislukte controle is voor jou een uitnodiging om de fout verder te onderzoeken. Het doel is zo goed mogelijke controlepunten te ontwerpen die jou van feedback voorzien .

Interpretatie van de principes

Tot slot is het belangrijk om te weten dat alle genoemde begrippen aan de rechterkant niet per definitie van minder waarde zijn. Maar als we focussen op de begrippen die telkens als eerste worden genoemd, dan zullen de zaken die daarop volgen vanzelf makkelijker worden. Het is dus niet het één of het ander. Uiteindelijk ben je als testprofessional met testautomatisering niet bezig om jezelf overbodig te maken, maar juist om je werk effectiever en efficiënter uit te kunnen voeren. Zodat je bijdrage en impact die je maakt, in je team, zo groot mogelijk is.