Auteur: Rik Marselis ● rik@marselis.eu
Redactie: Eric Spaargaren en Frits Iddekinge
Het was in 2018 dat ik voor het eerst de term quality engineering hoorde.
Geen idee wat het betekende. Het klonk vooral als een brede term.
Kortgeleden sprak ik een vakgenoot die zei ‘Ach joh, quality engineering wordt gewoon gebruikt als hippe term voor testen!’
Hoe zit het nou echt? In 2018 waren we met een groepje mensen bezig om het TMAP boek ‘Quality for DevOps teams’ te schrijven. Dat werd trouwens het eerste TMAP boek waar niet ‘testen’ maar ‘kwaliteit’ in de titel staat.
In de huidige agile wereld zonder duidelijk onderscheid in functies vragen opdrachtgevers
zich al snel af of testers nodig zijn. In plaats van in een enorme discussie over het nut van
testen te duiken, gooien we het over de ‘kwaliteits-boeg’. We vragen de opdrachtgever: ‘Is
kwaliteit belangrijk? Zo ja, wanneer is de kwaliteit goed genoeg?’
Met de beschrijving van ‘goed genoeg’ kunnen wij als IT-ers vervolgens beoordelen welke
activiteiten nodig zijn om dat niveau van kwaliteit te halen. En daaruit volgt dan welke kennis
en vaardigheden er in het team moeten zijn.
Om even met een extreem voorbeeld te beginnen: Als het niet uitmaakt of het IT-systeem
goed werkt of niet (dus lage kwaliteit is geen probleem), dan kun je met weinig kennis en
ervaring in het team, prima aan de verwachtingen voldoen, je bouwt maar wat en je kunt
testen achterwege laten.
Maar als de doelen voor kwaliteit wat hoger liggen, dan moet je als IT-delivery team(s) aan
de slag om de juiste kwaliteit in te bouwen en te laten zien dat het beoogde kwaliteitsniveau
gehaald is.
Deze benadering van ‘kwaliteit definiëren, kwaliteit bouwen, informatie over kwaliteit
geven’ is de kern van wat we vandaag vatten onder ‘quality engineering’. Het uitgangspunt
is dat we de kwaliteit bouwen die gevraagd is en dat we door middel van testen laten zien
of dat gelukt is. Als de kwaliteit op het juist niveau is, dan voldoet het team aan de
acceptatiecriteria en zijn ze dus klaar.
Is testen dus nog belangrijk? Jazeker! Door te testen toont het team aan dat de kwaliteit
goed genoeg is. En als tijdens het testen blijkt dat de kwaliteit nog niet goed genoeg is, tja
dan is er dus nog werk aan de winkel.
Wat betekent het dan voor jou?
Als jij nu ‘tester’ bent, moet je dan wat anders gaan doen?
De pure focus op testen als een los vakgebied, zoals we dat meer dan een decennium geleden
vaak zagen, bijvoorbeeld met aparte ‘geoutsourcede’ systeemtestteams, dat zien we niet
meer. Het realiseren van de juiste kwaliteit op het juiste moment is de verantwoordelijkheid
van het agile team. Binnen het agile team heb je een scala aan kennis en vaardigheden nodig
en zullen de teamleden diverse rollen vervullen. Op het ene moment bouwt iemand code en
op het andere moment is zij betrokken bij testwerkzaamheden, om daarna nog wat
beheerwerk te doen. Maar dat wil niet zeggen dat iedereen een expert in alles moet zijn. De
bedoeling is dat alle teamleden samen de juiste kennis en vaardigheden hebben en dat ze
bij het vervullen van diverse rollen zo op elkaar inspelen dat ze tot de juiste resultaten
komen. Hierbij is het prima dat het ene teamlid beter is in programmeren en het andere
teamlid beter is in testen. Dus wordt een tester dan een quality engineer? Jazeker. Maar ook een programmeur wordt een quality engineer. En binnen quality engineer heb je verschillende nuances, iedereen kan overal bij betrokken zijn maar de ene persoon is beter in bouwen en de ander in testen en weer een ander is beter in beheertaken.
In TMAP is quality engineering helemaal ingebed (zie bijvoorbeeld de definitie in de glossary:
https://www.tmap.net/page/tmap-glossary-online
En ISTQB dan? Ook binnen die gelederen dringt steeds meer het besef door dat het testvak
geen eiland is. Dat blijkt bijvoorbeeld uit de titel van de nu in ontwikkeling zijnde DevOps
module die ‘ISTQB – Quality in DevOps’ heet.
Mijn tip aan jou: verbreed jezelf! Zorg dat je wat afweet van programmeren, gebruik
verschillende tools om je te ondersteunen in je werk (ja, ook GenAI !!), en wees vooral
nieuwsgierig naar wat er om je heen gebeurt en wat je daarvan kunt leren.
Veel succes en plezier met quality engineering !!
Rik Marselis