Nu scrum, kanban en agile hoogtij vieren (ik gooi de termen bewust op een hoop), ontstaan er steeds meer inzichten in de impact op testen in deze setting. De kern: ten opzichte van waterval is er niet of nauwelijks verschil in wat je test. Hooguit dat de testobjecten gemiddeld kleiner in omvang zijn. In het hoe en wanneer zijn echter wel duidelijke verschillen te signaleren. Het meest in het oog springende verschil is, dat je als tester in een agile omgeving vrijwel direct na de oplevering van nieuw geschreven code kijkt naar de werking ervan en de impact op bestaande functionaliteit.
In deze blog wil ik stilstaan bij de straat van omgevingen die in een agile traject van toepassing (kunnen) zijn. Daarnaast ga ik in op de vraag wat voor agile de ideale inrichting van het testproces is, rekening houdend met die verschillende omgevingen. Daar tegenover zet ik een ontwikkeling die mij zorgen baart.
De OTAP straat
Een ‘standaard’ straat bestaat uit een ontwikkel-, test-, acceptatie- en productieomgeving (OTAP). Op de O (ontwikkel) omgeving wordt de nieuwe code geschreven. Ontwikkelaars gebruiken de omgeving om te kijken of de nieuwe bak met code technisch en basaal werkt, al dan niet ondersteund door een unit test. Op T (test) controleert de dedicated tester of de nieuwe functionaliteit werkt zoals de business het verwacht. De relatie met andere en bestaande functionaliteiten blijft hier doorgaans achterwege. Daarvoor hebben we de A (acceptatie) omgeving. Daarnaast worden daar de GAT en regressietesten uitgevoerd. Tot slot is er de P (productie of live) omgeving waar in sommige gevallen een productie test plaatsvindt op het moment dat een release plaatsvindt. Het laat zich raden dat dit niet in alle branches kan. Om die reden wordt A zoveel mogelijk productie-like gemaakt en gehouden. Test je succesvol op A dan weet je bijna zeker dat het in het echt ook goed gaat!
Een volledige OTAP straat maakt het je als team en organisatie makkelijk het proces van ontwikkelen en testen richting een release optimaal in te richten. In mijn beleving ziet het agile (test)proces er in de ideale situatie als volgt uit (uitgangspunt is een sprint van twee weken).
Het grote voordeel van deze route is dat een dedicated tester het begin van een sprint meteen zinvol aan de slag kan en daardoor zijn of haar werkzaamheden evenwichtiger zijn verdeeld. Het overzetten en configureren van de nieuwe code van de gehele sprint naar acceptatie is meteen een generale repetitie voor de release naar productie. Ook het plannen van gebruikers acceptatie testen gaat veel makkelijker. Omdat je als tester weet dat je de eerste dagen van de nieuwe sprint de A omgeving exclusief tot jouw beschikking hebt en je precies weet welke functionaliteiten hebt opgeleverd, kan je de afspraken met de acceptanten van te voren plannen.
De kortste route is niet altijd de slimste
Ik weet dat er nog meer varianten denkbaar zijn, maar waar het mij vooral om gaat, is dat na bestudering van dit model er een belangrijk inzicht volgt: als de T uit OTAP wegvalt zijn er veel minder mogelijkheden en is er bovenal veel minder flexibiliteit, in het doordacht testen van nieuwe en aangepaste functionaliteit. En dat is waar het bij agile toch juist om draait. Wat mij om die reden dus de eerder genoemde zorgen baart, is dat bedrijven (meestal puur vanuit bezuinigingsoogpunt) de testomgeving achterwege laten. Stom!
Vanuit bezuinigingsoogpunt de testomgeving achterwege laten. Stom!
Zeker nu teams steeds vaker volgens het DevOps principe werken is de impact van het beheer van een extra omgeving te verwaarlozen. De teamleden kennen de code én de omgevingen immers door en door. Problemen op de ene omgeving zijn bijvoorbeeld vaak door te vertalen naar de anderen. En daardoor snel gefikst. En met steeds meer migraties die naar de cloud verhuizen, zijn ook de harde kosten van het beheer steeds minder een argument om een ‘slimme’ short cut te nemen. Hier is het eeuwige dilemma van innovatie zichtbaar: de wet van de remmende voorsprong. In dit geval: het team werkt en denkt agile, maar de rest kan of wil daar (nog) niet in mee en neemt beslissingen die een rem zijn op de evolutie die agile heet. En dat is volgens mij een pad te dat we echt eens moeten verlaten…
