Binnen de wereld van Agile en Scrum wordt het testonderwerp vaak besproken. Men is op zoek naar dé manier van testen. Je moet vooral exploritory testing toepassen. Of nee, je moet testen vooral automatiseren. En als je automatiseert, moet je vooral BDD toepassen. Of TDD. Welke manier van testen moeten we nu gaan toepassen bij Agile of bij Scrum? Wat is de beste methode en kunnen we aan de toekomstige testers gaan leren? Maar bij mij komt eerder deze vraag op: waarom voeren we deze discussie eigenlijk?
De discussie is al ouder en werd al gevoerd voordat Agile gemeengoed werd. TMap was een grote winnaar, maar toch waren er regelmatig groepen die opriepen om die methode vooral niet te volgen. Automatisch testen kwam meer in, waardoor het handmatig testen steeds meer in twijfel werd getrokken. Was het wel nodig? Moest je het wel willen? Dat deze discussie zich daarom bij Agile herhaalde, is dan ook niet vreemd. Er kwam wel een nieuw element bij. Waar vorige discussies vooral door testexperts onderling werden gevoerd, kwam er nu een nieuwe groep bij: de Agile experts. Een groep die zeker niet alleen uit testexperts bestaat.
Het kan echt geen kwaad om de gebruikte testmethodes en -technieken af en toe is ter discussie te stellen. Om erover te praten en weer opnieuw de voor- en nadelen vast te stellen. In het kader van Agile is het zelfs handig om je af te vragen hoe een bepaalde methode of techniek met Agile gecombineerd kan worden. Het wordt gevaarlijk als men Agile en Scrum als argumenten gaat gebruiken om bepaalde manieren van testen af te keuren. Als mensen beweren dat je testen wel moet automatiseren, omdat je anders niet goed genoeg kan inspelen op de steeds opnieuw veranderende applicatie tijdens een sprint. En als je dan toch handmatig test, moet het exploritory testing zijn, andere methodes zijn niet flexibel genoeg en vragen teveel papierwerk. Als wordt beweerd, dat je op BDD over moet gaan, omdat dit de enige methode is waarmee je de business bij het testen kan betrekken. Als mensen beweren dat je juist TDD moet toepassen, omdat zo programmeurs al kunnen testen, wat de multidisciplinaire karakter van een team versterkt. Wat hier het gevaar van is? Men kijkt niet meer naar de nadelen van deze methodes.
Exploritory testing is een methode die moeilijk te leren is. Als je hem goed wil toepassen, heb je echt iemand nodig die het je leert. Veel mensen die beweren deze methode toe te passen, doen eigenlijk gewoon maar wat. Bij een team waar flexibiliteit verwacht wordt, is een methode met een lange leercurve een nadeel. Je kan niet zomaar iemand bijschakelen. Daarnaast hangt de kwaliteit zeer sterk van de ervaring af. De tester bepaalt zelf de strategie en die is niet bij iedere tester van dezelfde kwaliteit. Veel testers zijn ook juist bij deze methode niet in staat om ervoor te zorgen dat bij vakantie of ziekte het werk zomaar door een ander overgenomen kan worden. Want hoe leg je de uit te voeren exploritory testen vast? En hoe leg je het hertesten vast? Deze nadelen heeft een ouderwets testscript niet. Een testscript uitvoeren is eenvoudig te leren en kan ook goed overgenomen worden tijdens ziekte of vakantie. Het kost wel wat meer voorbereiding, maar daarna kan iedereen binnen je team meetesten. En bijna iedere tester weet hoe je er een schrijft.
Geautomatiseerd testen heeft ongeveer dezelfde nadelen. Ik heb zelf regelmatig geprobeerd om geautomatiseerde testen over te dragen en meestal is het niet gelukt. Alleen als de testen zijn geschreven in de taal van de ontwikkelaar met de tools van de ontwikkelaar is overdracht echt realistisch. De leercurve voor automatisch testen is ook nog eens veel groter dan bij exploritory testing, omdat mensen vaak eerst moeten leren programmeren in een taal en/of een testtool moeten leren gebruiken, voor de ook maar 1 test kunnen schrijven. Daarnaast is ook de voorbereidingstijd voor een goede automatische test enorm groot. De test is misschien zo geprogrammeerd (3 x zo lang als een handmatige test?). Maar herhaalbaarheid van de test en gebruik van goede testdata is vaak een probleem. De terugverdientijd is soms vrij lang. Terwijl juist door de snelle wijzigingen in een applicatie een test soms maar 3 x kan draaien, voordat hij opnieuw aangepast moet worden. Of misschien zelfs in zijn geheel weggegooid kan worden. Handmatig testen vraagt, zeker bij exploritory testing, veel minder voorbereiding en onderhoud. En is daardoor makkelijk aan te passen aan veranderingen in de software.
TDD en BDD zijn beide technieken die eenvoudig klinken, maar moeilijk zijn. TDD goed toepassen vraagt veel van programmeurs, daarom gebruiken vele een lichtere variant van TDD. Bijvoorbeeld eerst een aantal testen schrijven, daarna programmeren i.p.v. één test schrijven en dan programmeren. Wat de voordelen van TDD weer vermindert. Daarnaast worden er heel, heel veel testen geschreven. Dit vraagt veel onderhoud. De kleinste aanpassing gooit je testen al omver. Ook is TDD erg gericht op de kwaliteit van de code van een klein onderdeel van je applicatie. Kleine, eenvoudige testen. Testen waarbij gekeken wordt of module 1 ook goed samenwerkt met module 2 worden meestal niet geschreven. Zeker niet als de onderdelen in verschillende programmeertalen zijn geschreven. Of bij verschillende bedrijven zijn ontwikkeld. Het test daarom vaak niet voldoende om vast te stellen of je applicatie in zijn geheel geschikt is voor productie. Ouderwetse functionele testen zijn juist gericht op de gehele applicatie en staan veel meer los van een bepaald onderdeel. Een ervaren tester weet ook het aantal testcases beperkt te houden, zonder daarmee minder te testen.
BDD is ook al een methode waarbij de programmeurs vaak een light variant nemen. Hoewel de methode business-eisen als basis verwacht, worden die business-eisen regelmatig niet door de business ingebracht. Ergens ook logisch. Je maakt je zo afhankelijk van mensen die niet in je team zitten. En deze afhankelijkheid wil je eigenlijk zo min mogelijk hebben. Maar als de eisen niet van de business afkomen, heeft het dan nog veel meerwaarde? Daarnaast hebben deze testen vaak een lage dekkingsgraad. De business is niet opgeleid om tot een goed dekkende testcase set te komen. En de ontwikkelaars vaak ook niet. Nu BDD vaak gebruikt wordt om testers niet of minder nodig te hebben, is hun ervaring op dit gebied vaak afwezig. Wat is het dan een voordeel als je functionele test op meer gebaseerd is dan de business-eisen, waarbij door een tester goed is gekeken naar de dekkingsgraad.
Wil ik nu naar een Agile of Scrum wereld waarin al deze technieken niet gebruikt worden? Nee, natuurlijk niet. Wat ik wil is dat we stoppen met het verheerlijken van een bepaalde manier van testen. Zeker in Agile en Scrum. Agile vraagt een flexibiliteit van een tester, waarbij je kan inspelen op veranderingen in de applicatie, in je team, in de organisatie, in het ontwikkelproces. En naar mijn mening vraagt dit om de vaardigheid om de juiste keuzes uit je testgereedschappen te kunnen maken. Daarvoor moet je de voor- en nadelen van elke manier van testen heel goed kennen. En de voor- en nadelen die elke methode heeft binnen Agile en/of Scrum. Zodat je elk moment opnieuw kan besluiten of jouw team voor jullie situatie op de juiste manier test. Zowel Agile of Scrum schrijven tenslotte bewust niet voor hoe je moet testen of programmeren of documenteren. Welk testtool geschikt is, welke programmeertaal het beste is of welke template je aan moet houden voor het opschrijven van een story. Omdat beseft werd dat dit per situatie anders kan zijn. Wanneer gaan alle Agile (test)experts dat nu ook beseffen?
