Auteur: Johan Vink ● vink.jd@gmail.com
In traditioneel opgezette softwareontwikkelprojecten werken de testers en ontwikkelaars vaak onafhankelijk van elkaar. De ontwikkelaars dragen in deze opzet de door hun ontwikkelde software over aan het testteam. Vervolgens voert het testteam de geplande testen uit. In deze opzet is het dan ook erg belangrijk dat het ontwikkelaars en testers onderling duidelijke afspraken maken. Met name afspraken over de staat waarin de software moet verkeren voordat het testteam zinvol kan gaan testen.
Afspraken in een testplan
Meestal zijn deze afspraken vastgelegd in een testplan. In de meeste testplannen die ik in mijn carrière ben tegengekomen waren deze afspraken vaak erg basaal. Meestal had de testmanager in een paar zinnen aangegeven dat het ontwikkelteam verantwoordelijk was voor het uitvoeren van de unittesten. Daarnaast legde de testmanager in een aantal entry-criteria vast waaraan software moest voldoen voordat het testteam de opgeleverde software accepteerde. Deze exit-criteria waren meestal proces-georiënteerd.
Voorbeelden van dit soort criteria zijn:
- Alle unittesten zijn succesvol uitgevoerd;
- Geen openstaande (test)blokkeerde defects;
- Software is succesvol geïnstalleerd op de testomgeving;
- Het testteam heeft de smoke-testen succesvol uitgevoerd.
Dit had als effect dat het testteam en ontwikkelteam elk binnen hun eigen scope een eigen test(automatisering)aanpak toepasten. Het resultaat is dat het project ondanks de ambitie zoals verwoord in het testplan in werkelijkheid geen integrale testaanpak hanteerde.
Dit resulteerde in de situatie dat:
- teams geen invloed hadden op de dekking van de testen die andere teams uitvoerden;
- teams geen inzicht hadden in de dekking van de testen die andere teams uitvoerden;
- er samenwerking op het gebied van test(automatisering)aanpak ontbrak.
Dit leidde tot de volgende problemen:
- Teams testten belangrijke delen of kwaliteitsaspecten niet, of onnodig dubbel;
- Teams testten risicovolle of belangrijke delen of kwaliteitsaspecten (te) laat in de ontwikkelcyclus;
- Geen synergievoordelen op het gebied van de test(automatisering)aanpak.
Agile teams
Een van de zaken die ik zo prettig vind van het werken in een Agile team is dat bovenstaande problemen nu gemakkelijker op te lossen zijn. We werken nu als één team. Binnen het team hebben we alle test- en ontwikkelvaardigheden aan boord om een integrale testaanpak vorm te geven en uit te voeren. Gedurende backlog refinement sessies en gedurende de sprint planning stellen we de testaanpak op voor de komende sprint. Daarbij bepalen we op welke integratie niveaus we bepaalde tests (geautomatiseerd) gaan uitvoeren. Het mooie is dat ook ieder teamlid zich verantwoordelijk voelt voor deze aanpak.
Test automation pyramid
Een erg handig hulpmiddel bij het bepalen van een concrete integrale test(automatisering)aanpak is de test automation pyramid. De test automation pyramid is een concept dat is geïntroduceerd door Mike Cohn. In 2009 schreef hij hier een blogpost over. De essentie van het concept is dat je veel meer unittests moet hebben dan vanuit de user interface geïnitieerde end-to-end testen.
Later is de Test Automation Pyramid door anderen uitgebreid om ook de relatie te leggen met handmatig uitgevoerde testen. Deze variant kom ik in mijn praktijk het meest tegen. Maar als je een beetje googelt, vind je nog talloze varianten en uitbreidingen van de piramide.
Efficiëntie verbetering
Ongeveer twee jaar geleden hebben wij de Test Automation Pyramid binnen ons bedrijf geïntroduceerd bij een paar teams. Inmiddels is het concept door alle Agile teams geadopteerd.
Het uitgangspunt dat wij binnen onze teams hanteren, is dat we testen zo laag mogelijk in de piramide willen beleggen.
Van het oogpunt van efficiëntie levert dat ons de volgende voordelen op:
- We vinden fouten eerder in de sprint en hebben op die manier ook meer tijd om deze op te lossen.
- Hoe lager het integratie niveau is van de testen die we uitvoeren, hoe sneller de testresultaten te analyseren zijn. Op unittestniveau weet je vrijwel direct wat het probleem is. Voor het vinden van de root cause van een falende end-to-end test zijn we nu soms dagen bezig.
- Testen op lagere integratieniveaus zijn veel sneller uit te voeren dan testen op een hoger integratieniveau. Om je een voorbeeld te geven: voor het uitvoeren van twintig geautomatiseerde End-to-End web testen hebben we ongeveer dertig minuten nodig. Het uitvoeren van meer dan 1000 unittesten kost ons minder dan vijf minuten.
Onderhoud
Maar ook gezien vanuit het perspectief van onderhoud blijkt het gezond te zijn om dit uitgangspunt te hanteren. Unit testen zijn veel gemakkelijker te maken en te onderhouden dan End-to-End web testen. Daarnaast zijn onze End-to-End web testen veel gevoeliger voor storingen. Dit ondanks de investeringen die de teams hebben gedaan om deze testen zo robuust en onderhoudbaar mogelijk te houden.
Dekking controleren
Verder gebruiken we de testen op hogere integratieniveaus als manier om te controleren of de dekking op lagere niveaus wel goed genoeg is. Concreet betekent dat als we de resultaten van een gefaalde test analyseren ons ook afvragen of we de fout niet met een test op een lager niveau hadden kunnen vinden. Vaak resulteert dat dan in het toevoegen of aanpassen van testen op lagere integratieniveaus. Deze manier van werken passen we overigens ook toe op het analyseren van de resultaten van handmatige uitgevoerde testen.
Conclusie
De introductie van de testpiramide binnen ons team en binnen ons bedrijf heeft geresulteerd in een veel efficiëntere en door het hele team gedragen testaanpak. Bij veel teams hangt de testpiramide nu standaard aan de muur. Regelmatig ben ik nu betrokken bij discussies waarbij het hele team meedenkt om tot de meeste efficiënte en effectieve test te komen. De invloed van de testpiramide is daarbij niet gelimiteerd tot de aanpak van testautomatisering. Het concept helpt teams bij het bepalen van de volledige testaanpak.