Iedereen die al een tijdje in ‘testland’ rondloopt herkent het wel, de veranderende rol van de testmanager. Tot een jaar of vijf geleden was er duidelijke verdeling in testrollen die we grofweg kunnen onderscheiden in drie tijdvakken.
1: De drukke oude tijd waarbij met een waterval-methode software werd ontwikkeld. De rol van de testmanager bestond uit het maken van testplannen. Er moest goed met projectleiders en ontwikkelteams afgestemd worden wanneer de software opgeleverd werd. En was het dan eindelijk zover, dan begon de drukte. Dan moesten testanalisten aangestuurd worden, defect-overleggen en fix-releases worden geregeld.
2: Daarna volgde de Agile-hype. Wereldwijd werden ontwikkel- en testteams samengevoegd in Agile- of Scrum-teams maakten planningen plaats voor sprints. Op de werkvloer verschenen scrum-, kanban- of andere boards. De rol van de pur sang testmanager verdween en velen werden Scrum Master. Om net als bij de rol van de oude testmanager van alles te regelen om impedimenten uit de weg te ruimen en te zorgen dat teams konden blijven burnen.
3: En nu? DevOps en BusDevOps staan al een tijdje aan de deur te kloppen en bij veel organisaties zijn ze al binnengehaald en worden de Agile-werkende teams in DevOps-team omgevormd. En daar sta je dan als Scrum Master. Jarenlang ben je bezig geweest je teams te helpen en nu gaan ze zelfstandig aan de slag. Ieder team heeft wel een persoon die zelf achter de impedimenten aangaat. En zo ontstaan teams die hun eigen zaken organiseren en daarbij ook hun eigen problemen oplossen.
Vierde rol
Is dit het einde van de testmanager. Nee, want de vierde rol komt er al weer aan.
In situaties waarin slechts de ‘product owner’ nog directe invloed op een team heeft, moet er iemand het oog houden op de kwaliteit? Juist de testmanager. (Bus)DevOps-teams zijn prima in staat om zelf testgevallen te maken, deze te automatiseren en regressietesten in een releasepipeline te duwen. Maar dat is tegenwoordig enkel nog een kwestie van techniek en configuratie van tooling. Wie houdt echter de functionele dekking in de gaten? Hoe worden passende integratietests en ketentests opgezet? Het is belangrijk te zorgen dat een teststrategie wordt uitgezet die meerdere DevOps-teams past en zo efficiënt is dat teams niet dezelfde testactiviteiten uitvoeren.
En, zoals de testmanagers vanuit vroeger jaren al deed, heeft de testmanager van nu overzicht over meerdere systemen en landschappen. Als testmanager help je teams om een testaanpak te kiezen, kun je aangeven aan wat voor eisen je tests zouden moeten voldoen en help je bij het verdelen hiervan in blokken, zodat ze in hapklare delen als userstories en sprints opgepakt kunnen worden.
In vijftien jaar tijd is het vak van testmanager enorm volwassen geworden. Er mag een kwaliteitsstempel op!
Ok, hier ben ik het dus duidelijk niet mee eens.
1. Binnen Agile is geen plek voor een Test manager. Wanneer die er wel is, is dit een veelal een teken dat er geen serieuze Agile wordt bedreven. Een Test manager is soms wel nodig om zwakke testers te compenseren. Ik zou als bedrijf gewoon investeren in goede, technisch onderlegde test engineers met programmeer skills.
2. DevOps is voor heel veel bedrijven nog mijlen ver weg. Om aan te geven dat dit binnenkort de volgende stap is. Tsja…. voor bedrijven als Cool Blue misschien al realiteit, maar voor veel (grote) organisaties zal dit nog jaren en jaren gaan duren.
3. In modern DevOps wordt kwaliteit geborgd door het CI/CD ontwikkelproces en een moderne modulaire, schaalbare architectuur. Elk stuk functionaliteit wordt als een service geleverd (in welke vorm dan ook) en is schaalbaar. Unit testen zijn hierbij het fundament van de testautomatisering. Alle overige testen zijn een aanvulling op datgene wat niet kan worden gedekt door unit-testen. Mits de architectuur dit toelaat kan er heel veel worden afgedekt met unit-testen. Ketentesten (via de UI) zijn relatief traag, arbeidsintensief en foutgevoelig, en daarom enkel nodig om de compleetheid te testen van een systeem. In de toekomst zal dit hooguit 5% van test-effort mogen zijn. Binnen CI/CD is er dus ook vanuit testzijde technisch begrip nodig van architectuur, programmeercode en testautomatisering. Niet het sterkste punten van een de meeste testmanagers.
Het is je misschien al duidelijk geworden dat ik de functie van test manager geen toekomst geef 😉
2018, het jaar van de BuzzDevOps
@Rene … ik heb meerdere ervaringen opgedaan in de loop der jaren met Agile teams waarbij het team dacht bepaalde rollen (zoals testmanagement, maar bijvoorbeeld ook configuration management) zelf in te kunnen vullen. Wanneer alles binnen één team blijft lukt dit vaak nog wel, maar op het moment dat je aan een product werkt waar het werk van meerdere Agile teams samenkomt, dan kunnen er flinke gaten vallen in het totaalplaatje. Dit is waar bijv. de testmanager een belangrijke rol kan vervullen. Wie coordineert de overall test strategy, wie coordineert de testen die alleen op systeemniveau uitgevoerd kunnen worden, wie schrijft de testrapporten aan het eind van de rit welke nodig zijn voor vrijgave etc….
@pa va ke
‘…Wie coördineert de overall test strategy…’=>
Een test strategie was vroeger het feestje van de testers. Dat is nu een team effort geworden (van architect tot aan tester). Deze heeft in de toekomst (bij CI/CD) meer technische diepgang dan voorheen.
‘…wie coördineert de testen die alleen op systeemniveau uitgevoerd kunnen worden…’. =>
Dat is een probleem van veel hedendaagse IT architectuur. Die is vaak niet goed unittestbaar. Bij een moderne architectuur, passend binnen CI/CD, wordt gekeken naar o.a. test-, schaalbaar- en koppelbaarheid. Mede hierdoor ben je veel beter in staat om snel en volledig inzicht te krijgen in kwaliteit (voornamelijk d.m.v. unit- en integratie testen, welke doorgaans in code worden gemaakt).
‘.. wie schrijft de testrapporten aan het eind van de rit welke nodig zijn voor vrijgave etc….’ =>
Bij CI/CD heb je geen testrapporten en al helemaal geen vrijgave-adviezen. Er wordt continue geleverd. Elke dag wordt er meerdere malen naar productie gedeployed. Dat betekent dat werkelijk de gehele CD pipeline is geautomatiseerd. Volgens mij zijn er al wat grote(!) bedrijven in NL die hierin succes boeken. Kijk maar naar Cool Blue (waar ik overigens NIET werk).
Maar wat zegt het over de mentaliteit/cultuur van de organisatie en de teams als gaten pas gevuld worden op het moment dat er officieel een (gecertificeerde?) manager aangesteld is? Wat voor impact heeft dat op de o zo gewenste Agility?
Daarop doorredenerend:
Ook vraag ik me af wat er onder streep over blijft van de Agile gedachte op het moment dat er gewerkt wordt met grote(re) “Agile” teams. Immers, naarmate teams groter worden en de bemensing ook nogal eens varieert neemt het aantal processen, procedures en regels exponentieel toe; doorgaans gekoppeld aan de nodige managers en spreadsheets.
Concreet voorbeeld: http://www.ambysoft.com/essays/agileRoles.html
In dit voorbeeld zijn er 7 pools van mensen. Verdeeld over deze 7 pools wordt er steeds een “Agile” team samengesteld. Afhankelijk van de grootte van deze pools heeft elke pool weer zijn eigen coördinator/teamlead/manager die o.a. bepaald wie waar ingezet wordt.
Daaromheen moeten weer processen, procedures en regels opgesteld worden om op enig moment te kunnen bepalen welke sprint welke expertise nodig heeft en in welke omvang; zeker als er veel gewerkt wordt met ZZP-ers en ontwikkelteams in andere, lage lonen landen.
Een groot deel van de felbegeerde Agility wordt hierdoor vrijwel zeker teniet gedaan… voor je het weet heb je toch weer doorlooptijden van 3+ maanden… voornamelijk vanwege “snijverlies” doordat de teamsamenstelling steeds varieert en de daarmee samenhangende “omsteltijden” steeds langer worden.
Misschien was de combi waterval-methode en eigen-mensen toch zo gek nog niet… 😉
@rene … Kijken we even verder dan een webshop, bijvoorbeeld bij medisch diagnostische apparatuur (röntgen, mri), dan is de software onderdeel van het product, en heeft van daaruit een zwaar vrijgavetraject waarbij ook documentatie hoort.
Op ontwikkelniveau kun je wel CI/CD toepassen, zodat elke wijziging meteen mee getest gaat worden, maar eenmaal in productie kan de software niet zomaar constant gewijzigd worden.
De complexiteit van zulke systemen vereist meer afstemming, o.a. op testvlak, immers, je wil aan het eind van de rit zeker zijn dat alles getest is en er niets over het hoofd gezien is. Met alleen unit testen heb je geen garantie dat het geïntegreerde systeem van deze units ook werkt zoals verwacht
@Wil … zelf ben ik wel gecharmeerd van de SAFe (scaled agile framework) aanpak wanneer er meerdere agile teams samen aan een product moeten gaan werken.
Maar ik ben het met je eens dat, hoe groter het project wordt, management en processen remmend kunnen gaan werken.
Daarvoor is het mijns inziens dan ook belangrijk dat de architectuur van een product dusdanig is dat teams zo onafhankelijk mogelijk van elkaar kunnen werken. Het goed definiëren en vooral bewaken hiervan is van essentieel belang hiervoor.
Soms roept met wel dat men onafhankelijke bouwblokken heeft etc, maar als je dan gaat kijken dan blijkt het een Franse kaas-tosti model te zijn: van buiten lijken het laagjes maar als je die van elkaar probeert te halen dan zie je heel veel dikke en dunne verbanden ….