Sprint 0 of "Waarom wil je niet alles automatiseren"

Sprint 0, de start van een nieuw project. Voor mij een net afgerond traject. Tot mijn eigen verbazing bestaat de voorbereiding van een nieuw project voor mij vaak uit het beantwoorden van de vraag "Waarom wil je niet alles automatiseren?" Want juist bij Scrum en Agile wil ik niet alle testen automatiseren. Maar het lijkt wel of zo'n uitspraak in tegenspraak is met alles waar Scrum en Agile voor staan.  Heb ik dan echt zo weinig kennis van Agile en Scrum dat ik die verwachting voor testautomatisering nergens terug kan vinden?

Bij de start van een nieuw project is het altijd verstandig om stil te staan bij welke testen je wil automatiseren en welke niet. Performance gaat al snel naar automatisch testen. Testen van vormgeving vaak weer niet. En bij alle testen geldt ook voor mij: bij voorkeur automatisch. Maar dan moet het wel een meerwaarde hebben. Ik blijf er bij: het automatiseren van testen is geen doel, het is een middel om goede software te bouwen en te behouden. Levert het daaraan niet of nauwelijks een bijdrage, dan automatiseer je niet.

Dat is makkelijker geschreven dan bedacht. Want levert testautomatisering niet altijd een bijdrage aan het bouwen van betere software? Nee, naar mijn mening niet. Om een extreem voorbeeld te gebruiken: je kan vijfentwintig keer in een testcase testen of een knop de gebruiker van scherm 1 naar scherm 2 brengt. Maar als dat het enige is wat je test, heeft de test geen meerwaarde. De meerwaarde is er wel als de knop je van een invoerscherm naar een controlescherm brengt, waarin de ingevoerde gegevens opnieuw getoond worden. En elke testcase voor een bepaald invoerveld bijvoorbeeld een minimum of een maximale waarde test.

Dit kunnen de meeste testers zelf wel bedenken. Maar hoe zit het in deze situatie? Stel je hebt al een test, waarin je controleert of de waarde van een veld na de klik op een knop in het volgende scherm goed wordt meegegeven.  Heb je dan de testcase "Als de gegevens correct zijn, wordt na een klik op de knop het controle scherm getoond" nog wel nodig? Als aan deze eis niet voldaan wordt, zal ook het controleren van de waarde falen. Dat maakt de test overbodig. Een reden waarom ik nauwelijks testcases opstel en zeker niet automatiseer, die de navigatie tussen schermen controleren.

En stel nu dat je de vormgeving van een applicatie nog handmatig test. En het genoemde scherm krijgt bijna elke sprint  wel extra velden. Dus bijna elke sprint worden het invoerscherm en het controlescherm bij het handmatig testen van de vormgeving meegenomen. Neem maar rustig van mij aan, dat het niet uitmaakt wie het scherm test. Iedereen zal het laten weten als na een klik op de knop het controlescherm niet verschijnt. Automatisch testen voor de eerder beschreven testcase heeft in die situatie nauwelijks meerwaarde. Die paar keer dat het scherm in een sprint niet wordt aangepast, kan je hem wel handmatig testen.

Toch zijn er situaties waarin dubbel automatiseren wel een meerwaarde heeft. Als al tijdens het programmeren kan worden vastgesteld dat de knop niet meer werkt, kan de programmeur dat direct aanpassen. En dat heeft zeker voordelen. Maar vervolgens kan de knop best wel eens alleen werken in Firefox en niet in IE. Of de knop werkt ten onrechte niet, als het invoerveld "Geboortedatum" is leeg gelaten bij de persoonsgegevens. Vaak omdat de programmeur een foute aanname heeft gemaakt. Een aanname die herhaald is in zijn eigen automatische testen. In alle beschreven gevallen heeft de testcase dubbel automatiseren een meerwaarde. In het ene geval test je nu in een andere "omgeving", namelijk IE. In het andere geval is de automatisering om het werk te laten testen door een persoon die het werk niet gebouwd heeft. Een testprincipe wat ook bij testautomatisering erg belangrijk is.

Met een eenvoudig voorbeeld klinkt het misschien allemaal zo simpel en begrijpelijk. Ik heb in ieder geval mijn best gedaan om het zo begrijpelijk mogelijk op te schrijven. Maar zeker aan de start van een project is het dat niet, de te testen functies zijn zeker niet altijd zo simpel. Probeer het wel. Bedenk welke overlap de testen hebben. Sta stil bij de directe testen, maar ook de indirecte testen, zoals het klikken op knoppen bij het controleren van de vormgeving. Bedenk of het dubbel testen, al of niet automatisch, een duidelijke meerwaarde heeft. En maak je niet teveel zorgen over fouten. Als je te veel of te weinig meeneemt in je automatische test, je project is Agile. En dat betekent dat niet alleen de business, maar ook jij van mening mag veranderen.