Waarom productkwaliteit altijd een gezamenlijke verantwoordelijkheid moet zijn

Denk bijvoorbeeld aan apps. Uit onderzoek blijkt dat meer dan 70% van de apps gemiddeld maximaal 90 dagen wordt gebruikt. Naadloze gebruikerservaringen, snelle laadtijden en apps zonder bugs zijn daarom belangrijker dan ooit tevoren. Maak van kwaliteit een integraal onderdeel van je ontwikkelproces.

De evolutie van Quality Assurance (QA)

Hoeveel testers heb je nodig om er zeker van te zijn dat je een kwalitatief hoogwaardig product produceert? Het ligt eraan aan wie je deze vraag stelt. In sommige organisaties is de verhouding tussen developers en testers 5 op 1, maar in andere organisaties komt deze verhouding meer in de buurt van 2 op 1. QA-engineers worden vaak gezien als personen die niets anders doen dan tests schrijven en uitvoeren. Dit is niet zo verwonderlijk als we kijken naar de traditionele watervalmethode die bij softwareontwikkeling veel wordt gebruikt.

In dit model komt het product bij testers terecht nadat de developers hun werk hebben afgerond. De testfase is dus een afzonderlijke fase. Zoals je je kunt voorstellen – en wellicht heb je dit zelf ooit meegemaakt – heeft deze methode een aantal grote nadelen:

Het feedbackproces verloopt traag. Bewaar je het testen voor het laatst? Dan loop je het risico dat grote fouten in je product pas laat in het ontwikkelproces worden ontdekt. Het product moet weer terug naar de developers, waardoor de marktintroductie vertraging oploopt. Het tegenovergestelde probleem bestaat ook:de deadline is belangrijker dan de kwaliteit en het testen wordt overhaast uitgevoerd of zelfs helemaal overgeslagen. Bugs en andere problemen worden pas na de release ontdekt. Dit is schadelijk voor de reputatie van het product.

Er is geen gezamenlijke verantwoordelijkheid. Het spreekt voor zich dat je met het op tijd opsporen van fouten en bugs veel tijd – en daarmee ook geld – bespaart. Maar zolang de ontwikkel- en testfase twee afzonderlijke fasen zijn, lopen developers de cruciale input mis die zij vooraf van de QA engineer horen te ontvangen. Zo voorkom je mogelijke problemen die later tevoorschijn zouden komen en hoeft de developer minder kritisch naar zijn werk te kijken omdat deze input al verkregen is.

Agile-methoden

Als alternatief voor de watervalmethode wordt vaak gekozen voor Agile methoden. Gary Hamel merkte ooit op: "Zonder mensen met aanpassingsvermogen kun je geen aanpassingsbereide onderneming opbouwen. Mensen veranderen echter alleen wanneer zij daartoe gedwongen zijn, óf als ze het zelf willen." Ondanks pogingen van een organisatie om agile te werken, vallen mensen vaak terug in oude gewoonten. Daardoor gaat het ontwikkelproces op een incrementeel watervalmodel lijken. Nog steeds vindt er tijdens de ontwikkeling van features weinig interactie en samenwerking met de QA-engineers plaats en wordt het project aan het einde van het ontwikkelproces nog 'gewoon' op de oude manier overgedragen.

Hoewel deze aanpak wel enkele tekortkomingen van het watervalmodel oplost – de feedbackloops zijn korter en het testen van features is beter afgestemd op de ontwikkeling ervan – zijn er toch nog steeds problemen:

• Het oplossen van problemen kost veel tijd. Features worden nog steeds pas getest nadat ze zijn ontwikkeld. Het feedbackproces is korter, maar wanneer QA aangeeft dat er een probleem is met een feature, moeten developers hun huidige werk onderbreken om het probleem met deze feature op te lossen.
• Afhankelijkheid belemmert de voortgang. Developers en QA-engineers zijn afhankelijk van elkaar en moeten op elkaar wachten om voortgang te maken.

QA en development zijn in de loop van de tijd dichter bij elkaar gekomen door veranderde interpretaties over agile werken. Enkele praktijkvoorbeelden hiervan zijn:

• QA-engineers schrijven de testscripts voor een functie terwijl de ontwikkeling nog in volle gang is.
• Test Driven Development (TDD) wordt gebruikt, waarbij de tests aansluiten bij de ontwikkelde code.

Beide processen verkorten de doorlooptijd van de tests en zorgen ervoor dat het testen beter wordt geïntegreerd in de productontwikkeling. In geen van beide gevallen is de QA-engineer echter onderdeel van een lean werkend productontwikkelingsteam. Ook draagt in deze situaties niet het gehele team de verantwoordelijkheid voor de algehele kwaliteit van het product.

Een QA-mindset integreren in productontwikkeling

In de Foundation-opleiding van de International Software Testing Qualifications Board (ISTQB) wordt de mindset van testers en developers besproken. Testers en developers hebben namelijk een verschillende mindset.

