In deze blogreeks spreken wij met testprofessionals uit diverse branches. Bij Testersuite horen wij graag de diverse visies op het gebied van testen en wat een testprofessional bezighoudt.
In deze editie van Let’s Talk About Test spreken wij met kwaliteitsexpert Rik Marselis. Principal Quality Consultant bij Sogeti, voormalig voorzitter van TestNet en winnaar van de ISTQB® International Software Testing Excellence Award 2022.
" ...het begint uiteindelijk met de vraag welk probleem wil je oplossen..."
Eerst de standaardvraag: Wie is Rik Marselis?
Dan beginnen we met een standaardantwoord. Mijn naam is Rik en woon in Amstelveen samen met mijn vrouw. Mijn grootste hobby is fotografie en daarnaast ben ik de trotse opa van drie kleinzoons.
Ik werk bij Sogeti als Principal Quality Consultant. Mijn werkzaamheden bestaan uit drie zaken. Als eerste werk ik in opdracht van Sogeti als quality coach en consultant bij klanten. Verder ontwikkel ik trainingen en geef ik trainingen op het gebied van quality engineering & testing. Ook maak ik maakwerk-trainingen naar de behoefte van klanten. Als laatste doe ik research en development op het gebied van kwaliteit en testen. Ik bedenk niet zo zeer nieuwe dingen maar breng bestaande zaken samen waaruit weer iets compleet nieuws ontstaat. Daar vertel ik over in boeken, blogs en podcasts.
Inmiddels heb ik meegewerkt aan 25 boeken waarvan zes boeken met mijn naam erop. Mijn kleinste bijdrage voor een boek is het maken van een foto van de auteurs voor op de achterkant. Het boek Quality for DevOps teams is mijn meest recente en tot dusver grootste publicatie.
Hoe ben je in het vakgebied van Quality Engineering terecht gekomen?
Dat begint in 1980 toen ik werd opgeleid tot programmeur. Je moet iets maken dat voldoet aan wat er gevraagd wordt en ik heb geleerd dat een programma niet af is als er geen testset bij zit. Tegenwoordig gebeurt dat wel eens minder. Ik kom ontwikkelaars tegen die denken dat ze onfeilbaar zijn maar dat is zelden het geval. Gelukkig zijn er ook veel ontwikkelaars die wel begrijpen dat kwaliteit belangrijk is en er getest moet worden.
Software is nu veel complexer dan vroeger. Waarom denkt men dan onfeilbaar te zijn?
We hakken softwareontwikkeling tegenwoordig op in deeldoelen. Hierdoor denkt men al gauw, ‘mijn stukje is af en zo moeilijk was het niet dus het zal wel goed zijn’. Daar gaat het mis. Wanneer er dan fouten gevonden worden wordt er al snel geroepen ‘dat is niet mijn stukje’. Vroeger bouwde je in een klein team een heel systeem en kon je het geheel overzien. Tegenwoordig kadert men te veel af en overziet men de complexiteit niet.
Speelt de business hier ook een rol in?
De business stelt ook vaak onrealistische eisen. Als ik naar de supermarkt ga voor een zak chips dan kan ik tegenwoordig honderd soorten kiezen. Ja dan weet ik het ook niet meer. En als ik een zak chips kies dan is de kans groot dat die de volgende keer er niet meer is. Marketeers denken dat IT alles kan en dus gaan ze de klanten honderd varianten bieden i.p.v. drie. Zo ontstaat complexiteit en daarmee ook fouten.
Ooit was ik betrokken bij een IT-project waarbij developers ervoor moesten zorgen dat oude verzekeringspolissen mee konden worden genomen in een nieuwe applicatie. Dit project zou heel veel geld gaan kosten. Ik heb toen de vraag gesteld welk probleem lossen we nu eigenlijk op? Je kan van alles maken maar wie zit er nu op te wachten? Uiteindelijk bleek een handjevol klanten nog zo’n oude polis te hebben. Het bleek veel goedkoper om deze mensen een ruimhartige aanbieding te doen en de oude polis om te zetten naar een nieuwe polis.
Wat je ook wel eens hoort is dat iemand zegt ‘mijn neefje van 15 maakt dit in een middag’. Ja, alleen weet jouw neefje weet niks van security, netwerksystemen, wetgeving, kwaliteitsattributen, etc…
Mijn punt is, IT kan inderdaad veel maar het begint uiteindelijk met de vraag welk probleem wil je oplossen!
"Gewoon vragen stellen als waarom dan, wie dan en hoe dan."
Wat boeit jou zo binnen het vakgebied van de quality engineering?
Dat zit hem vooral in het feit dat vanuit kwaliteit je veel meer met alle IT-aspecten te maken hebt dan anderen. Bij quality engineering draait het om Product, Proces en People. Deze moeten alle drie op orde zijn om het juiste resultaat te krijgen.
Vanuit qualitiy engineering ben je overal bij betrokken. Een grap die ik wel eens maak is door de vraag te stellen wat QA in het Engels betekent. Iedereen roept dan Quality Assurance. Dat is inderdaad correct maar het betekent ook Question Asker. Dat is het belangrijkste kenmerk van quality engineering. Gewoon vragen stellen als waarom dan, wie dan en hoe dan.
Wanneer ik een quasi domme vraag stel en iemand heeft een goed antwoord, dan weet ik dat die persoon weet waar die het over heeft. Stel ik een vraag en iemand gaat hakkelen dan weet ik dat iemand niet weet waar die het over heeft. Het is ook een kwestie van ervaring waardoor je de juiste antwoorden van de flauwekul antwoorden kan onderscheiden. Als je ouder wordt, besef je dat je niet overal vanaf hoeft te weten om toch een goede bijdrage aan het geheel te leveren.
Wat is de ISTQB eigenlijk?
ISTQB staat voor International Software Testing Qualifications Board. De Q staat niet voor kwaliteit maar voor een kwalificatie die je behaald hebt. Dus ISTQB certifieert mensen in het vakgebied. Je moet examen doen en daarvoor moet je trainingen volgen.
Recent heb je de ISTQB International Software Testing Excellence Award 2022 gewonnen. Wat is dit voor een award?
Het eerste wat ik altijd zeg is dat die toegekend is in plaats van gewonnen. Ik heb er niet speciaal iets voor hoeven doen zoals hardlopen. De award wordt toegekend doordat je iets hebt bijgedragen aan het vakgebied. Het is niet zo dat je denkt ik ga even iets doen om hem te winnen.
In 2022 zijn acht personen door de verschillende internationale ‘boards’ genomineerd. Vanwege bijvoorbeeld de boeken die ik schrijf, mijn presentaties op conferenties en de syllabi waar ik aan bijdraag, vond men dat ik de award toegekend mag krijgen dit jaar. In mei werd dit bekend gemaakt en in oktober wordt hij uitgereikt. Dit gebeurt tijdens de general assembly in Marrakesh.
Wat betekent deze award voor jou?
Vooral een erkenning om trots op te zijn en een stimulans om zo door te gaan. Ik heb niet het idee dat ik iets bijzonders doe maar als niet veel mensen het doen is het dus toch wel bijzonder. Dan is het leuk om erkenning te krijgen. Zo’n award stimuleert om door te gaan. Daarnaast groeit mijn internationale netwerk hier ook door en dat is ook mooi.
"Wist je trouwens dat de basis van TMAP is gelegd door de Tweede Kamer in 1986?"
Kan je ISTQB vergelijken met TMAP?
We zijn TMAP ooit begonnen door praktijkkennis over testen te gaan vastleggen. Deze kennis is men gaan gebruiken voor trainingen en certificaties. Bij ISTQB is het omgekeerd gegaan, zij hebben eerst de exameneisen gedefinieerd en zijn daar trainingen en literatuur bij gaan maken. Het zijn geen concurrenten maar ze vullen elkaar aan, waarbij TMAP wat slagvaardiger is doordat er minder mensen meebeslissen over toevoegingen en wijzigingen. Er is trouwens een gedeelde historie. Toen ISTQB werd opgericht bestond TMAP al zo’n 10 jaar. Een van de schrijvers van het eerste TMAP-boek is Erik van Veenendaal. Hij is ook een grote aanjager van ISTQB geweest.
Wist je trouwens dat de basis van TMAP is gelegd door de Tweede Kamer in 1986? Er was toen een debacle met de belastingdienst(!) en de Tweede Kamer besloot toen dat er een handboek voor testen moest komen. Dit is geëvolueerd tot TMAP.
Loopt Nederland zo voorop met testen?
Nederland is zeker een voorloper op het gebied van testen. Helemaal in de jaren 90 en 00. Ooit heb ik gesproken op een event in Denemarken waarbij ik iets moest zeggen over de toekomst van testen. Men adviseerde mij te vertellen wat we in Nederland deden. Dat was voor het niet Nederlandse publiek namelijk de toekomst. Nog steeds zie je veel Nederlandse sprekers op internationale conferenties. Gezien ons kleine landje is dat toch bijzonder.
Wij komen soms organisaties tegen die testen geen prioriteit geven. Hoe zie jij dit?
Het eerste wat ik altijd vraag is hoe vaak gaat het fout in productie. Als er niks fout gaat dan is het terecht want dan heb je blijkbaar briljante ontwikkelaars. Vaak vindt men het niet waard om te testen. Fouten worden dan gecamoufleerd, weggemoffeld of geaccepteerd. Als er geen geld is voor een briljante IT dan gebeuren veel dingen houtje-touwtje en leeft men er mee. Men maakt de afweging wat voor kwaliteit heb je nodig en hoeveel risico ben je bereid om te lopen? We lossen het wel op als het fout gaat, redeneert men dan.
Wat je ook ziet is dat men kiest voor standaard-pakketten zoals bijvoorbeeld Salesforce of SAP. Dit zijn echter geen standaard-pakketten maar systemen waarmee je het proces bij elkaar kan klikken. Daar gaat het ook vaak fout. Men accepteert dat gewoon nog steeds omdat men er niet goed over nadenkt. De business maakt hier geen lawaai over en accepteert vaak een workaround en er is niemand die het echte probleem oplost.
Als dit soort organisaties vooraf wat meer nadenken over kwaliteit en de teams kwaliteit inbouwen, dan leidt dit tot betere resultaten van de IT-systemen en de organisatie. Zo blijven de testinspanning (en met name al het werk aan het fixen van problemen!!) binnen de perken.
Wat vind jij van de huidige wijze waarop organisaties omgaan met het testen van software?
Daar is niet een simpel antwoord op. Ik observeer twee mogelijkheden. Men vindt kwaliteit belangrijk en kiest voor de juiste aanpak. Dit komt neer op de vraag hoeveel risico wil je lopen? Dat bepaalt de juiste aanpak.
Er zijn ook organisaties die kwaliteit en risico zien als een kostenpost. Als je focust op kosten daalt de kwaliteit. Als je focust op kwaliteit dan dalen de kosten. De kanttekening daarbij is dat de kosten pas na verloop van tijd significant dalen. Je verdient het later terug. Veel organisaties beginnen te laat en roepen ‘het testen is zo duur’. Wat ze bedoelen is dat de bugfixing duur is en niet het testen.
Door te testen laat je zien wat er misgaat en dat oplossen kost geld. Het testen zelf is niet zo duur. De kosten gaan voor de baat uit. De wet van Boehm loopt hier parallel aan. Men wil vaak tijd besparen aan het begin van een project door niet te reviewen. Als problemen dan verderop aan het licht komen is het vaak te laat. Dan gaat het herstellen daarvan veel geld kosten.
"Testersuite geeft mensen structuur."
Hoe kijk jij aan tegen een testmanagement tool als Testersuite?
Veel mensen hebben belang bij structuur. Testersuite geeft mensen structuur. Veelal is men zelf niet in staat om de structuur te maken. Daar zit een groot voordeel van Testersuite. Daarnaast is Testersuite laagdrempelig en dat maakt dat het helpt om het geaccepteerd en geïmplementeerd te krijgen.
Welk advies geef je het Testersuite Team mee?
Houdt vol om de tool niet te complex te maken. Steeds meer mensen willen dingen erbij en dat moet je in de perken houden. Testersuite blinkt uit doordat het hanteerbaar is. Als je het complex maakt dan haal je een van de belangrijke succesfactoren onderuit.
Welk advies geef jij de testmanager mee?
Een goede testmanager begint met eerst te bedenken hoe en wat hij aan het eind moet rapporteren. Als je weet wat de stakeholders willen weten, kan je daar je activiteiten op afstemmen. Tip daarbij is, maak nooit een eindrapport maar een voortgangsrapport waarbij je laatste voortgangsrapport ook je eindrapportage is.
