Automatisch testen als automatisch testen niet kan

Stel je hebt nog helemaal geen automatische testen. Je hebt geen tijd om een automatische test op te bouwen. En je hebt nauwelijks kennis van testautomatiseringstools. De belangrijkste functies lijken onmogelijk om te automatiseren, zo moeilijk en/of uitgebreid zijn ze. Of bedenk zelf maar andere redenen waarom testautomatisering bouwen eigenlijk gewoon niet mogelijk is. Er is vaak wel een reden om aan een onmogelijk grote klus als testautomatisering niet eens te beginnen. Zelf denk ik daar toch anders over. Je moet alleen wel bereid zijn om met weinig te beginnen.

Wat je naar mijn mening nodig hebt: minimaal 2 uur per week en de vaardigheid om tevreden te zijn met een heel klein beetje. Maar daarmee, dat weet ik ook wel, kom je niet zonder problemen tot een automatische test. Ik hoop met deze blog wat hulpmiddelen te geven om de moed te vinden te starten.

De voorbereiding

Wat heel verstandig is om voor de testautomatisering te hebben, is een in een document beschreven testscript. Hierin moet goed beschreven zijn wat je wilt invoeren en wat je wil controleren. Zorg ervoor, dat je alleen die testen automatiseert, die op papier beschreven staan. Het is je ontwerp bij de bouw en je documentatie bij later onderhoud. En het is het inwerkmateriaal voor latere overdracht.

Daarna komt, met behulp van de beschreven testscripts, de volgende stap. Deel je testscripts in zo klein mogelijke delen op. Je kan later altijd weer samenvoegen. Als je in een test op Opslaan klikt, heb je een deel wat je los kan automatiseren. Als je op een OK of een Cancel button klikt, vaak ook. En bij wisseling in applicatie heb je al zeker te maken met losse delen. Het idee is, dat een los deel van het testscript geautomatiseerd kan worden en het voorgaande deel en het deel erna eventueel handmatig uitgevoerd kan worden.

Stel je hebt een programma voor urenregistratie. En hiervoor wordt de volgende test uitgevoerd: De medewerker voert zijn uren in. Hierna keurt de leidinggevende de uren af. Vervolgens past de medewerker zijn uren aan. 

Stel nu dat voor de testautomatisering de switch tussen medewerker en leidinggevende niet mogelijk is. Je moet daarvoor namelijk al bij het inloggen op de computer de juiste persoon gekozen hebben. En het inloggen op de computer automatiseren is niet mogelijk. Dan kan je de hele testcase laten vallen, niet mogelijk is niet mogelijk. Of je kan toch besluiten te automatiseren. Want het invoeren van de uren en het aanpassen zijn handelingen, die je als tester veel tijd kosten. Het goedkeuren is slechts een knop indrukken. Dus splits je het testscript in drie delen: het invoeren van de uren en het wijzigen van de uren worden geautomatiseerd gedraaid op computer 1. En het controleren van de uren doe je op computer 2 handmatig tussendoor. Testautomatisering is dan niet meer het doel, maar een middel om sneller te testen. En dat maakt testautomatisering, zoals hopelijk uit het voorbeeld blijkt, een stuk sneller waardevol.

De aanpak

Er zijn in mijn ogen twee manieren om testautomatisering aan te pakken. De beste manier is op basis van risico: je kijkt welke onderdelen het meest belangrijk en/of het meeste kans op fouten hebben. Dit kan dus een volledige testcase zijn, maar ook een onderdeel van een testcase. Het grootste voordeel is: je hebt het snelste resultaat. Maar om dit voor elkaar te krijgen, heb je wel veel kennis van je testautomatiseringstool nodig. De meest belangrijke testcases en de testcases met de meeste kans op fouten zijn helaas vaak ook de moeilijkste om de automatiseren. Dus is deze aanpak alleen geschikt, als je de kennis al hebt of veel tijd hebt om die kennis op te bouwen.

Een minder ideale manier is op basis van moeilijkheidsgraad. Je bouwt eerst de makkelijkste onderdelen en, naarmate je kennis van testautomatisering toeneemt, bouw je de moeilijkere onderdelen. Hier wordt het vaak moeilijk om gemotiveerd te blijven, want wat is het nut nu? Bij deze aanpak ligt het nut dan ook veel meer in tijdsbesparing. Want gelukkig zijn de eenvoudigste testautomatiseringsklussen, vaak ook erg tijdrovend. Iedere tester heeft wel eens voor de zoveelste keer handmatig een heel formulier ingevuld. Of met het oog een heleboel gegevens op een scherm opgevraagd en gecontroleerd. De kans dat je hier als tester een fout maakt, is eigenlijk vrij hoog. Het is eenvoudig werk, maar vraagt toch veel tijd en concentratie. Dus zo onlogisch om te automatiseren is het dan misschien toch niet? Als je hoofddoel maar ligt in de tijdsbesparing en dus niet in de testautomatisering.

Bij de laatste aanpak is het vaak verstandig om te beginnen bij CRUD (create, read, update, delete). Automatiseer het aanmaken van personen, bestellingen, artikelen en/of pas ze aan. Vraag schermen op en controleer of de juiste waardes worden getoond. En automatiseer het verwijderen om de automatische test herhaalbaar te maken. Want eenmaal verwijderd, kan je precies hetzelfde object opnieuw aanmaken. Er is bijna geen applicatie waar deze testen in de een of andere vorm niet voor plaatsvinden. Begin bij invoervelden en knoppen. Ga daarna naar tabellen en los weergegeven teksten. En bepaal daarna welke onderdelen voor jou en jouw automatiseringstool een logische volgende stap zijn.

Durf te beginnen

Wat zo langzamerhand wel duidelijk is: naar mijn mening moet je met testautomatisering gewoon beginnen. Onder alle omstandigheden, desnoods klein en eenvoudig. Maak van testautomatisering niet je doel, maar gebruik de testautomatisering om sneller en beter te testen. Als het automatiseren van een volledig testscript niet mogelijk is, automatiseer dan een deel. Maar dus bovenal: zie de testautomatisering nooit als een enorme klus, die pas zin heeft als je alles meteen helemaal volledig kan automatiseren.