"De mindset van een tester moet de volgende kenmerken hebben: Nieuwsgierigheid, Professioneel pessimisme, Een kritische blik, Aandacht voor detail, Enthousiasme voor goede en positieve communicatie en relaties."

“De mindset van een developer bevat enkele van bovengenoemde aspecten van de mindset van een tester, maar succesvolle developers zijn vaak meer geïnteresseerd in het ontwerpen en bouwen van oplossingen dan in het nadenken over wat er mis zou kunnen zijn met die oplossingen."

Bron: ISTQB syllabus

Het overbruggen van de kloof tussen de werkwijze van developers en QA-engineers begint met het integreren van de QA-mindset in het productontwikkelingsproces.

Samen verantwoordelijk voor kwaliteit

De meeste problemen ontstaan door gebrekkige communicatie. De algehele kwaliteit gaat omhoog als inzichtelijk wordt gemaakt op welke momenten in het ontwikkelproces developers, QA-engineers en andere teamleden met elkaar communiceren en in welke mate zij worden gestimuleerd om samen te werken.

Eerder in dit artikel bespraken we de ontwikkeling van QA en we zagen toen dat er vaak pas aan het einde van een taak wordt gecommuniceerd. Wanneer een developer zijn of haar deel van een taak af heeft, moet er overleg met de QA-engineer plaatsvinden. De developer geeft een samenvatting van het betreffende onderdeel, zodat de QA-engineer hiermee aan de slag kan. Andersom geldt uiteraard hetzelfde. Met het oog op een betere relatie en communicatie is het van belang dat er meer wordt samengewerkt. Vaak begint dit met het analyseren van teamstructuren en verantwoordelijkheden.

In traditionele engineeringteams zijn er meestal specialisten voor elk afzonderlijk gebied. Een workflow loopt bijvoorbeeld via de volgende stations: architect - database-expert - front-end developer - back-end developer - QA-engineer.

Wanneer je van QA – of een willekeurige andere taak binnen het team – een apart specialisme maakt, creëer je verschillende verantwoordelijkheden. Daardoor ontstaat er onduidelijkheid en misschien ook onenigheid binnen het team over wie de problemen binnen een bepaald onderdeel van een project moet oplossen. Bij een omvangrijk probleem zijn mensen minder snel geneigd om uit hun comfortzone te stappen en te helpen dit probleem op te lossen. Bovendien wordt het leveren van kwaliteit nog als een aparte stap beschouwd of als een taak die erbij komt doordat QA-engineers hun expertise binnen het team delen.

Een betere aanpak is dan ook het samenstellen van kleine multidisciplinaire teams, waarbinnen personen van veel zaken kennis hebben, maar expert zijn op slechts één gebied. Dit wordt ook wel T-shaped genoemd. Alle teamleden delen nog steeds hun expertise of brengen een bepaald gebied onder de aandacht, maar het team als geheel draagt de verantwoordelijkheid voor een specialisme. In teams die op deze manier functioneren, wordt kwaliteit – net als alle andere aspecten – een gezamenlijke verantwoordelijkheid. Best practices op het gebied van QA worden al vanaf de start toegepast. Developers en QA-engineers werken tegelijkertijd aan het verbeteren van de kwaliteit van het product.

Hoe dit in de praktijk vorm krijgt

Een productontwikkelingsteam wordt gevormd door een kleine groep van developers, designers en QA-engineers die allemaal input leveren en ondersteuning bieden op basis van hun specialisme.

Alle teamleden zijn tijdens de hele levenscyclus van een functie aanwezig en beslissen mee over verwacht gebruikersgedrag en resultaten. Dit geldt zowel voor situaties waarin alles meteen werkt zoals verwacht als voor situaties waarin dit niet het geval is. Er zijn geen overdrachten, geen knelpunten in de communicatie, beslissingen worden snel genomen en er wordt snel vooruitgang geboekt.

Voorafgaand aan de werkzaamheden worden de werkwijzen bepaald, waarna testscenario's worden gemaakt in de vorm van acceptatiecriteria. Aan de hand hiervan schrijven developers functionele regressietests (evenals unittests en integratietests). Iedereen is in staat tests uit te voeren en kwaliteitscontroles te implementeren, wat de algehele productkwaliteit ten goede komt.

QA-engineers bewaken de kwaliteit, geven sturing, kennen de best practices op het gebied van QA en stellen alle teamleden in staat om zelf QA-vaardigheden aan te leren of deze verder te ontwikkelen. Het resultaat is een team dat betere beslissingen neemt op het gebied van softwareontwikkeling.

Conclusie

De eenvoudigste en meest kosteneffectieve manier om de kwaliteit van je eindproduct te waarborgen, is door best practices op QA-gebied vanaf de start in het project te integreren. De rol van QA-engineer is weliswaar een specialistische functie, maar deze engineers voegen de meeste waarde toe wanneer zij binnen een breder team werken om van kwaliteit een gezamenlijke verantwoordelijkheid te maken.