Dit is slechts één voorbeeld van gebrekkige software. Elke dag gebeuren er talloze andere incidenten in verschillende sectoren.

Natuurlijk zouden velen van ons met de vinger naar het QA-team hebben gewezen omdat ze niet goed hadden getest, omdat zij altijd werden gezien als de bewakers van de kwaliteit.

Maar geldt dat ook voor dit scenario? Is het schuldvraagstuk eigenlijk wel van toepassing op een dergelijk scenario in de huidige levenscyclus van agile softwareontwikkeling?

Het antwoord is nee.

Bij Zuci werken we met klanten uit verschillende sectoren voor advies over softwarekwaliteit en we hebben een gemeenschappelijk patroon opgemerkt: Kwaliteit wordt beperkt tot het domein van de QA-teams.

In deze editie van Z to A Pulse willen we het dus hebben over het nemen van een

Hallo lezers, Welkom! Deze editie van de maandelijkse nieuwsbrief Z to A Pulse wordt u aangeboden door Keerthi V, marketingstrateeg bij Zuci Systems.

Punt 1:

Bij een van de recente opdrachten werkte Zuci Systems samen met een klant die actief was in de e-commerce. Deze klant leverde oplossingen voor postbedrijven, koeriers en logistieke organisaties wereldwijd. Ze speelden een cruciale rol bij het leveren van een verbeterde retail- en digitale klantervaring, het mogelijk maken van nieuwe inkomstenstromen en het optimaliseren van de leveringskosten.

Het enorme volume aan transacties dat hun software dagelijks verwerkte was duizelingwekkend. Het was duidelijk dat het succes van hun bedrijf afhing van het uitbrengen van betrouwbare software in de handen van tevreden gebruikers.

Om een naadloze gebruikerservaring te kunnen bieden, had de klant duidelijkheid over de hiaten in de kwaliteit van het product en zocht hij naar manieren om hun QA-processen in hun teams te verbeteren.

Ze wilden een ervaren, onafhankelijke derde partij om een gap-analyse uit te voeren van hun huidige QA-inrichting en -processen en verbeterpunten aan te dragen en toen kwam Zuci in beeld.

Het was een interessante ervaring van 8 weken omdat we diep in hun applicatiesuite doken, niet alleen vanuit een QA-standpunt maar ook vanuit het perspectief van software engineeringprocessen, waarbij we in vogelvlucht hun architectuur, code, infrastructuur en andere relevante gebieden bekeken.

Het resultaat van onze inspanningen was een rapport van 56 pagina’s – een geconsolideerd overzicht van onze benadering van kwaliteit, dat alles omvatte van vereisten tot vrijgave. Het gaf onze klant een routekaart voor verbetering, met de nadruk op gebieden waar ze hun processen konden verbeteren en een hogere kwaliteitsstandaard konden garanderen.

Geïnteresseerd in het rapport? Geef een seintje op sales@zucisystems.com

Bij Zuci geloven we in

Kwaliteit is ieders verantwoordelijkheid

Daarom willen we bij elk advies of elke gap-analyse eerst inzicht krijgen in de “kwaliteitscultuur” bij de klant.

Want goede softwarekwaliteit betekent niet alleen kijken naar testen. Het gaat erom de onderzoekshoed op te zetten en dieper in de software te graven om de onbekenden bloot te leggen.

Bij gap-consultancyopdrachten verdelen we onze aanpak in twee delen: Testprocesbeoordeling en Engineeringprocesbeoordeling. Hierdoor kunnen we alle praktijken die worden gevolgd in de Software Development Life Cycle (SDLC) uitgebreid evalueren.

Binnen de Testprocesbeoordeling richten we ons op drie belangrijke gebieden:

1. Test techniek
2. Testbeheer
3. Testbeheer en naleving.

Voor deze klant analyseerden we gegevens uit JIRA, over een periode van 12 tot 14 maanden, om cruciale meetgegevens te meten en de volwassenheid van de processen van de klant in te schatten.

Enkele bevindingen waren:

• Het belang van een E2E-teststrategie definiëren
• De “Definition of Done” voor een user story vaststellen
• Zorgen voor traceerbaarheid van vereisten naar code via tools als JIRA, Bitbucket en Azure DevOps
• De noodzaak van TDD benadrukken
• Het belang van speciale testomgevingen benadrukken
• Analyse van de hoofdoorzaak

Om deze bevindingen beter te begrijpen, heb ik contact opgenomen met Dhanalakshmi Tamilarasan, SDET-manager bij Zuci Systems.

Keerthi: Waarom is een goed ontworpen E2E-teststrategie belangrijk?

Dhana: Het doel van een end-to-end (E2E) strategie is om duidelijk te definiëren en te ontdekken hoe een product zich gedraagt, zowel wat betreft de functionaliteit als de niet-functionele aspecten. De teststrategie moet een levend document zijn en regelmatig op een consistente manier met het hele team worden besproken.

Een goed gedefinieerde teststrategie legt de richtlijnen vast voor de manier waarop we testen benaderen om onze testdoelen te bereiken en de verschillende soorten tests uit te voeren die we in ons testplan hebben staan. Het omvat verschillende aspecten zoals testdoelstellingen, benaderingen, testomgevingen, automatiseringsstrategieën en hulpmiddelen, evenals een risicoanalyse met een noodplan.

In een notendop dient de teststrategie als een actieplan om de overkoepelende productvisie te realiseren.

Keerthi: Volgen we bij Zuci best practices voor het ontwerpen van een effectieve teststrategie?

