Kwaliteit was belangrijk, is belangrijk en zal altijd belangrijk blijven. Een open deur die we gebruiken om onze goede intenties ten opzichte van kwaliteit te uiten. Maar hoe we dat concreet maken en handvatten en inhoud geven, blijft een uitdaging, ook binnen de it. Elke ontwikkelmethode of procesmodel dat gekozen wordt, geeft aandacht aan kwaliteit. Een pijler is het testen.
In dit artikel kijken we naar testen en de veranderingen die daar plaatsvinden. Welke stappen kan een organisatie nemen om testen een blijvend relevante plaats te geven en hoe kan een tester anticiperen en bijblijven? Ook al lijkt een tester vaak een onzichtbare held, in het laatste deel (van in totaal vier artikelen) zal blijken dat hij een cruciale rol vervult in het tijdig en met de juiste kwaliteit opleveren van producten en diensten.
Toegevoegde waarde
Met agile werken zijn we gericht op snel feedback vergaren. Hierbij speelt communicatie een belangrijke rol. Er wordt minder vooraf gespecificeerd en wat de gebruiker wil, wordt kort beschreven in een user story en besproken met het team. En daar heeft de tester direct toegevoegde waarde. Omdat de gebruikers niet altijd helder kunnen uitleggen wat ze willen terwijl het team bouwt wat gevraagd wordt binnen eigen kaders van ervaring en kennis, loopt het team de kans dat de waarde die zij opleveren niet als dusdanig wordt ervaren door de gebruikers. Wanneer een tester betrokken wordt, vermindert dit verschil. Een tester zorgt hierbij voor shared understanding. Meer, testers worden een baken in de chaos en onzekerheid voor alle betrokkenen van het ontwikkelproject, van ontwikkelaars, tot projectmanagers, architecten en product owners
En door het delen van hun ervaringen en kennis ontstaat er iets anders, namelijk het verbeteren van het ontwikkelproces. Immers testers willen niet alleen maar fouten vinden en risico’s inschatten. Ze willen fouten en problemen voorkomen. Dus naast het meedenken met het ontwerp, is het ook handig om een tester mee te laten werken tijdens het ontwikkelen om de code te verbeteren, ook wel pair programming genoemd. Ook kunnen zij testtechnieken introduceren om de geautomatiseerde unit-testen zo effectief mogelijk te maken en de ‘shift left’–filosofie uit te dragen. Deze filosofie streeft ernaar om bevindingen te doen of te voorkomen, en dat zo vroeg mogelijk in het software ontwikkelingsproces. Hiervoor worden alle taken, dus ook testen, zo vroeg als mogelijk in het proces gepland en opgepakt.
Human skills
Om mensen als team te laten werken zijn ervaring en kennis niet voldoende. Human skills zijn hierbij van cruciaal belang. Communiceren binnen een team is belangrijk: snapt iedereen wat er moet gebeuren, stap je naar iemand toe als het even niet duidelijk is en durf je te zeggen tegen iemand in je team dat diegene niet het juiste lijkt te doen?
Open communicatie is belangrijk. De kwaliteit van het product of de dienst zal alleen maar beter zijn als iedereen de eigen insteek en inzichten deel waarbij het hele team aan het werk gaat om kwaliteit zo vroeg mogelijk de benodigde aandacht te geven – een idee waar ook de tester waarde aan hecht. Uiteindelijk zal de samenwerking in een multidisciplinair team leiden tot betere testen en een betere kwaliteit.
Als we al deze onderdelen van de kentering van softwareontwikkeling onder de knie hebben, dan gaan we zeker de juiste producten of diensten opleveren.
Tastbaar
In vier afleveringen hebben we beschreven dat de tester cruciaal is in onze agile manier van werken. Niet slecht voor een onzichtbare held.
Waarom is die held nog altijd onzichtbaar? Mede omdat kwaliteit ook onzichtbaar is. Het is niet concreet en tastbaar. Goede kwaliteit wordt niet als ‘speciaal’ beoordeeld: het voldoet immers aan (onuitgesproken) verwachtingen. Tot het moment dat er een gebrek aan kwaliteit is. Dan worden de gevolgen van het gebrek zichtbaar en voelbaar en weet iedereen te benoemen wat kwaliteit inhoudt.
Bij goede kwaliteit kan de tester veel werk verzet hebben zonder dat dit zichtbaar wordt in het product. De held blijft bij goede kwaliteit onzichtbaar, want het voorkómen van gebreken is niet zichtbaar. Dat maakt de rol van testers kwetsbaar. Ook wanneer het gaat om het meten van productiviteit en efficiëntie van teams valt een tester vaak buiten het meetbare bereik. De tester wordt bij dergelijke metingen al snel gezien als overbodige luxe of een laspost waarop bezuinigd kan worden. En dat is dus niet zo. Integendeel. De onzichtbare held blijft. Voor altijd.
Auteurs: Bart Knaack, Iris Pinkster, Bilal Sabuncu, Veerle Verhagen en Francis Welbie
Side note: het gevaar van het MVP
In de bouw is er een strikte volgorde waarin bepaalde activiteiten uitgevoerd moeten worden. Bij het bouwen van een huis zal niemand beginnen met muren metselen voordat het fundament gestort is. Eeuwenlange schade en schande hebben deze disciplines ingesleten. Door de relatief jonge leeftijd van de softwarediscipline en de schijnbare veranderlijkheid van software, is de noodzaak om vaste volgordes aan te houden minder dwingend. ‘Begin maar vast met die routine te schrijven, die passen we zo wel in’, is een veelgehoorde blunder.
Daarnaast wordt in de agile wereld het minimum viable product (mvp) als principe geïntroduceerd. Een eerste versie van het systeem die gebruikt kan worden om de klantvraag te valideren. En dat is dan ook waar een mvp voor gebruikt moet worden. Het mvp is dan ook meer een rapid prototype (verschillende technieken om snel een schaalmodel van een (deel)systeem te kunnen maken) dan een eerste stap voor de echte ontwikkeling.
Wat steeds vaker gebeurt, is dat – net als bij de rapid prototyping – de software die gebouwd wordt voor het mvp al zoveel werk heeft gekost, dat het niet achteloos weggegooid wordt, maar dat er op doorgebouwd wordt. Hierdoor wordt een raamwerk dat bedoeld was voor het ophalen van customer feedback opeens de basis van de uiteindelijke oplossing.
Net als bij rapid prototyping zijn die eerste houtskoolschetsen niet altijd geschikt om op door te bouwen. Het verdient dan ook strikte aanbeveling om de (technische) kwaliteit van het mvp goed te bekijken en waar nodig te refactoren voordat het mvp als basis voor de verdere ontwikkeling is te gebruiken.
