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
Quality engineering is inderdaad een veel bredere term, testen is een middel erin. Maar kwaliteit moet je engineeren van begin tot eind. Dus onder andere;
– Architectuur review; als het kan voor je echt begint, denk aan performance, stabiliteit , uitwijk en schaalbaarheid, want dat fix je achteraf niet even
– Code kwaliteit, reviews en code checks (linting, PMD, SonarQube, etc.) allemaal middelen om kwaliteit tijdens dev te bewaken.
– Efficiency, profiling en capacity management; hoe draai je met zo min mogelijk resources, duurzaam en kostenbesparend
– Testen, mits er requirements zijn en risk based
– Monitoring, bewaken van de kwaliteit in productie, bij voorkeur met middelen welke vanaf design zijn meegebouwd, je bewaking opleveren als deelproduct van je deliverable, denk bijvoorbeeld aan OpenTelemetry. En ook dat moet getest worden want levert dit het inzicht in wat je in productie nodig hebt om een root cause te vinden als iets mis gaat.
En daarnaast zijn er nog allerlei tools voor Chaos Testing, een andere term sterk gerelateerd aan Quality engineering is Site Reliability Engineering https://sre.google/
Dus eens, we moeten ons zeker niet alleen tot testen beperken. dat is eigenlijk maar een klein deel van al het moois wat er op kwaliteit te doen is.