Problemen bij Scrum en Automatisch testen - Ze bestaan echt

Scrum en automatisch testen worden vaak als perfect koppel gezien. Dus hoeveel problemen kan je tegenkomen, als je deze twee combineert? Een heleboel! Hoe komt dit?

Automatisch testen werkt het beste als deze op de ideale wijze uitgevoerd kan worden. Dit houdt in dat er per Scrum team een stabiele omgeving is, waar op een afgesproken tijd opgeleverd wordt. Deze afgesproken tijd is afgestemd op de automatische testen, zodat de automatische test tegen een voorspelbare applicatie draait. Onderhoud aan de automatische testscripts wordt binnen de teams zelf afgehandeld als onderdeel van de story. Bugs worden opgelost bij het team, waar de bug vastgesteld wordt. De perfecte omgeving. Een perfecte omgeving, die er dus niet altijd is.

Meer Scrum teams is niet altijd meer testomgevingen
De meeste problemen ontstaan als er meerdere Scrum teams in een bedrijf aanwezig zijn. Bij het toevoegen van Scrum teams, zal er niet altijd sprake zijn van het toevoegen van testomgevingen. En zeker niet van testomgevingen, die stabiel genoeg zijn voor een automatische test. Hierdoor zal de automatische test draaien op een omgeving, waarin de code van meer dan 1 team wordt opgeleverd.

Dat maakt analyse noodzakelijk bij het falen van de test. Niet alleen moet worden nagegaan of er echt sprake is van een fout, maar ook moet worden nagegaan welk team deze veroorzaakt heeft. Als je tenminste het streven wilt vasthouden, dat er alles aan gedaan moet worden om de story's met de beste kwaliteit mogelijk op te leveren. Het eindproduct van een sprint moet tenslotte geschikt zijn voor productie. En dat is zeker niet het geval, als je weet dat er nog een fout in zit.

Tijdstip afstemmen op de oplevering
Elke wijziging, die opgeleverd is, moet een keer automatisch getest zijn. In de meest ideale situatie vindt er daarom na elke oplevering van een story een volledige automatische test plaats. Maar als dit (nog) niet mogelijk is, moet er meer afstemming plaats vinden. De automatische test kan als eindcontrole gebruikt worden aan het eind van een sprint. Dit is het meest eenvoudig, maar maakt de afstand tussen oplevering van de story en de automatische test wel erg groot.

Ook kan de automatische test met een vaste, korte frequentie draaien. Maar het heeft geen zin om de automatische test dagelijks te draaien, als je de story's pas 1 keer in de week op een stabiele omgeving neerzet. Deze oplossing kan dus pas als de story's ook minimaal 1 keer per dag opgeleverd worden naar een stabiele omgeving, die geschikt is voor de automatische test.

Onderhoud van de testscripts
Testautomatisering begint vaak als een los project, buiten de bestaande Scrum teams op. Regelmatig vraagt het kennis, die in de teams nog niet beschikbaar zijn. En tijd, die binnen het team niet vrijgemaakt kan worden. Om onderhoud van de testscripts onder te brengen in de Scrum teams is als gevolg daarvan een uitdaging. En zeker op korte termijn met regelmaat (nog) niet haalbaar.

Dit staat dan nog los van de verantwoordelijkheid van de testscripts. Het meest eenvoudig is om een Scrum team verantwoordelijk te maken voor de testscripts, die "hun" applicaties of modules raken. Maar wat als twee Scrum teams werken aan dezelfde applicatie, zelfs aan dezelfde schermen? Beide onderhouden hun eigen wijzigingen? Wie voegt deze wijzigingen dan weer samen en controleert het geheel?

Niet vreemd dat onderhoud van de testscripts bij testautomatisering nog wel eens wordt losgetrokken van de Scrum teams. Maar in dat geval zal je wel afspraken moeten maken over het melden van de benodigde wijzigingen. Hoe weet de testautomatiseerder welke functionaliteit wijzigt? Waar velden worden toegevoegd of gewijzigd? En waar controles worden aangepast?

Toch doen!
Laat deze problemen je er niet van weerhouden om met testautomatisering te starten. Afspraken zijn te maken en problemen zijn op te lossen. Het kan alleen handig zijn om er van tevoren alvast bij stil te staan. Dat maakt de kans op het slagen van testautomatisering alleen maar groter!