Moet ik elke test automatiseren?

Een van de meest gestelde vragen in QA. Het antwoord is nee, en juist omdat we fan zijn van automatisering weten we waarom.

Het is de vraag die op elke QA-afdeling terugkomt, meestal in een sprintplanning, meestal met een zucht erachter. En het eerlijke antwoord verrast mensen: nee, je moet niet elke test automatiseren.

Dat klinkt vreemd uit de mond van een bedrijf dat leeft van testautomatisatie. Maar juist omdat we ermee werken, weten we waar de grens ligt. Een team dat alles probeert te automatiseren, eindigt met een suite die niemand nog onderhoudt.

Wat automatisering wél doet

Automatisering is briljant in het herhaalbare. Een regressietest die elke sprint hetzelfde pad aflegt, dezelfde stappen zet, dezelfde uitkomst verwacht: laat een machine dat doen. Die wordt niet moe, slaat geen stap over, en klaagt niet als het de tweehonderdste keer is.

• Repetitieve regressietests die elke release opnieuw moeten
• Performance- en loadtests
• API-validaties op grote schaal
• Kritieke flows die simpelweg nooit mogen breken

Wat een script niet kan

Hier wordt het interessant. Er is een categorie testwerk waar automatisering structureel tekortschiet, en dat heeft niets te maken met technische beperkingen. Het gaat om oordeelsvermogen.

Een script controleert of de knop werkt. Het merkt niet op dat de knop op een rare plek staat. Het controleert of het formulier verzendt. Het merkt niet op dat de foutmelding onbegrijpelijk is voor een gebruiker die haast heeft.

• Menselijk oordeel: beoordelen of een nieuwe feature logisch en bruikbaar aanvoelt
• Intuïtie: dat gevoel dat er iets niet klopt, nog voor je kunt zeggen wat
• Exploratory testing: ontdekken wat je niet wist dat je moest testen
• Gebruikerservaring: werkt het, versus voelt het goed

De verkeerde vraag

"Moet ik elke test automatiseren?" is eigenlijk de verkeerde vraag. De betere vraag is: welke test hoort waar?

Wij zien in de praktijk dat teams die deze afweging bewust maken, betere suites bouwen. Niet grotere, betere. Ze automatiseren wat vaak draait en stabiel is, en ze houden de menselijke aandacht over voor waar die het meeste oplevert: de nieuwe feature, het onverwachte scenario, de vraag of dit eigenlijk wel een goed idee is.

Dat is geen compromis. Dat is de bedoeling.

Hoe je het in de praktijk aanpakt

Stel bij elke test twee vragen. Hoe vaak draait deze, en hoe stabiel is wat hij test? Draait hij elke sprint en verandert het onderliggende zelden: automatiseren. Draait hij eenmalig bij een nieuwe feature waarvan het ontwerp nog volop verandert: manueel, en pas automatiseren als het stabiel is.

Kijk daarnaast naar de onderhoudskost. Een geautomatiseerde test die voortdurend moet worden aangepast, levert vaak minder op dan ze kost.

Het principe is eenvoudig. De juiste afweging maken blijkt in de praktijk vaak moeilijker.