Tijd tot kwaliteit begrijpen
Er zijn tegenwoordig tal van statistieken die worden gebruikt om de voortgang van QA bij te houden. De meeste daarvan zijn behoorlijk nuttig, maar ze zijn allemaal nogal eendimensionaal, in die zin dat het momentopnamen zijn van een bepaald moment of een bepaalde sprint in de tijd. Dit geldt zelfs voor tempo- en trendstatistieken, die ongelooflijk belangrijk zijn, maar opnieuw momentopnamen in de tijd vormen.
Toen ik bij Symantec werkte, merkte ik het volgende op:
Er werden veel statistieken gebruikt om het niveau van de kwaliteit die op de leverdatum (naar verluidt) was bereikt, vast te stellen. Maar er werden geen statistieken verzameld, noch tijdens het proces, noch achteraf, om de kosten van het bereiken van die kwaliteit te meten.
Met andere woorden: het maakte ons niet uit hoe efficiënt die kwaliteit gedurende de looptijd van het project werd bereikt.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Je product is misschien met een hoge kwaliteit geleverd, maar moest het echt zoveel tijd en moeite kosten om die kwaliteit te bereiken?
Dit is op zichzelf een efficiëntievraagstuk, geen kwaliteitsvraagstuk, maar de twee houden sterk verband met elkaar.
Het raakvlak van kwaliteit en efficiëntie
Kwaliteit en efficiëntie kruisen elkaar omdat een van de belangrijkste redenen waarom softwareprojecten vaak aanzienlijk uitlopen op hun geplande opleverdatum (en dit komt vaak als een onverwachte “adder onder het gras” in de laatste fase van het project) een slechte codekwaliteit is. Niet alleen de aanvankelijke codekwaliteit, maar gedurende het hele project.
Een andere reden, die eigenlijk slechts een onvermijdelijk gevolg is van een slechte codekwaliteit, zijn defecten waarvoor meerdere herstelpogingen nodig zijn, verspreid over meerdere testrondes of sprints voordat het defect daadwerkelijk is opgelost. Als het al lukt.
Deze eindeloze iteraties van herstellen, testen en opnieuw falen voegen aan bijna elk softwareproject talloze persoonsweken toe.
Toch wordt dit faalpatroon, interessant genoeg, niet afzonderlijk vastgelegd in andere project- of kwaliteitsstatistieken die ik heb gezien. Zoals hierboven opgemerkt, zijn al deze statistieken momentopnamen in de tijd en slagen ze er daardoor niet in dit verschijnsel vast te leggen.
Het viel me in dat er een eenvoudige manier was om dit faalpatroon vast te leggen. Ik bedacht een statistiek die ik "Tijd tot kwaliteit" noemde, oftewel TTQ.
Introductie van een nieuwe statistiek: Tijd tot kwaliteit (TTQ)
De statistiek zelf is vrij eenvoudig. Hij werkt als volgt:
Houd voor elke testronde (hoe die ook wordt gedefinieerd) niet alleen bij hoeveel tests zijn geslaagd of mislukt, maar ook hoeveel tests bij de eerste poging zijn geslaagd. En hoeveel pogingen er nodig waren — twee, drie of meer — voordat dezelfde tests uiteindelijk slaagden.
Als eenvoudig voorbeeld: als je 20 tests uitvoert en er 5 bij de eerste poging slagen, is je TTQ-ratio 25%. Hoe hoger het getal, hoe beter. Het is een eenvoudige, berekenbare en gemakkelijk toegankelijke indicator van je algehele codekwaliteit.
Deze statistiek is een zeer goede indicatie van de aanvankelijke codekwaliteit.
Dat komt doordat je, naarmate de kwaliteit van de code hoger is, een test minder vaak op die code hoeft uit te voeren voordat deze slaagt. En omgekeerd. Deze statistiek is veel nauwkeuriger dan aantallen defecten en trends.
TTQ is ook een ongelooflijk nuttige statistiek voor het volgen van projecten.
Als bijvoorbeeld 70% van de tests bij je eerste testronde slaagt en 30% mislukt, kun je redelijkerwijs aannemen dat je project wat de planning betreft nog op schema ligt. Maar als bijvoorbeeld slechts 20% van je tests bij de eerste uitvoering slaagt, dan ben je, om het in technische termen te zeggen, "Meid, je zit in de problemen! "
Dat betekent namelijk dat je eerste testronde in feite niet succesvol was. En die tijd moet als kwaliteitsschuld aan een toekomstige testronde worden toegevoegd.
De TTQ-statistiek is uiterst nuttig als wat ik graag een "waarschuwingsstatistiek" noem.
Als je deze consequent gebruikt, levert hij zeer nauwkeurige gegevens op waarmee de projectmanager kan vaststellen of het project ontspoort, lang voordat de trein daadwerkelijk de rails verlaat.
Dit betekent dat er veel eerder proactieve maatregelen kunnen worden genomen om de zaken weer onder controle te krijgen. Zo voorkom je gênante bekentenissen, heel laat in het proces, dat de projectplanning aan flarden ligt. Gebruik met andere woorden een TTQ-drempel om te bepalen of het project nog op groen staat, op geel staat of op het punt staat rood te worden. Maak deze integraal onderdeel van de projectstatus zelf.
Want laten we eerlijk zijn: een van de hardnekkige problemen bij softwareontwikkelingsinspanningen is de aanhoudende ontkenning dat er dingen misgaan — en wel op grote schaal — zodra voor het eerst duidelijk wordt dat dit het geval is. Iedereen is bang om als “negatief” te worden bestempeld, of dat men simpelweg te lui of te weinig toegewijd is om de problemen op te lossen, of geen “teamspeler” is. De overeenkomst met disfunctionele gezinnen is ongemakkelijk duidelijk.
Deze ontkenning en onderdrukking van wat iedereen weet dat er werkelijk gaande is, leidt tot het faalpatroon waarbij men weigert te erkennen dat het project ver, ver achter op schema ligt, tot het allerlaatste moment.
Wanneer dit niet langer voor het hogere management verborgen kan worden gehouden, ondermijnt de onaangename verrassing die dit voor hen veroorzaakt soms — en soms permanent — hun vertrouwen in hun eigen ontwikkelteams. En wie kan het ze kwalijk nemen?
Maar als je TTQ consequent opneemt in je statistieken en projectmanagement —en handelt naar wat die statistiek je vertelt— kun je dit voorkomen.
Het meten van de tijd tot kwaliteit depersonaliseert de beslissing om te erkennen dat plannings- en kwaliteitsrisico's zich al in de vroegste fasen van het project opbouwen.
Het wordt heel duidelijk en ondubbelzinnig, een kwestie van cijfers. Niet een kwestie van persoonlijk heldendom, dat de persoon vaak duur komt te staan.
De TTQ-metriek is ook zeer nuttig voor een projectretrospectief of een evaluatie achteraf van een project.
Hiermee kan het team precies vaststellen welke delen van de code zwak waren en gedurende het hele project zwak bleven. En daarmee ook hoe efficiënt het team was in het produceren van kwaliteit als zodanig. Of hoe kostbaar dat was.
Dit is een vraag die in projectretrospectieven grotendeels wordt vermeden. Deels omdat teams niet over de conceptuele woordenschat beschikken om deze te formuleren, en deels omdat het vaak politiek gevoelig ligt om vanuit de engineeringafdeling consequent slechte codekwaliteit aan te wijzen.
Samenvatting
TTQ zorgt voor enorme transparantie en voorspelbaarheid in uw projecten, vrijwel zonder tijd of moeite te kosten, omdat het simpelweg een meta-analyse is van metrieken die u al verzamelt.
Ik gebruik TTQ al twee decennia in mijn QA-projecten en het heeft brede acceptatie gekregen onder projectmanagers die ik erin heb opgeleid, om alle hierboven genoemde redenen.
Probeer het uit en u zult het zelf zien. Het zal echt een gamechanger zijn voor uw team. Zoals altijd: veel succes.
P.S. Als u meer praktijkverhalen en de redenen achter TTQ wilt horen, sprak ik met Jonathon Wright op de QAL Podcast.
