Tag verantwoordelijkheid

Waarom testen testers?

Tijdens een Retrospective gaf onze tester aan dat hij omkwam in het werk. Eigenlijk verbaasde niemand dat. Ons team bestaat uit vijf ontwikkelaars en één tester, en die ene tester is verantwoordelijk voor het schrijven van geautomatiseerde tests voor de code van al die vijf ontwikkelaars. Je kunt op je vingers natellen dat die situatie niet houdbaar is. – Dus wat te doen?

First time right?

Na afloop van mijn praatje kreeg ik de vraag of ik geloof in het idee van first time right. Mijn antwoord was: “Ik geloof niet dat er zoiets bestaat als first time right. Maar ik geloof wel in first time een stuk beter dan we het nu doen.” Tijd om dat antwoord verder uit te werken, was er op dat moment niet. Maar de vraag bleef wel in mijn achterhoofd spoken. Is het mogelijk om een systeem in één keer goed te bouwen?

Formuleer je kernwaarden

Hoe ziet softwareontwikkeling er – volgens jou – idealiter uit? Hoe functioneert een ontwikkelteam op de toppen van z’n kunnen? Wat is de verhouding tot hun stakeholders en collega’s? Hoe ondersteunt het management daarin? – Als je dat plaatje eenmaal scherp hebt, wat kun je dan concluderen over de kernwaarden van waaruit je software ontwikkelt?

Overpeinzingen (over vakmanschap)

“Ziet u niet hoe vaklieden, hoewel zij tot op zekere hoogte bereid zijn om hun opdrachtgever tegemoet te komen, zich niet kunnen veroorloven af te wijken van de voorschriften van hun vak? Is het niet verbazingwekkend en teleurstellend tegelijk dat bij een architect en een geneesheer de grondbeginselen van hun vak meer gerespecteerd worden dan bij de rede bij de doorsneemens, terwijl het juist de rede is die hij met de goden gemeen heeft?”

De tester als code reviewer

Mijn team heeft onze tester onlangs tot verplichte reviewer gemaakt voor elk pull request (PR). Hij heeft een heel specifieke opdracht – drie, eigenlijk: 1. Ga na of het PR unit- of integratietests bevat. Zo nee, keur het PR dan af. 2. Ga na of je de unit- en/of integratietests kunt begrijpen. Zo nee, keur het PR dan af. 3. Ga op basis van de unit- en/of integratietests na of de code werkt zoals bedoeld. Zo nee, keur het PR dan af. Pas als aan alle drie voorwaarden is voldaan, is het PR klaar om naar de main branch te mergen.

Iteratief verbeteren in de praktijk

Er was een briefje op de deur geplakt, de deur richting de wc’s: “Dicht houden in verband met de kou!” Er was een dingetje dat je moest weten. Als die deur eenmaal dicht was, dan kon je de afdeling softwareontwikkeling alleen nog maar uit – niet meer in. Een slimme ontwikkelaar liet die deur dus op een kier staan. En we waren allemaal slimme ontwikkelaars – misschien was het daarom wel zo koud, bedenk ik nu.

Het is niet jouw verantwoordelijkheid een onmogelijke deadline te halen

Er gebeurt iets wonderlijks wanneer je tegen een ontwikkelteam zegt dat die en die feature een deadline heeft: ze gaan hun best doen om die deadline te halen. Dat is een nobel streven, natuurlijk. Maar het is ook een gevaarlijk gegeven. Want niet elke deadline voor elke feature is even realistisch. Een team dat, ongeacht de haalbaarheid, gaat rennen om die deadline te halen, werkt zichzelf – en haar stakeholders – in de nesten.

Waar doe je het voor?

Een luie programmeur grijpt alles aan om zijn eigen werk makkelijker te maken (met uitzondering van het besparen op kwaliteit - daar is een andere term voor: een slechte programmeur). En makkelijker maken betekent meestal: automatiseren. Want waarom zou je zelf het werk doen, als een machine het ook voor je kan doen?

Test third party code

Het updaten van third party code is net zozeer een risicovolle onderneming als het niet updaten ervan. In beide gevallen loop je kans op de introductie van bugs. Er is een uitweg uit dat probleem. En die uitweg is - zoals meestal in softwareontwikkeling - testen, testen, testen.

Van rader in het geheel naar bron van talent

Hoe ziet een bedrijf haar personeel? Een hint van een antwoord zit ‘m in de daaraan toegewijde afdeling: human resource management. Personeel is een resource, een hulpbron - net als het IT-systeem, maar dan menselijk - die gemanaged moet worden. Die metafoor heeft enkele interessante consequenties, die inderdaad regelmatig haar uitwerking vinden in de praktijk: medewerkers zijn raderen in het geheel, ze moeten op hun prestaties beoordeeld worden en kunnen eenvoudig vervangen worden wanneer ze een negatieve impact hebben op dat geheel. Die zienswijze is hopeloos achterhaald, betoogt Rob van den Berg in Futureproof talentmanagement.