Auteur: Kees Blokland ● kees.blokland@polteq.com
Sinds een maand of acht werk ik bij het Kadaster aan het testen van een nieuw registratiesysteem van rechten op en rond onroerende zaken. We hebben het dan over eigendom, erfpacht, hypotheken, beslagen, mandeligheden (google die zelf maar even) en nog een stuk of wat andere zogenaamde rechtsfeiten. Mijn e-mail-handtekening vermeldt ‘Testmanager’ onder welke titel ik een veelheid aan testwerkzaamheden uitvoer. Naar de organisatie stel ik me vooral op als bewaker van de testpiramide. Waar komt dat op neer?
Scrum-teams
Vier ontwikkelteams bouwen in tweewekelijkse sprints aan het systeem dat Koers heet. De continuous delivery pipeline levert meer dan 150 keer per sprint een nieuwe versie op van de software. Vaak dus tien keer op een dag. De teams zijn verantwoordelijk voor de testdekking van hun component. Koppeltests dekken de interactie tussen de componenten af. Maar wie doet de Koers systeemtest precies, van begin tot eind?
Testteam
Samen met twee (binnenkort drie als de performancetester begint) collega’s vorm ik het testteam. Dat er eigenlijk niet zou moeten zijn, want Scrum-teams worden geacht een werkend product increment op te leveren, dus volledig getest en wel. Het testteam richt zich op de volgende taken:
- Het ‘van stuk naar stand’ testen van Koers: dit is het testen van begin tot eind van het systeem, gericht op de zogeheten rechtsfeiten;
- Het automatiseren van een representatieve regressietestset hiervoor;
- Het organiseren van uitgebreidere tests door materiedeskundigen;
- Experimenten uitvoeren waaruit blijkt dat de prestaties op orde zijn (performance);
- De ketentest met aanpalende systemen.
Testpiramide
Aan de hand van de vorm van een piramide leggen we als testers uit dat het uitgebreid automatiseren van systeemtests met een erg hoge dekking, terwijl de geautomatiseerde testdekking op component- en unitniveau zwak is, tot problemen leidt, zoals:
- Nieuwe bugs komen laat aan de oppervlakte.
- Feedback-lus van de systeemtest is lang van duur en daarmee inefficiënt.
- Nieuwe bugs die diep in de code zitten worden slecht gevonden.
Wat voor de geautomatiseerde tests geldt, is ook waar voor andere, niet geautomatiseerde tests. Onvoldoende testdekking in de basis van de testpiramide (die lijkt dan meer op een ijshoorntje…) levert soortgelijke problemen op.
Hamvraag
Dan nu de hamvraag: hoe gaat dat in mijn project? Best oké eigenlijk. De meeste van onze tests verlopen goed. De meeste problemen die we vinden, laten zich vaak op componentniveau lastiger vangen, terwijl ze zich op systeemniveau gemakkelijker openbaren. De materiedeskundigen hebben daardoor genoeg tijd om te onderzoeken of het systeem in de praktijk ook zo kan werken, zonder te veel afgeleid te worden door bugs. De stapeling van de testdekking heeft de vorm van piramide.
Bewaking
Ondertussen bewaak ik de testpiramide ‘met harde hand’:
De geautomatiseerde tests worden in de pipeline opgenomen, waarmee de teams een belangrijke verantwoordelijkheid krijgen voor het voorkomen van regressie waardoor de systeemtest in de pipeline faalt.
- We ondersteunen de teams uiteraard bij het oplossen van problemen in de systeemtest in de pipeline.
- We stimuleren de ontwikkeling van voldoende koppeltests.
- We weigeren om de systeemtestdekking zwaarder aan te zetten dan nodig: het topje van de piramide moet smal blijven ten opzichte van de basis.
- Voor een gevonden bug maken we niet automatisch een extra systeemtest: dat moet op component- of unitniveau gebeuren.
Ook voor performancetest
Voor het testen van performance volgen we dezelfde aanpak: voordat we de performance van het systeem gaan meten, willen we dat de teams het gedrag van hun component goed begrijpen: waar zitten de kwetsbaarheden, waar kunnen we problemen verwachten als we de performancedruk opvoeren, waar zitten mogelijke bottlenecks?
Indicator
Het gemak waarmee je een bug vindt in een testactiviteit boven in de testpiramide is een indicator van de juiste verhoudingen in de testdekking. Als we veel problemen zouden vinden, dan zou systeemtesten veel langzamer verlopen en de materiedeskundigen zouden erg gefrustreerd raken van de vele manco’s in het systeem.
Wanneer het fout zit
De voortgangsgrafiek hieronder van de ketentest van een project liet na zes weken proberen slechts enkele succesvolle tests zien (het groene streepje). De tests onder de ketentest in de testpiramide van dit project detecteerden kennelijk onvoldoende dat er nog veel manco’s in het systeem zaten en dat opstarten van de ketentest weinig zin zou hebben. Vervolgens kwamen er veel bugs uit de ketentest, die in een te lange, inefficiënte feedbackloop binnen het project werden rondgepompt.
