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!

Test op "veel gebruikt" of test op "risicovol"?

Een van de grootste uitdagingen van een tester is: wat test je wel en wat test je niet? Zeker als de tijd om te testen beperkter is. De basiskeuze hiervoor is, naar mijn ervaring, de volgende: test je vooral datgene wat veelgebruikt is of test je datgene wat het grootste risico heeft om fout te gaan?

Het verschil

Maar wat maakt het eigenlijk uit welke keuze je maakt? Komt beiden niet grotendeels op hetzelfde neer?

Stel je hebt een personeelsadministratie applicatie bij een bedrijf waar de meeste personeelsleden tussen de 20 en de 30 zijn. En ongeveer 75% is man. Het bedrijf ligt dicht bij de grens met Duitsland, maar de meeste werknemers wonen in Nederland. Dit bedrijf geeft personeelsleden boven de 50 twee extra vakantiedagen.

De gegevens, die waarschijnlijk het meest ingevoerd worden, zijn die van een man tussen de 20 en 30, die woont in Nederland. Alleen: man is de standaard waarde bij het invoeren van nieuwe werknemers. En datzelfde geldt voor de landkeuze "Nederland". Zelfs als er een fout zit in het opslaan van de gegevens (als je het geslacht of land wijzigt, wordt deze niet opgeslagen), zal je deze niet testen. De standaard waarde wordt vaak toch wel opgeslagen. Daarnaast is de kans zeer groot dat de ontwikkelaar al getest heeft met de waarde "Man" en de waarde "Nederland". Dat is tenslotte de meest eenvoudige invoer. En vergeet niet de extra situatie: het kan ook zeker interessant zijn om te kijken of die twee extra dagen toegevoegd worden.

De keuze

Stel, je hebt maar tijd voor 1 testcase. Kies je dan de man tussen de 20 en 30, die woont in Nederland? Of kies je de vrouw boven de 50, die woont in Duitsland? De tweede heeft een veel groter risico om fouten te vinden: in de opslag, in het tonen van het adres en in het berekenen van de vakantiedagen. En je test bijna alle functionaliteit, die de eerste testcase ook zou testen, uitgezonderd de berekening van het aantal vakantiedagen. Dus je test meer en de kans is groter dat je fouten vind. In mijn ogen geen moeilijke keuze.

In de praktijk heb je gelukkig wel meer tijd dan 1 testcase. En de keuze is niet altijd zo simpel, als hierboven beschreven. Om het risico te bepalen, moet je weten welke functionaliteit geraakt wordt en bij welke criteria uitzonderingen van toepassing zijn. Daarnaast kan het handig zijn om te weten waar in het verleden veel fouten zijn gevonden. Dit is echter informatie, die je niet altijd tot je beschikking hebt.

En laat ik volledig en eerlijk blijven: de veelgebruikte optie heeft ook voordelen. Je test of de applicatie voor de meeste werknemers goed zal werken. En niet of de applicatie goed werkt voor een kleinere uitzonderingsgroep.

Over het algemeen is het verstandig beide groepen aandacht te geven in je test. Test de meestgebruikte situaties. Maar kijk ook, voor zover mogelijk, naar de uitzonderingen

Wijk af van de standaard waardes

Met twee testcases kan deze voorwaarde vaak al afgedekt zijn. Veel tijd is dus niet nodig.

Test business rules uitgebreider

Als er business rules bekend zijn, test dan verschillende mogelijkheden van een business rule. De verschillende mogelijkheden kan je, als je moet kiezen, weer afwegen op basis van hoeveelheid gebruik of verschil in uitkomst van de businessrule. Om de tweede afwegingsoptie iets te verduidelijken: als je denkt aan het bovenstaande voorbeeld, dan heb je de invoer "onder de 50" en "50 jaar en ouder" voor de uitkomsten "Standaard vakantiedagen" en "Standaard vakantiedagen + 2". Een werknemer van 20 jaar en 30 jaar zullen dan ook precies dezelfde functionaliteit testen. Een werknemer van 20 jaar en 60 jaar niet.

Vraag naar fouten in het verleden

Veel ontwikkelaars, functioneel ontwerpers, business analisten en andere bijdragers aan de applicatie hebben al veel bugs langs zien komen. Ze kunnen je dan ook waarschijnlijk wel vertellen wat voor soort fouten zich in het verleden in dit onderdeel, in soortgelijke onderdelen of in de applicatie in het algemeen hebben voorgedaan. Andere testers in je bedrijf hebben mogelijk ook informatie hierover. Dit is, hoe kort je tijd ook is, belangrijk om mee te nemen in je test.

