Het effectief inzetten van geautomatiseerd testen vraagt om een weloverwogen strategie. Een van de grootste fouten die organisaties kunnen maken is om gewoon te starten met geautomatiseerd testen zonder eerst een goede teststrategie te ontwikkelen. Vaak wordt afgegaan op expertise van consultants met een bepaalde testtool en beginnen vervolgens met het automatiseren van de User Interface (UI) testen. En dat is meestal niet de meest efficiënte en effectieve plaats om met geautomatiseerd testen te beginnen.

Het testautomatisering piramide model, ontwikkeld door Mike Cohn, geeft houvast bij het bepalen van een testautomatisering strategie.

De testautomatisering piramide kent 3 lagen:

• Unit test als onderste laag
• API, Integratie- en component tests als middelste laag
• UI testen als bovenste laag

Het uitgangspunt is dat er zoveel mogelijk inspanning plaatsvindt bij Unit testen, gevolgd door API / integratietesten en als laatste UI testen.

Veel organisaties die beginnen met geautomatiseerd testen starten bij het automatiseren van de UI testen en besteden veel minder tijd aan Unit testen. Er ontstaat dan eigenlijk een omgekeerde piramide. In deze situatie is het van belang om stappen te ondernemen om de piramide om te keren. Een stappenplan hiervoor staat beschreven in “omkeren van de testautomatisering piramide”.

In dit artikel gaan we in op de verschillende lagen van de piramide.

Geautomatiseerde User Interface (UI) testen

UI testen zijn met name gericht op het end-to-end testen van een applicatie. Geautomatiseerde UI testen zijn echter vaak erg langzaam. Daarnaast kost het wijzigen van deze testen als gevolg van wijzigingen in de interface veel tijd.

De UI testen moeten tot het minimum worden beperkt en alleen worden gebruikt om vast te stellen of de gebruikersinterface correct is en niet om de business logica te testen. Het testen van de business logica is namelijk al gedaan tijdens de unittest en/of API- / integratietesten.

Geautomatiseerde API, Integratie- en component tests

Net als bij UI testen, wordt bij integratietesten de connectiviteit en functionaliteit getest. Het verschil is dat er bij integratietesten geen gebruik gemaakt wordt van de User Interface om de testscripts uit te voeren. En daardoor zijn deze testen sneller en minder onderhoudsgevoelig. De communicatie vindt plaats via de beschikbare API’s of services.

Wanneer de testuitvoering niet plaatsvindt via de UI, kunnen de testscripts gebruik maken van input en output die gespecificeerd zijn in bijvoorbeeld een excel spreadsheet.

Geautomatiseerde unit testen

Deze testen vormen de basis van de testautomatisering piramide en vormen het grootste onderdeel. Een unittest richt zich op het testen van een kleine hoeveelheid onafhankelijke code. Er mogen dus geen afhankelijkheden zijn met iets anders. De reden hiervoor is dat wanneer er iets fout gaat, je direct weet in welk stuk code het probleem zit.

De test piramide gaat er van uit dat er meer unittests moeten zijn. De gedachte hierachter is dat ze sneller en daardoor goedkoper gemaakt kunnen worden. En ze zijn makkelijker te onderhouden.

Het nadeel is dat ze niet alle fouten zullen kunnen vinden. Sommige fouten zullen zich namelijk alleen voordoen door connectiviteits problemen tussen meerdere componenten. Dit zorgt ervoor dat integratie- en UI-testen nog steeds van belang zijn.

En hoeft er dan niet meer handmatig getest te worden?

De hiervoor beschreven geautomatiseerde testen zorgen ervoor dat kan worden vastgesteld dat de ontwikkelde software werkt conform de specificaties. Echter is het niet alleen nodig om aan te tonen dat de software goed werkt. Samen met business experts zal moeten worden vastgesteld dat de software ook de juiste functionaliteit biedt en dat de software gemakkelijk te gebruiken is. Er blijft dus handmatig testwerk over om de processen en gebruikersvriendelijkheid te kunnen beoordelen.