Blogserie geautomatiseerd testen deel 4: wanneer wel, wanneer niet?
In aflevering 3 hebben we alle, maar dan ook alle, voor- en nadelen van geautomatiseerd testen op een rijtje gezet. Om eerlijk te zijn: in de eerste versie ontbraken er nog een paar maar dankzij de kritische blik van enkele lezers is die lijst nu echt compleet. In aflevering 1 had ik beloofd om nu op de testpiramide in te gaan, maar eerst nog even iets anders. Al doende en denkende kwam ik er namelijk achter dat het ook nodig is om gevoel te hebben voor situaties die zich lenen voor geautomatiseerd testen en situaties die zich daar minder goed voor lenen. Ik hoop (en verwacht) dat het wat toevoegt!
Alles automatiseren, moet je dat willen?
Moeten we alle testen automatiseren? Het antwoord is: nee, dat moet je niet willen. Geautomatiseerd testen is niet de ‘silver bullet’ voor elke situatie. In de test piramide die we in de volgende aflevering gaan behandelen heeft ‘handmatig testen’ niet voor niets een vaste plaats. Dat heeft te maken met de menselijke factor, zowel bij testers als bij de gebruikers waarvoor je het allemaal doet. En zoals altijd met een kosten/baten afweging natuurlijk.
Critical thinking
Ten eerste is en blijft testen een creatief proces omdat het bijna per definitie gaat over uitzonderingssituaties die niet of minder goed zijn gedocumenteerd en waar eerder niet goed genoeg over is nagedacht. James Bach en Michael Bolton hameren er terecht op: de beste test ideeën ontstaan door ‘critical thinking’ door mensen van vlees en bloed, tijdens handmatige testuitvoering. Het zogenaamde ‘exploratief testen’, is de aanpak die de voorkeur krijgt bij het testen van nieuwe functionaliteit in agile teams. Dat is het echte testwerk, in tegenstelling tot het automatiseerbare ‘checken’.
Nieuw wordt oud
Als we de unit- en integratietesten (test first, TDD) even buiten beschouwing laten, dan zien we dat kritisch nadenken vooral terug in de exploratieve ‘progressietesten’ van nieuwe functies door onafhankelijke testers (zie de figuur). Die doen dat creatief, exploratief en handmatig. Je denkt wel vooraf na en bereidt zogenaamde ‘session sheets’ met missies of ‘test charters’ voor, maar de detaillering ontstaat voor een groot deel exploratief, tijdens testuitvoering. Dit is scheppend, handmatig werk en vrijwel niet te automatiseren. Bovendien is de focus tijdens de sprint op maximale ‘velocity’ en minimale overhead en documentatie.
Als je dat proces eenmaal een keer hebt doorlopen dan moeten dezelfde testen wellicht regelmatig herhaald worden in het kader van regressietesten. Pas dan komt geautomatiseerd testen om de hoek kijken.
Draagvlak en betrokkenheid: IKIWISI
Naast ‘critical thinking’ is er een tweede reden waarom je niet alles wilt automatiseren: het hands-on testen van een nieuw systeem is enorm waardevol voor draagvlak, kennisdeling, betrokkenheid en training van de gebruikers. De gebruikers leveren de bevestiging dat het systeem inderdaad ‘fit-for-purpose’ is: werkt het voor mij? Al doende leren ze het systeem kennen en komen er zelfs aanvullende requirements boven water. Dat is niet erg, want ook dat is een onderdeel van het acceptatietest vangnet: I Know It When I See It (IKWISI). Dit is belangrijke meerwaarde van handmatig testen én levert weer input voor nieuwe geautomatiseerde testen.
Kosten/Baten
Ten derde zijn er genoeg situaties waarin de kosten van geautomatiseerd testen niet opwegen tegen de baten. Hier komen we later nog op terug met de business case van geautomatiseerd testen.
Wanneer wel en wanneer niet?
Aanvullend op bovenstaande zijn er ook meer inhoudelijke en technische overwegingen voor wel of niet automatiseren: wat in de ene situatie wel werkt, werkt in de andere situatie niet. In de Valori SmarTEST praktijk hebben we in de loop van de jaren veel ervaring opgedaan met wat wel en wat niet werkt. Dat heb ik verrijkt met de fraaie Gartner analyse ‘The Eight Essentials When Moving to Automated Software Testing’. Het leverde een tabel met een aantal kwalitatieve overwegingen voor wel of niet automatiseren.
Wanneer/wat wel automatiseren? | Wanneer/wat wellicht niet automatiseren? |
|---|---|
Als testen vaak herhaald worden in het kader van nieuwe sprints en releases | Bij minder dan 2x per jaar testen (eigen praktijkervaring) of als het te testen systeem binnenkort wordt uitgefaseerd. |
Als het testobject redelijk stabiel is (geldt vooral voor regressietesten). | Als het testobject nog sterk in ontwikkeling is en bestaande functies voortdurend wijzigen. Het voortdurend moeten aanpassen van de scripts wordt dan misschien te arbeidsintensief. |
Als handmatige testuitvoering tijdrovend en foutgevoelig is. Als er geen GUI is, als handmatig meten niet precies genoeg kan*. | Bij simpele testen die eenvoudig en snel handmatig uitgevoerd en beoordeeld kunnen worden |
Als de gebruikers er geen moeite mee hebben dat ze niet meer zelf ‘aan de knoppen zitten’. | Als de gebruikers persoonlijk de acceptatietesten willen doen, ook voor draagvlak en opleiding |
Als de testen voorspelbaar zijn en consistent dezelfde uitkomst moeten geven. | Bij onvoorspelbaar gedrag, geen goede specs of uitkomsten die een genuanceerd menselijk oordeel of ingrijpen vereisen. |
Bij legacy systemen die worden ‘vernieuwbouwd’ of een nieuwe schil krijgen. | Bij einde levensduur applicaties |
Als de applicatie voldoet aan standaarden, gangbare (web)interfaces en protocollen | Als de applicatie geen gestandaardiseerde GUI of API-interfaces heeft en dus moeilijk ‘herkend’ wordt door de test tools. |
Als de nadruk ligt op functionaliteit, gebruikersinteractie en performance | Voor non-functional kwaliteitsaspecten als gebruiksvriendelijkheid, vormgeving, leerbaarheid en aanpasbaarheid. Die laten zich minder makkelijk geautomatiseerd testen. |
Als externe interfaces beschikbaar of makkelijk te simuleren zijn (stubs, drivers, service virtualisatie) | Als externe interfaces niet beschikbaar, niet stabiel en niet eenvoudig te simuleren zijn. |
Als de applicatie veel functionaliteit heeft en de testuitvoering arbeidsintensief is | Als de applicatie beperkte functionaliteit heeft en de nadruk op de data ligt. In dat geval ligt de uitdaging bij slimme vergelijkingssoftware en niet bij handelingen via de GUI automatiseren. |
Voor administratieve systemen, ook rondom embedded software en IoT. | Geautomatiseerd testen van de echte embedded en IoT functies kan wel, maar niet met generieke tooling. Dit vergt specifieke tools. |
* Voorbeeld: realtime en embedded systemen, het meten van transactietijden of het interveniëren in transacties die je niet kunt timen als tester.
Tot zover voor deze keer. Ik hoop dat ook dit waardevolle inzichten biedt bij het kiezen van je geautomatiseerde teststrategie en bij het vermijden van reeds door anderen verkende valkuilen. Ook deze keer geldt: reageer vooral als je nog wat mist, dan vul ik de tabel aan.
Volgende keer: wat de test automation piramide ons vertelt en waarom het zo’n handig plaatje is.