De collectie testcases

Verdeel je testtijd tussen "Veel gebruikt" en "Risicovol". Een 50%-50% verdeling tussen deze twee is zeker geen onverstandige keuze. En besef dat, zelfs bij beperkte kennis, testen op "Risicovol" wel degelijk tot de mogelijkheden behoort. Test dus op beide, hoe beperkt je tijd ook is.

Als testen meer is dan testen

Deze blog is ooit mede ontstaan als een kijk op een wereld, die vaak wordt ontkent. De testwereld, waarin niet alles perfect geregeld is qua geld, tijd, proces, mensen en/of middelen.. Een wereld, waarin je als tester een keuze hebt: je laat jouw testen bepalen door jouw testwereld of je laat jouw testen steeds opnieuw jouw testwereld uitdagen om te veranderen. Uitleggen welke keuze ik heb gemaakt, is denk ik niet nodig. Maar waar loop je dan tegenaan? Waar ben ik tegenaan gelopen?

Een rol groter dan tester

In de eerste plaats kom je als tester in een andere rol terecht, dan mensen van je verwachten. Je wil als tester steeds meer en beter kunnen testen. Misschien zelfs wel de kwaliteit in het algemeen verbeteren. En daarom ga je over zaken praten, die eigenlijk jouw taak niet zijn. Je wil niet alleen een goed testscript, je wil ook goede specificaties. Je wil nieuwe tools en/of omgevingen, waardoor praten met managers van belang wordt. Je wilt dat de processen goed lopen, omdat betere processen vaak ook leiden tot een beter product. Soms wordt dit gewaardeerd. Soms niet, want het zijn jouw zaken niet. Soms is er vooral ongeloof: wat weet jij als tester nu van deze zaken af? Als je werkelijk sterk in je schoenen staat, is het antwoord: ik kom op voor de kwaliteit van het product. En dat is waar ik als tester ook ervaring in heb. Dus ik kan meer, dan jij misschien denk.

Oplossingen uit "de ideale wereld"

Als er een probleem is, wordt er vaak gekeken naar succesverhalen van anderen. Dan vallen er woorden als: Testautomatisering, Scrum, Outsourcing. Er wordt verteld hoe fantastisch dit geholpen heeft. Dit zijn natuurlijk absoluut geen woorden waar ik tegen ben. Ze kunnen in veel situaties een oplossing bieden. Maar ik merk, dat ik me als tester juist tegen dit soort oplossingen sterk moet verzetten. Niet omdat ik een tegenstander ben van de oplossing op zich. Maar omdat men vaak niet bereid en/of niet in staat is om op een realistische manier te kijken naar de obstakels in de huidige organisatie. Heel veel testautomatiseringprojecten falen, omdat men wel de tijd heeft om de testen te maken, maar niet om ze te onderhouden. Als tester helpt Scrum vaak niet, omdat puur deze invoering er niet opeens voor zorgt, dat ontwikkelaars bereid zijn mee te helpen met testen. En dat terwijl je er juist bij Scrum als tester vaker alleen voor staat. Outsourcing van testen kan een heleboel bugs opleveren, maar bij een houding "we kunnen/moeten onze tijd niet aan dit soort bugs besteden", kan het werkelijke effect van deze testen erg klein zijn. Het is dan soms ook moeilijk om een evenwicht te vinden tussen iemand die open staat voor verandering en iemand die kritisch naar oplossingen kijkt.

Vriend en vijand tegelijkertijd

Als je je evenwicht weet te vinden, ben je vriend en vijand tegelijkertijd. Mensen waarderen je inzet, de bugs die je vindt, de problemen die je aankaart, de verbeteringen die je voorstelt. Maar tegelijkertijd wil men het eigenlijk niet horen. Want als de testwereld niet perfect is, zijn er vaak meer problemen. En extra zaken waar tijd naar toe moet, wil men eigenlijk liever niet. Als het je lukt je positie goed neer te zetten, zal je waardering en aandacht vinden. Maar, al of niet humoristisch bedoeld, opmerkingen als: "Oh je, daar heb je hem/haar weer" zal je zeker ook horen. En als je het evenwicht nog niet gevonden hebt, kan het vijand deel ook nog eens de boventoon gaan voeren. Meer zijn dan puur alleen tester is niet altijd makkelijk. Maar als het je lukt, heb je er, ondanks de regelmatige gevoelens van onwil, toch al snel heel veel vrienden bij.