Toen in 1995 de Test Management Approach (TMap) werd geïntroduceerd, betekende dat niet alleen een gedegen nieuwe aanpak van IT-testen. Het gaf ook een boost aan de erkenning voor het belang van testen. Anno 2020 is dit vakgebied volwassen geworden en staat het steeds vaker synoniem voor zorg voor kwaliteit.
Kwaliteit staat aan de basis van ieder DevOps team vandaag de dag. Daarom hebben de auteurs van het nieuwe Sogeti-boek ‘Quality for DevOps teams’ de term ‘test’ maar helemaal verwijderd uit hun model. De zes activiteiten van DevOps bestaan uit: Plan, Code, Integrate, Deploy, Operate en Monitor. Co-auteur Rik Marselis: “Testen is niet een stapje binnen je activiteiten, maar iets overkoepelends. Het is kwaliteitszorg voor het IT-proces in de brede zin van het woord. Rondom het DevOps model zijn twee cirkels met kwaliteitstestactiviteiten. De ene cirkel bevat de organiserende onderwerpen zoals de rollen en verantwoordelijkheden en voortdurende verbetering. De andere ring geeft de uitvoerende onderwerpen weer, zoals test design, acceptatiecriteria en dergelijke.”
Waar staan we?
Het boek beschrijft waar we nu staan met DevOps en wat deze manier van kwaliteitsbewaking behelst. Ondanks het indrukwekkende aantal pagina’s (ruim 400) benadrukt Marselis dat niet alles erin staat. “In dit boek focussen we op wat nieuw is. We geven een inleiding met verduidelijkende schema’s en lichten dan vervolgens ieder onderwerp toe. Wie verder de diepte in wil, kan op internet terecht. De ‘body of knowledge’ die daar beschikbaar is, dekt in principe alles af.”
Het boek besteedt veel aandacht aan de wens van veel organisaties om naar een DevOps-cultuur te bewegen. “Niet ieder bedrijf is een Bol.com,” waarschuwt Marselis. “De componenten in hun website kun je prima tien keer per dag opnieuw releasen. Maar een bank met een traditionele hypotheekmoloch lukt dat echt niet. Er zijn nog altijd projecten die met waterval goed verlopen. We beschrijven daarom ook de traditionele en hybride modellen.”
Cross-functionele teams
Marselis loopt al veertig jaar mee in de IT. “Toen Glenfort Myers zijn beroemde boek ‘The Art of Software Testing’ publiceerde in 1979, ging testen over het opzoeken en oplossen van alle fouten. Dat kon toen nog met de beperkte omvang van systemen. Tegenwoordig is dat volstrekt onhaalbaar. Daarom moet je nu kwaliteit inbouwen – waarbij testen vooral bevestigt dat het goed is – en moet je op alle activiteiten van DevOps over kwaliteit nadenken. Hierin komt ook de waarde van cross-functionele teams duidelijk naar voren, een belangrijk item in het boek. Niemand in het team heeft het monopolie op specifieke taken, maar alle teamleden dragen dezelfde verantwoordelijkheid. Als een businessanalist ziet dat iets niet goed werkt, hoeft hij niet op de ontwikkelaar te wachten. Tenzij het programmeerwerk te ingewikkeld wordt natuurlijk. Ook gaat het testen gewoon door tijdens de vakantie van de testspecialist. Anders dan in een multidisciplinair team, waar alle specialisten hun eigen dingetje doen, dragen de leden van een cross-functioneel team de verantwoordelijkheid voor alle dingen samen.
Ketenregressietestteam
Cross-functionele teams realiseren zich dat ze onderdeel zijn van een groter geheel. Het boek pleit dan ook voor de inrichting van een ketenregressietestteam. Marselis: “Als een team vertrouwen heeft in hun aandeel, checkt het ketenregressieteam of dat stukje geen problemen veroorzaakt in de keten. Bij een grote bank bouwen wel meer dan honderd teams aan systemen. Belangrijke systemen raken aan zeker tien ketens. Hiervoor moeten dus tien ketenregressietestteams een soort van supervisie uitvoeren.”
