Na elke iBurgerzaken release hebben we een Kwaliteitsweek. Deze week is een vast onderdeel van de ‘Eye of the Hurricane’: een moment tussen 2 iBurgerzaken releases om te werken aan dingen die moeilijk in te passen zijn in het vaste sprintritme. Eerder schreven we al over de Innovatieweek die 4x per jaar ruimte biedt voor innovatie. De Kwaliteitsweek is een belangrijk onderdeel binnen ons gehele proces voor kwaliteitsborging. Laten we dit proces eens nader bekijken; onze OTAP-straat en de rol van de Kwaliteitsweek daarin…
Laten we bij het begin beginnen… iBurgerzaken is belangrijk voor een primair proces van de gemeente; zonder deze software kunnen burgers en bedrijven niet direct geholpen worden bij de aanvraag of aangifte. Dat versterkt de vraag om continue beschikbaarheid en zo min mogelijk fouten. Bovendien is het daardoor wenselijk nieuwe functionaliteiten die het proces verbeteren snel uit te leveren, uiteraard met oog voor de juiste kwaliteit. Vandaar dat we kiezen voor korte releases met een gedegen OTAP-straat.
De afkorting OTAP staat voor ontwikkeling, test, acceptatie en productie. Het is een methode voor het ontwikkelen van software. OTAP is een werkwijze die zorgt dat er op efficiënte en beheersbare wijze nieuwe releases en patches geïnstalleerd worden. Het belang van de kwalitatief sterke OTAP-straat en continuïteit in de ontwikkelomgeving mogen niet worden onderschat. De vier fases zijn essentieel. We willen immers kwalitatief goede software opleveren en toeval uitsluiten.
De afdeling Development van PinkRoccade Publiekszaken kent 3 ontwikkelteams voor iBurgerzaken; vandaag de dag zijn dat team Care, Core en Edge. Hoewel elk team net een andere focus en een andere werkwijze heeft, werken ze uiteraard wel allemaal volgens dezelfde (scrum)principes en processen.
Dat betekent dus dat er meerdere teams én daarmee meerdere personen aan één versie van iBurgerzaken werken; een nieuwe release. Dat doen ze in een speciale ontwikkelomgeving die nabootst hoe de software ook in productie zal fungeren. In deze omgeving werken de ontwikkelteams aan een story of bug. Afhankelijk van de complexiteit van het stukje ontwikkelwerk is dat één persoon of zijn dat meerdere personen uit het team.
Voor, tijdens en na de ontwikkeling zijn er binnen scrum meerdere kwaliteitsmomenten ingebouwd: bijvoorbeeld de (pre)refinement, testvoorbereiding, (peer) review, uitgebreid testen en sprint review. Tijdens de refinement bespreekt het team de story zodat het vraagstuk vanuit diverse disciplines is beoordeeld. De (peer) review gebeurt bij voorkeur door een collega buiten het eigen team waardoor de gemaakte oplossing nogmaals kritisch wordt beoordeeld. En de testvoorbereiding en het testen gebeurt door een Tester, een specialist op dit vakgebied. Als er nog iets fout zit in de software gaat het uiteraard direct terug naar de ontwikkelaar(s) zodat tijdens de sprint review het eindresultaat getoond kan worden aan de stakeholders. Dat is nog een extra feedbackmoment vanuit bijvoorbeeld de andere ontwikkelteams, de Manager Development of de Productmanager.
Daarnaast kennen we binnen iBurgerzaken vele automatische testen, zowel technisch als functioneel. De resultaten van deze unittesten, integratietesten (2.119 scenario’s), grafische testen (91 scenario’s) en loadtesten liggen de volgende dag klaar voor het ontwikkelteam. Daarmee wordt bijvoorbeeld ook zichtbaar wat de impact is op de gehele applicatie; regressie. Daarnaast testen we ook de version fixers; 1 scenario voor iedere status in ieder proces. In principe moeten deze testen allemaal ‘groen’ zijn voor de afronding van elke sprint binnen de release.
Elke iBurgerzaken release sluiten we tenslotte af met een Kwaliteitsweek. Daarbij zijn in principe alle ontwikkelaars betrokken, als één (test)team. Dit is dus een extra aanvulling op de automatische testen. Het testgilde bepaalt vooraf de scope; enkel een handmatige regressietest voor de apps met veel of complexe ontwikkelingen binnen deze release. Voor de overige apps doorlopen we alleen handmatig de happyflow van deze processen voor een visuele controle. Zo zetten we onze tijd zo efficiënt mogelijk in; meer tijd en aandacht aan de meer risicovolle onderdelen van de release. Daarnaast gebruiken we deze week om wat gevonden is te corrigeren en om te werken aan andere kwaliteitsverhogende activiteiten. Denk hierbij aan analyse van de logging, aanvullingen en verbeteringen van onze geautomatiseerde tests, onderzoeken van incidenten, prioriteren van marktsignalen, voorbereiding van de gebruikerstesten etc.
Na goedkeuring kan de nieuwe release van iBurgerzaken worden geïnstalleerd in diverse acceptatieomgevingen. Dat doen we gefaseerd met ook hier weer oog voor de juiste kwaliteit:
[A1] Allereerst installeren we iBurgerzaken in onze acceptatieomgeving; ACC. Deze acceptatieomgeving is, qua hard- en software, zoveel mogelijk gelijk aan de productieomgeving. In deze fase kunnen functionaliteiten en performance bekeken worden door de Product Owners, zonder dat de dagelijkse productie hierin onderbroken wordt.
[A2] Als deze stap ook succesvol wordt doorlopen installeren we de release op de klanttestomgeving; CTE. Vanaf dat moment kunnen alle klanten met een testomgeving de nieuwe software in hun eigen testomgeving benaderen. Dit gebeurt vrijwel direct na stap A1.
[P1] Na acceptatie van een groep specifieke testklanten zetten we de release door naar de ‘Early Adopter omgeving’; een groep van 8-10 geselecteerde gemeenten die de software in de praktijk gaan gebruiken. Dit is bij voorkeur 1 à 2 weken na stap A2.*
[P2] 1 à 2 weken later* installeren we de nieuwe release binnen de productieomgeving; alle klanten gebruiken vanaf dat moment de nieuwe software in de productieomgeving. Uitzondering: Op het moment dat we een compleet nieuwe app uitleveren betrekken we veelal enkel een specifieke groep klanten; kwartiermakergemeenten die een pilot draaien en de nieuwe functionaliteiten beproeven voor de landelijke uitrol.
Uit dit alles blijkt dat we kwaliteit hoog in het vaandel hebben staan en dat we het zien als de verantwoordelijkheid van iedereen. In de verschillende fases zijn heel bewust diverse partijen betrokken want alleen samen kunnen we zorgen dat we toeval – zoveel mogelijk – uitsluiten en kwaliteit blijven leveren!
Bijvoorbeeld door als applicatiebeheerder met jouw burgerzakenteam je verantwoordelijkheden te nemen bij stap A2; jouw applicatielandschap of jouw gebruikerstest kan er immers net anders uitzien dan dat wat wij getest hebben… En door dit ‘probleem’ in fase 3 al boven water te krijgen voorkomen we wellicht onnodige verstoringen in fase 4. En de dienstverlening aan burgers en bedrijven willen we allemaal continu door laten gaan toch?!
-------------
*) Voor de volledigheid: We leveren in principe uit conform releaseplanning waarover we tijdig communiceren. In het geval van enige twijfel nemen we echter geen risico’s. Dan stellen we de installatie van een release naar de acceptatieomgeving, CTE, Early Adopter of productieomgeving uit. En zetten we zogezegd eerst een aantal stappen terug in de OTAP-straat.
‘Klanten wil ik steeds opnieuw op een creatieve wijze verrassen.’
Sanne van der Zanden, Programmamanager