Dhana: Een paar best practices die hier worden gevolgd zijn:

• Brainstormsessies met teams over alle aspecten van testen voordat je tot een teststrategie komt
• Intercollegiale toetsing van teststrategie met collega-leads
• Gedetailleerde review en aftekenen van teststrategie door MKB’s en producteigenaren

Keerthi: Wat zou een ideale “Definition of Done” voor een user story moeten zijn?

Dhana:

Volgens Scrum.org is een definitie van klaar (DoD) een gedeeld begrip van de verwachtingen waaraan de huidige sprint (of increment) moet voldoen om te worden vrijgegeven aan gebruikers.

De Definition of Done is een afgesproken set regels/checklists die moet worden ingevuld voor elk werkitem in het team/de release.

Doelen van DoD:

• Het gemeenschappelijke begrip over kwaliteit en volledigheid opbouwen
• De checklist met criteria definiëren om te controleren in elke user story
• Zorgen voor de verzending van het overeengekomen increment

Enkele voorbeelden van DoD, maar niet beperkt tot

• UT-dekking van elke module moet aan X % voldoen voordat PR wordt verhoogd
• Alle ontwikkelde modules moeten het gedefinieerde CICD-proces volgen
• Min X % van in sprint te bereiken automatisering
• Geen bugs van prioriteit 1 & 2 in de functionaliteiten
• Aan niet-functionele vereisten voldaan
• Gebruikersdocument bijgewerkt

Keerthi: Waarom is traceerbaarheid van vereisten naar code via tools als JIRA, bitbucket en Azure DevOps noodzakelijk?

Dhana: Traceerbaarheidsmatrix speelt een belangrijke rol om de volgende belangrijke aspecten te bereiken

• Om de testdekking van elke functie/gebruikersverhaal te garanderen en de juiste dingen te kunnen testen
• Eenvoudiger triage van defecten, RCA en impactanalyse mogelijk maken
• Herwerk verminderen door de defecten en traceerbaarheid intact te houden als een kennisrepo

Keerthi: Wat is TDD en wat maakt het voor verschil?

Dhana: Testgestuurde ontwikkeling (TDD) is een softwareontwikkelingsproces dat berust op de herhaling van een zeer korte ontwikkelcyclus: eerst schrijft de ontwikkelaar een falende unit testcase die een gewenste verbetering of nieuwe functie definieert, vervolgens produceert hij de minimale hoeveelheid code om die test te doorstaan en ten slotte refactureert hij de nieuwe code naar aanvaardbare normen.

TDD is belangrijk omdat het ervoor zorgt dat software wordt ontwikkeld met kwaliteit en betrouwbaarheid in het achterhoofd. Door tests te schrijven vóór de code, worden ontwikkelaars gedwongen om na te denken over het ontwerp van hun code en hoe deze zal worden gebruikt. Dit kan leiden tot meer modulaire, herbruikbare en testbare code. Bovendien kunnen TDD-tests worden gebruikt om defecten vroeg in het ontwikkelingsproces op te sporen, wat op de lange termijn veel tijd en geld kan besparen.

Keerthi: De meeste teams hebben geen speciale testomgeving. De meeste tests worden door de ontwikkelaars zelf uitgevoerd in hun lokale omgeving – Waarom is dat een slechte gewoonte?

Dhana: De uitdagingen van het gebrek aan specifieke testomgevingen zijn:

• De ontwikkelomgeving heeft vaak gemockte gegevens of onvolledige code/build die niet de uiteindelijke build zal zijn om te testen
• Geen vertrouwen geven in testdekking en kwaliteit
• Defecten reproduceren zal een uitdaging zijn
• Leidt tot meer herbewerking
• Voortdurende wijzigingen in de build tijdens de ontwikkeling maken testen moeilijk

Keerthi: Hoe voer je een RCA uit? Kun je een sjabloon delen?
Dhana:

De RCA wordt uitgevoerd door alle teamleden te laten deelnemen aan een vergadering of gesprek om elk defect te beoordelen. Meestal wordt de 5 WAAROM-techniek gebruikt om de hoofdoorzaak te bepalen, hoewel er ook andere methoden beschikbaar zijn.

Momenteel wint RCCA (Root Cause and Corrective Action) aan belang. Tijdens hetzelfde gesprek identificeren we niet alleen de hoofdoorzaak, maar bepalen we ook corrigerende maatregelen. Dit is cruciaal om te voorkomen dat het probleem zich opnieuw voordoet.

RCCA wordt gedaan in 2 delen

1.Waarom is het geïnjecteerd?

Dit is om de oorzaak van het defect te achterhalen dat vanuit de ontwikkeling wordt geïntroduceerd.

2. Waarom is het niet gedetecteerd?

Dit is om vast te stellen waarom het defect onopgemerkt is gebleven tijdens het testen, of dit nu tijdens UT- of functionele tests was.

Hier is een voorbeeld van een RCA-sjabloon

Dat gaat vooral over de beoordeling van het testproces. We zullen in de komende edities meer vertellen over de beoordeling van het engineeringproces. Blijf op de hoogte!

Vraag voor jou:

Wat betekent kwaliteit voor elk team in de SDLC?

Bedankt voor het lezen!

Laat ons je opmerkingen of suggesties hieronder weten. Schrijf u in om toekomstige edities te ontvangen met de meest opwindende onderwerpen over engineering excellence.

Als je onze inhoud leuk vindt, toon ons dan je steun door je hier in te schrijven voor onze driemaandelijkse nieuwsbrief, Sound bytes.

Perfectie. Altijd.