Case: test manager på sletningsrelease til database
Jeg var test manager for en kunde på en release, der havde til formål at rydde op i en database med 8 TB kundedata – dels for at spare penge på storage, dels for at øge systemets stabilitet og hastighed og endelig for at blive GDPR-compliant.
Releasen havde været undervejs i næsten 2 år. Der var allerede et år tidligere forsøgt et forløb mod en produktionssætning, som blev opgivet, da det viste sig at oprydning i en database er mere end blot at skrive og eksekvere SQL-sætninger. Der var andre områder i den samlede løsning for produktet med betydelige risici, der ikke umiddelbart kunne mitigeres af projektgruppen på daværende tidspunkt.
Opgaven var langt mere omfattende end kunden havde forestillet sig. To af de mest kritiske problemer der blev identificeret i projektforløbet var 1) i den underliggende infrastruktur var der en forkert konfigureret Netscaler og 2) applikationen udviklede memory leaks under afvikling med høj belastning. Derudover blev der identificeret en række af andre tekniske elementer, som blev justeret.
Testforløbet i denne release blev designet som en 5-trins raket, hvor der i hvert trin var et eller flere specifikke mål med testen. De 5 trin havde ikke overlappende testscope, men supplerede hinanden, så hvert trin bidrog med mere viden om produktet.
Det var fra starten et udsagn fra kunden om, at der ikke var tillid til releasen. Dette udsagn kom både fra udviklingsholdet, forretningen og kundens sikkerheds- og compliance funktion.
De 5 trin i testforløbet var designet, så der løbende blev skabt tillid til produktet.
Releasen lykkedes fordi der i teamet var en dygtig underleverandør som udviklede produktet, en projektleder med forståelse for betydning af test, en lydhør ledelse hos kunden, der udviste beslutningsdygtighed, og løbende fælles risikovurdering og justeringer af testforløbet, så viden om produktet gradvist blev afdækket. Sidst, men ikke mindst, en it-leverandør, der greb opgaverne som blev stillet i forbindelse med den underliggende infrastruktur og var med på, at kvalitet var den væsentligste parameter.
Projektlederen og jeg fik opgaven i starten af december og releasen blev sat i produktion 4 måneder senere i begyndelsen af marts med en kendt risiko-profil og kendte udeståender.
En måned efter produktionssætningen var der ingen fejl i releasen og produktet fungerende for brugerne uden, at de kunne bemærke, at der i baggrunden løbende blev ryddet op i databasen.
