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 dit derde deel (van in totaal vier artikelen) zal duidelijk blijken dat zij een cruciale rol vervult in het tijdig en met de juiste kwaliteit opleveren van producten en diensten.
Schade of impact
We hebben in het voorgaande al kort het testen op basis van risico’s benoemd. Omdat dit cruciaal is voor het vormgeven van testen, diepen we deze graag iets verder uit.
Natuurlijk weten we al langer dat het onmogelijk is ‘alles’ te testen en dat er gefocust moet worden op die zaken die – als ze misgaan – de meeste schade of impact hebben.
Als we dit vertalen naar de huidige tijd waarin de fasering van activiteiten niet meer zo strikt gescheiden is, kunnen we ons ook afvragen waarom we de risico’s pas in dit late stadium willen meenemen. Als we immers al weten wat de risico’s zijn die we lopen met een product, waarom zouden we deze informatie dan niet meteen meenemen tijdens de ontwikkeling van de applicatie of misschien zelfs al bij de keuze van de architectuur? Door het risicoprofiel van een applicatie te bepalen in een riskstormsessie (waarbij met het hele team gekeken wordt welke risico’s er optreden als de te bouwen software niet aan alle kwaliteitseisen voldoet) kunnen we hier beter mee omgaan. Deze sessies hebben het meeste effect als ze gedaan worden met het gehele team zodat de risico’s die geïdentificeerd worden ook door de hele groep gedragen worden. Het risicobesef wordt op deze manier ook binnen de hele groep ‘geïnstalleerd’.
Groepsverantwoordelijkheid
Vertalen we dit naar concrete stappen binnen een agile proces, dan zouden we bijvoorbeeld in een refinement-sessie al kunnen bepalen welke risico’s door een bepaalde user story geïntroduceerd zouden kunnen worden of welke reeds eerder geïdentificeerde risico’s door een user story vergroot of misschien juist gemitigeerd worden.
Door de risicoanalyse met het hele team uit te voeren, is ook de kennis van de risico’s gedragen door het hele team en kan het omgaan met deze risico’s ook een groepsverantwoordelijkheid worden.
De grote(re) kracht van de risicoanalyse wordt nu dat in een vroeg stadium nagedacht kan worden over architectuurkeuzes; iets wat als de bouw eenmaal begonnen/afgerond is vaak maar moeilijk te veranderen valt.
In de praktijk blijkt dat (het faciliteren van) product risico analyses geen sinecure is. Het denken in risico’s is een vaardigheid waar de tester zich mee kan onderscheiden, waarbij in een echt multidisciplinair team thread modelling mee is te nemen als een van de kwaliteitsaspecten. Voor de volledigheid: threat modeling is een proces waarbij potentiële bedreigingen, zoals structurele kwetsbaarheden of de afwezigheid van passende veiligheidsmaatregelen, kunnen worden geïdentificeerd en mitigerende maatregelen kunnen worden geprioriteerd.
De twee centrale vragen in deze zijn al mooi verwoord door Fiona Charles tijdens haar keynote op Eurostar 2019, namelijk: ‘What could possibly go wrong?’ en ‘Do we really want to do this?’.
Het herhaaldelijk stellen van deze vragen in de stadia van de softwareontwikkeling, maar voornamelijk aan het begin, kan veel problemen in een later stadium voorkomen. Hierin moeten – zeker bij de tweede vraag – goed de potentiële benefits afgewogen worden tegen de mogelijke nadelige consequenties. Deze ’negatieve’ insteek zal niet altijd van harte gekoesterd worden, maar is wel van cruciaal belang.
Oneigenlijke wijze
Om de nadelige consequenties boven tafel te krijgen, kan ‘malicious engineering’ een belangrijke rol spelen. Dit gaat verder dan de vraag wat er mis kan gaan, omdat dat van toevalligheden uitgaat. Malicious engineering – waarbij actief gezocht wordt naar manieren om een systeem op oneigenlijke wijze te gebruiken – gaat van intentioneel handelen uit en kijkt niet alleen naar potentiële risico’s als er een fout gemaakt wordt tijdens de bouw van de software, maar ook naar de potentiële negatieve neveneffecten van een ‘goed’ werkend systeem. De discipline heeft duidelijke overlappen met ethisch hacken, ofwel het legaal inbreken in computers en andere devices om de bescherming van een organisatie te testen.
Al met al zien we dat de mogelijkheden van risicogebaseerd denken verder reiken dan alleen een manier om test prioritering aan te pakken. Door het nadenken over en afwegen en mitigeren van risico’s een groepsdiscipline te maken zijn grotere voordelen te halen dan door dit te te isoleren tot één discipline.
Testers leveren dus een bijdrage die verder reikt dan alleen testen.
Auteurs: Bart Knaack, Iris Pinkster, Bilal Sabuncu, Veerle Verhagen en Francis Welbie
