Agile, Testadvies, Testmanagement

Zorgen dat we sneller naar productie gaan door het hele team met kwaliteit te infecteren. Dat is waar ik mij de afgelopen maanden bij mijn klant mee bezig heb gehouden. Daarvoor moesten we met z’n allen vanuit nieuwsgierigheid de ‘status quo’ uitdagen. En wilden we als team één visie, één aanpak vastleggen. Waarin continue verbeteren, concrete en snelle resultaten de codewoorden zijn.

We doen het niet

De uitdaging waar wij voor stonden was om met behoud van kwaliteit naar meer snelheid te gaan. Een oplossing moet wat ons betreft altijd door het hele team gedragen worden. Daarom begonnen we met brainstormsessies: waarom moet het sneller? Hoe doen we ons werk nu? Willen we dingen anders gaan doen? Willen we taken niet meer gaan doen? De eerste instelling was: het kan niet sneller. Alles wat we doen – zoals een goede systeemtest, ketentest, productie-acceptatietest, performance test – moeten we blijven doen. Toen zijn we ons dat toch gaan afvragen: welk risico dekken we hiermee eigenlijk af? Is dat nog nodig? Kan het anders? Worden er niet dingen dubbel gedaan?

"We gingen als team nadenken over een andere manier van testen."

Anders testen

Na de eerste sessie ontstond een flow binnen het team en kwamen er meer sessies. We gingen als team nadenken over hoe we op een andere manier kunnen testen terwijl we tegelijkertijd continu feedback hebben. Dat leidde tot een aantal oplossingen:

  1. Geen performance testen, tenzij.
    Toen we ons realiseerden dat we al jarenlang zes keer per jaar een performance test draaien en de resultaten eigenlijk altijd goed zijn, vroegen we ons af waarom we dit nog doen. Wat zou er gebeuren als blijkt dat iets niet goed gaat? Hoe erg is dat dan? Omdat ons productiesysteem dubbel is uitgevoerd kan in principe de helft uitvallen of aan performanceverlies verloren gaan en dan kunnen we nog alles bedienen. Vandaar dat we besloten om geen performancetesten meer te doen, tenzij we op voorhand grote perfomancerisico’s zien. Dit scheelt veel tijd. Eventueel performanceverlies onderkennen we nu dankzij onze monitoring in productie en herstellen we in de volgende release of eerder indien nodig.
  2. Ontwikkelaars gaan meer zelf testen.
    Feedback wil je snel hebben. Niet pas als software in productie staat of zich al in de acceptatieomgeving bevindt. Ontwikkelaars zijn daarom meer unittesten gaan maken. Deze draaien zij direct als de code klaar is zodat ze meteen weten of deze goed is. Daardoor heb je minder testen daarna nodig. Het duurde even voor iedereen zich in deze nieuwe aanpak kon vinden. Na meerdere sessies bleken echter steeds meer de voordelen, was iedereen on board en konden we verder. Ontwikkelaars en testers stemmen nu onderling af wie wat test, waarbij zoveel als mogelijk reeds in de unittests wordt afgevangen en doublures in testen worden voorkomen.
  3. Tester gaat meer naar de voorkant in het softwareontwikkeltraject, shift left .
    Door de tester eerder in het traject te betrekken en aan de business analist te koppelen, kan hij actief meedenken, testgevallen en testbaarheid bepalen en de implementatiestrategie ontwikkelen. De input voor de ontwikkelaar is daardoor beter op orde. De testers controleren nu mede aan de voorkant in plaats van enkel aan de achterkant.
  4.  Wij testen in productie, shift right.
    Eerder moest iets perfect zijn voordat we het naar productie brachten. Tegenwoordig zorgen we dat het goed is, dan gaan we naar productie om daar verder te testen en continu te blijven verbeteren. De monitoring hebben we verbeterd – onder andere door het resourceverbruik te monitoren-, errors worden goed geanalyseerd en (bug) taken staan op de backlog. Iets dat wij bijvoorbeeld daarnaast doen is een nieuwe release om te beginnen op één server laten draaien in plaats van op alle vier tegelijk. Ook dat is een manier om te testen: als het op één server goed gaat, kan het product door naar de rest.
  5. Een user story wordt door een kleiner team opgepakt.
    Eerder pakte het hele team een nieuwe user story op om deze te refinen. Nu doet een kleiner team van één ontwikkelaar, één tester en één businessanalist dit. De andere zes kunnen doorwerken. Daardoor kunnen de overige  personen ieder ongeveer twee uur per week aan andere dingen besteden.

Quality Infected Team

Toen de eerste weerstand overwonnen was, bleek dat het wel kan: meer snelheid door anders te testen met behoud van kwaliteit. Als je maar flexibel bent en zorgt dat feedback snel komt. Voor de testers was er onzekerheid over wat de nieuwe manier van testen voor hun zou betekenen. Maar door de testers aan de voorkant meer te betrekken, zorgen we er nu voor dat daar de kwaliteit al goed is. In productie zijn testers nu meer bezig met testen, monitoren en beoordelen. Er blijkt dus nog genoeg werk te doen! Onze testers worden nu alleen anders ingezet. Ontwikkelaars hadden op hun beurt weerstand door het idee dat testen niet iets voor hen is en beter opgepakt kan worden door een specialist. Nu blijkt dat unittesten klein en flexibel zijn en sneller te maken dan de systeemtesten die de tester voorheen maakte, kunnen ontwikkelaars zich er helemaal in vinden. We zijn dankzij onze Whole Team Apporach  met z’n allen een Quality Infected Team geworden waardoor we meer focus hebben op het snel en kort cyclisch leveren van klantwaarde.

 

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz