Onder de motorkap van het ontwikkelteam.

Inzicht in softwarekwaliteit voor het management

De meeste IT-leads en product owners hebben het wel eens meegemaakt. De software die wordt opgeleverd in de acceptatieomgeving is niet productiewaardig. Hoe kan het toch dat dit gebeurt als je een ervaren team hebt van senior ontwikkelaars? Zijn de bedrijfprocessen of epics te complex? Wordt de ‘Definition of Done’ niet nageleefd? De oplossing hiervoor kan eenvoudiger zijn dan je misschien denkt.

Bij de meeste softwareontwikkelprojecten, die ik heb meegemaakt, wordt de businesswaarde van een nieuwe functionaliteit pas echt duidelijk wanneer die functionaliteit is opgeleverd in de acceptatie of productieomgeving. Ook de kwaliteit van de applicatie wordt pas bij oplevering zichtbaar. Tijdens de ontwikkeling is het voor het management vaak onduidelijk wat er gebeurt. Het is als een ‘black box’ waarbij in- en output bekend zijn, maar wat er binnenin gebeurt, is onzichtbaar.

Daarbij komt dat het ontwikkelteam zelf, soms, door de bomen het bos niet meer ziet. Met name wanneer het team onder tijdsdruk staat en wanneer verschillende tests en kwaliteitsscans in de ontwikkelpijplijn meldingen rapporteren
Door de hectiek en het beperkte overzicht kan het soms gebeuren dat er ongeteste functionaliteit of software met beveiligingslekken naar productie gaat.

Fail fast?

Hoe eerder problemen worden opgelost hoe goedkoper. Hoe langer je wacht, hoe duurder. In een eerder artikel ga ik in op het fenomeen technische schuld en wat hieraan kan worden gedaan.
Fouten en problemen vroegtijdig opsporen en oplossen, kan leiden tot een lagere kostenpost voor corrigerend onderhoud. Dit betekent dat het project binnen het gestelde budget kan worden afgerond, wat kan leiden tot een hoger rendement op de investering.

Als men daarom eerder wil weten of iets niet voldoet, is het nodig om vroeg inzicht te hebben.
Ontwikkelaars kunnen dan eerder reageren op problemen en kunnen daarmee vertragingen voorkomen. Dit kan leiden tot een snellere time-to-market, wat betekent dat het product eerder beschikbaar is voor gebruikers en dus eerder waarde levert.

Op dit moment is er een overvloed aan monitoring en dashboarding-tools in de markt beschikbaar. Deze tools kunnen van alles weergeven, infra- en hardware performance, de staat van de virtualisatie of het containerplatform en alle logs.
Daarentegen is de keuze beperkt als het gaat om het monitoren van de softwareontwikkeling zelf.

Ontwikkelaars kunnen tijdens het ontwikkelen directe feedback krijgen van hun ontwikkelprogramma (IDE). Dit is te vergelijken met de spelling- en grammaticacontrole tijdens het typen. Daarnaast geven de testtools in de testomgeving vaak een overzicht van de regressie of de uitvoer van de test cases.

Maar, voor inzicht in de bouwfase zijn ze vaak aangewezen op de resultaten van de verschillende scans en tools. Al deze scans hebben een resultaat, soms blokkerend, soms minder urgent. Sommige meldingen vormen een echt risico en in andere gevallen valt het onder technische schuld en kan het later worden opgelost. Maar wie bewaart het overzicht hiervan? Hoe wordt de prioriteit bepaald en hoe komt het werk dat eruit voorkomt weer in de sprint?

Nadat een ontwikkelaar zijn werkpakket (user story) heeft afgerond en de code heeft toegevoegd het geheel (main branch) worden er automatisch tests en scans uitgevoerd in de verschillende bouwstappen van de ontwikkelpijplijn. In deze stappen worden unittests uitgevoerd, wordt statische codeanalyse gedaan, worden gebruikte bibliotheken (dependencies) gescand op bekende beveiligingslekken en daarnaast vindt er nog een automatische regressietest plaats. Als deze stappen hebben hun eigen meldingen en kwaliteitsdrempels (quality gates). Dit resulteert in zoveel meldingen dat dit veel te veel is om op dagelijkse basis bij te houden.

Waarom Quality-time?

Ik zie tegenwoordig steeds meer teams die streven naar een volledig geautomatiseerde pipeline met verschillende kwaliteitscontroles en tests als vast onderdeel.
Als het team daarnaast gebruik maakt van een digitaal scrum-board dan zijn er verschillende bronnen beschikbaar die informatie bevatten over de kwaliteit van de software, de kwaliteit van het ontwikkel- en testproces en de snelheid waarmee er wordt geacteerd op mogelijke problemen.
Meerdere tools geven meldingen van variërende prioriteit waardoor de mensen er niet meer op willen reageren, dit wordt ‘alert fatigue’ genoemd. Ook omdat er zoveel plekken zijn waar iets geconfigureerd kan worden, en teams vaak gefocust zijn op het afkrijgen van hun sprintwerk, zien ze geregeld iets over het hoofd.

Om het team zo snel mogelijk van feedback te kunnen voorzien op gebied van kwaliteit, moeten al deze bronnen regelmatig worden geraadpleegd.

De algemene vraag die Quality-time beantwoord is: “Wat staat er te doen op het gebied van softwarekwaliteit, ontwikkelproces en werkvoorraad?”.

Quality-time is een open source, geautomatiseerd dashboard (webpagina) dat actuele informatie geeft op basis van de geconfigureerde achterliggende bronnen. Deze informatie wordt ingedeeld op kwaliteitsattributen (niet-functionele eisen / non-functional requirements) zodat de gebruiker op ieder moment antwoord heeft op vragen zoals:

• Hoe staat het met de onderhoudbaarheid (maintainability) van de software?
• Is er nieuwe software gecommit die minder testdekking heeft?
• Zijn er mogelijke beveiligingsrisico’s gesignaleerd op de huidige broncode?
• Hoeveel technische schuld heeft het project op dit moment?
• Zijn de huidige images van de containers die naar productie gaan zonder bekende kwetsbaarheden (CVE’s)?

Naast het weergeven van informatie in een actuele, bewerkbare, online rapportage biedt Quality-time de mogelijkheid om de gebruikers proactief te waarschuwen door berichten uit te sturen. De meldingen die Quality-time uitstuurt zijn uitvoerbare acties (actionable).

Allerlei rollen binnen het project kunnen hier hun informatie uit halen. Op basis van de meldingen in Quality-time kan het team de product owner adviseren over de prioriteiten van de komende sprint en/of release. Ontwikkelaars en testers kunnen op basis van deze meldingen hun acties en taken voor deze dag of sprint bepalen en een kwaliteitsmanager of testmanager weet in een oogopslag waarop deze moet sturen.

Onderstaande afbeelding geeft een screenshot weer van een dashboard gemaakt in Quality-time. Naast een samenvatting van de staat van de projecten, weergegeven in de meest linkse cirkeldiagrammen, wordt er in de ander cirkels per kwaliteitsaspect aangegeven hoe het de software en het team hierop scoort.

Ieder cirkeldiagram is ook een link naar een onderliggende pagina die meer verdieping geeft.
Wanneer we in willen zoomen op de onderhoudbaarheid om te weten hoe de score is opgebouwd dan kan de gebruiker klikken op dit diagram en zal het overzicht eruit zien zoals onderstaande afbeelding.

In bovenstaand dashboard kan de gebruiker zien dat er mogelijke kwetsbaarheden op gebied van security in de broncode zijn ontdekt. En kan direct vanuit Quality-time een user story of taak worden aangemaakt op de backlog zodat dit snel opgelost kan worden door het team.
De grenswaarden die zijn ingesteld per metriek zorgen ervoor dat de meetwaarden groen, geel of rood worden. Ook kan worden ingesteld dat er direct een melding wordt verstuurd naar bijvoorbeeld een Teams-kanaal.

Heilige graal?

Lost dit de problemen op? Kortgezegd: nee, het installeren van een tool lost niets op. Doel en middel moeten niet worden verward.

Allereerst is het belangrijk dat de nodige tests en scans daadwerkelijk zijn ingericht in de ontwikkelpijplijn anders is Quality-time een leeg dashboard. Maar hoe weten de ontwikkelaars wat er nodig is? Dit kan alleen als er afspraken gemaakt zijn over de kwaliteit, de kwaliteitseisen en als het team zich verantwoordelijk voelt voor de kwaliteit. Hierover zal ik uitweiden in een volgend blogartikel.

Slot

Het installeren van een vernieuwende tool alleen zal de wereld niet veranderen. Toch geloof ik dat Quality-time helpt bij een bewustwording van het ontwikkelteam en product owner.

Het is open-source en relatief eenvoudig om te installeren. Daarna kan het team stapsgewijs het dashboard uitbreiden om meer inzicht te krijgen. Direct een big-bang organisatorische veranderingen is hiervoor niet nodig.
Vanaf het aansluiten van de eerste bronnen zullen er meldingen verschijnen die inzicht geven. Vanaf dat moment kan het team en de product owner dus vroegtijdig gaan bijsturen op kwaliteit.

Het unieke van the/experts. is dat we zowel expertise hebben op gebied van softwareontwikkeling als kwaliteitszorg in de IT. Fuller-stack noemen wij dat. Dit betekent dat wij niet alleen tot de kern van de problemen komen, maar het ook kunnen oplossen. Wij accelereren uw digitalisering.

Herkent u bovenstaande perikelen? Wilt u inzicht in softwarekwaliteit? Wacht dan niet en neem contact op.

Ontdek waarom wij onszelf the/experts noemen.
Zelf aan de slag met Quality-time? Start hier.