Door: Gerben de la Rambelje
Auteur: Fred Steenbergen ● suzefred@gmail.com
Als tester ben ik momenteel werkzaam bij een groot bedrijf waar Agile gewerkt wordt. Steeds vaker valt nu het buzzword ‘DevOps’ en dit lijkt dan ook de volgende logische stap, waardoor ik me daar ook eens even in wil gaan verdiepen om te kijken of het iets voor mij is en wat ik als tester in dit proces kan betekenen. Het kwam dan ook mooi uit dat de thema-avond van TestNet van 17 januari over ‘DevOps & Testautomatisering’ ging.
De presentatie van Peter Nijenhuis ging over DevOps en dan met name de vraag wat het is en wat er nodig is om goed te kunnen DevOpsen.
In een mooie mix van ervaringen, tips en trucs en discussies met het publiek kregen we een beeld van wat het is en laat ik maar meteen met het einde beginnen; ja, het is ook iets voor mij, als tester.
Eens kijken wat ik van de kennis mee kan nemen in mijn dagelijkse werk en de verbetertrajecten die we aan het doorlopen zijn.
Agile versus DevOps
Eén van de grootste verschillen die ik langs zie komen tussen het werken als tester in een Agile omgeving of DevOps zit verwoord in de quote van Werner Vogels (CTO van Amazon), ‘You build it, you run it!’. Op mijn huidige opdracht is het eigenlijk uit onze handen zodra het naar productie gaat. Ondanks dat ik werk in een Agile omgeving is er nog een figuurlijke muur tussen Dev en Ops. Verder ervaar ik de pijn van bevindingen in productie niet echt, hooguit als er ‘user stories’ op de backlog komen of in de sprint getrokken worden, ten koste van wat anders.
Het volgende verschil dat langskomt is de snelheid. Werken wij nog in sprints van twee weken en kijken we lachend naar de bedrijven die misschien eens per half jaar een release hebben, zo worden wij juist bekeken door DevOps. Twee weken, dat is een eeuwigheid! Sowieso heb je het bij DevOps niet meer over een start en een einde van een sprint, het gaat continu door. Desnoods met 100+ opleveringen per dag.
Meer mogelijkheden van DevOps voor mijn huidige werkomgeving
Ik zie in DevOps een aantal mogelijkheden, zeker omdat ik een persoon ben die continu wil verbeteren. De problemen waar wij in ons werk tegenaan lopen, komen zo te horen niet voor in de ideale wereld van DevOps. Wat nou als wij ook een soort pilot zouden starten om richting DevOps te gaan? Wat de uitkomst ook zou zijn, we zouden er sowieso profijt van hebben. Bijvoorbeeld op het gebied van de handmatige regressietest. Elke twee weken moet deze weer opgepakt worden en is een groot deel van het personeel daar mee bezig, om zeker te weten dat we met vertrouwen naar productie kunnen. Omdat we nu releasen per twee weken is een dag handmatige regressietest nog wel te doen, maar als je elke dag, of misschien wel vaker, een release hebt, dan is dat geen optie meer. Dan blijft die test dus achterwege. Maar dat kan dus alleen bij een alternatief waar je vertrouwen in hebt. Ik besluit daar eens even verder over na te denken en dit mee te nemen naar mijn opdracht.
Daarnaast hang ik maar weer eens een spreuk aan de muur:
‘Continuous improvement is better than delayed perfection’.
Stop even met lezen en ga nog even terug naar die spreuk, lees hem nog een keer en laat hem even goed op je inwerken.
Ik denk dat hier de kern ligt, maar niet alleen voor mijn verhaal maar voor zoveel zaken in je werk. Hoe vaak heb je geen dingen die je maar niet eens oppakt omdat je weet dat wat je gaat doen nog niet perfect is? Stop met denken. Doe wat!
Doe iets en ga ervan uit dat je fouten maakt, omarm je fouten zelfs want juist dat zijn de momenten dat je kan leren en kan verbeteren. Zorg er dus ook voor dat je je fouten snel opmerkt. Monitor dus goed en handel op je fouten. En vertel ook anderen wat je doet, deel je succes, organiseer brainstormsessies, maar stel jezelf ook kwetsbaar op en geef aan waar je hulp nodig hebt. Continuous improvement…
Wat je zoal moet doen om van Agile naar DevOps te gaan
Toch een kanttekening hierbij. Je ambitie om te verbeteren zal echter ook effect hebben op je velocity. Twee keer zelfs. In eerste instantie zal het een dip in de velocity teweegbrengen. Dit is natuurlijk en niet erg, maar het houdt wel in dat je commitment moet hebben, en dat er een gemeenschappelijk sense of urgency nodig is om iedereen achter je te hebben staan om te kunnen verbeteren. Daarnaast zal je afspraken moeten maken hoe je één en ander gaat aanpakken. Bijvoorbeeld door een tweede backlog te maken en daar de DevOps-zaken op te zetten en die dan ook op te pakken, bijvoorbeeld voor 25% van de tijd? Zorg er vooral voor dat dit getrokken wordt door iemand, die er op gebrand is om die verbeteringen door te voeren, iemand die stevig in zijn schoenen staat, die kan enthousiasmeren, iemand die het leuk vindt om bij wijze van spreken op een fruitkistje te gaan staan (of misschien wel letterlijk?!) en zijn verhaal te doen. Zorg voor een veilige plek waarin dit alles geprobeerd kan worden, zorg dat dit vertrouwen ook uitgesproken wordt. Zorg verder voor een cultuur waarin niet op de vingers getikt wordt bij het maken van fouten. Bij dit alles moet rekening gehouden worden met het simpele feit dat ‘Vertrouwen te voet komt, maar te paard vertrekt’.
En natuurlijk zullen er mensen zijn die niet willen veranderen. ‘het gaat toch goed zo, never change a winning team, laat het lekker zo!’. Ga met deze personen in gesprek. Vraag hen gewoon waar ze bang voor zijn, wat is de angst om te veranderen?
Begin klein. Met een klein team, ontdek je de beren op de weg, en kun je die dus oplossen. En dan snel door naar de volgende stap. Het is allemaal ervaring die gebruikt kan worden bij de andere teams die gaan volgen. En de velocity die zal je snel, door alle verbeteringen, weer kunnen ombuigen van een dip naar een stip!
Het was een mooie avond, ik heb weer ideeën opgedaan die ik in mijn dagelijkse werk ga doorvoeren. Tijdens de avond kreeg ik een tip voor een boek dat ik meteen maar besteld heb: ‘De vijf frustraties van teamwork door Patrick Lencioni’. Maar daarover later wellicht meer.
NieuwsMagazine
Food for thought:
Die handmatige regressietesten, hoeveel bugs _die expliciet gevonden zouden moeten worden door die scripts_ zijn er het laatste jaar mee gevonden? Hoe kan het dat die bugs, als ze er zijn, niet eerder in de sprint gevonden zijn en zijn ze veroorzaakt door wijzigingen die in die sprint gedaan zijn?
Als je die vraag beantwoord hebt, is de volgende vraag: Is het erg als die testen niet meer elke delivery uitgevoerd worden?
In dit alles is belangrijk te beseffen dat testen een stukje risk management is. Dit betekent niet dat er na testen geen risk management meer mogelijk is. Continuous delivery is hier een mooi voorbeeld. Vaak wordt er vanuit gegaan dat je deployt naar alles en iedereen ter wereld. Een rare gedachte, geen enkele grote speler doet dit. Een nieuwe patch / versie wordt gefaseerd uitgevoerd om zo risico’s te beperken.
Natuurlijk is het vervelend voor de eerste groep klanten die een versie met een issue voor de kiezen krijgt (maar grote kans dat slechts een deel tegen het probleem aanloopt), maar je hebt niet direct een heel groot probleem. Dezelfde dag nog een fix en klaar. Als daarnaast ook de klanten in de eerste release groep elke keer anders zijn, zal een individuele klant maar heel zelden tegen een day-1 issue aanlopen. Dit terwijl de klanten wel vaker nieuwe features krijgen…dus ook voor applicaties geldt: ‘Continuous improvement is better than delayed perfection’