Vorige maand alweer schreef Venkat Reddy Chintalapudi een post die sinds die tijd in mijn bookmarks staat om er hier nog even op door te gaan. Tester is not a Quality Police, zo luidt de titel van zijn betoog. De discussie over de raakvlakken van testen en kwaliteitscontrole is en blijft actueel in de testwereld en het leuke is dat er zoveel facetten aan kleven dat iedereen wel een beetje zijn of haar gelijk kan halen. Ik pak een paar uitspraken uit de post om er vervolgens een eigen ei over te leggen:
The perception from most of the management is that the Testers are the quality police for the products / projects that they develop… The attitude of acting like a Quality Police for testers is injected by the management from the beginning of their careers… The role of the Tester is to test software, find bugs, report them so that they can be fixed.
De redenatie van Venkat komt kort door de bocht op het volgende neer: wanneer een organisatie geen apart kwaliteitscontrole-team kent, legt het management deze bal bij de tester neer. Er wordt verwacht dat een tester niet alleen de software test, maar tegelijkertijd met een kwaliteitspet op te werk gaat. Hij gaat zelfs zo ver door te veronderstellen dat testers deze missie aan het begin van hun carrière opgelegd krijgen, terwijl daarentegen volgens hem alle betrokken teams verantwoordelijk zouden moeten zijn voor het kwaliteitsgehalte van het eindproduct.
Over die laatste conclusie zijn we het snel eens, maar voor wat betreft die opgedrongen QA-rol heb ik toch het gevoel dat hier wat ontbreekt in zijn verhaal. Ik heb namelijk niet het idee dat een tester die rol hoeft te worden opgelegd, die zou er eigenlijk al (van nature) moeten zijn. Hierbij interpreteer ik overigens het begrip Tester breed, ik versta er dus ook een testmanager of testcoördinator onder.
Waar ik naar toe wil is het zogenaamde donutmodel. Je kunt een donut verdelen in een binnenring en een buitenring. De binnenring kun je zien als het gebied waarop een tester grip heeft, denk daarbij bijvoorbeeld aan teststrategieën, testplannen, testgevallen en rapportages. De tester heeft dit (voor een groot deel) in eigen hand en kan er alles aan doen om deze producten kwalitatief op een hoog niveau te trekken.
Maar bij de buitenring van de donut ontstaat een probleem, helemaal wanneer het eerder genoemde kwaliteitsteam ontbreekt. Daar worden namelijk producten ontwikkeld, plannen bedacht en afspraken gemaakt waar een tester in eerste instantie veel minder grip op heeft. Denk bijvoorbeeld aan een projectopdracht, business requirements en functionele ontwerpen. Zaken die voor een tester echter van cruciaal belang zijn, het is de basis waarop de binnenring voortborduurt.
Het lijkt me daarom sterk (en dat mis ik in het verhaal van Venkat) dat het management die tester een duwtje in de rug moet geven. Dat zou toch onnodig moeten zijn. Die tester zoekt die buitenring echt zelf wel op door zich te bemoeien met de projectplanning, door met een testbril op requirements en ontwerpen te bestuderen en door te trekken aan die acceptatiecriteria. Natuurlijk zou een kwaliteitsteam een mooi steuntje in de rug zijn. Een team dat bijvoorbeeld kijkt naar de manier waarop processen verlopen, naar afgesproken reviewmomenten en naar de kwaliteit van de opgeleverde producten. Is dat team er echter niet, dan zul je in veel gevallen zien dat de tester zelf die pet op zet. Hoe beter de zaken in de buitenring worden geregeld, hoe eenvoudiger het proces in de binnenring verloopt. Dus laat dat duwtje nu maar achterwege, want een goede tester heeft die pet al default in de achterzak zitten.
Technorati Tags: kwaliteitspolitie, donutmodel, Quality Police, testers