Binnen (ICT)organisaties en bedrijven, wordt vaak aangenomen dat de tester verantwoordelijk is voor de kwaliteit van de opgeleverde software. Maar is dat werkelijk zo? In projecten stellen projectmanagers vaak dat testers verantwoordelijk zijn voor de kwaliteit van de software.
Hier ben ik het niet mee eens.

Allereerst moet vastgesteld worden wat met kwaliteit wordt bedoeld. Iedereen heeft namelijk een andere belevenis van wat kwaliteit is. Wat voor de een kwaliteit is, hoeft voor een andere niet zo te zijn.

Veel mensen vinden een iPhone goede kwaliteit hebben, je kunt er mee bellen, app-en, interneten enzovoort. Ze lopen hier letterlijk en figuurlijk mee weg. Mijn grootvader vindt het ondingen. Geef hem maar een telefoon met een draaischijf of met druktoetsen, eenvoudig in gebruik en je hoeft niet gestuurd te hebben om het te gebruiken, vindt hij. Hier heb je een klein voorbeeld van verschil in beleving van kwaliteit.

Volgens de Van Dale is de kwaliteit het volgende: “Bepaalde gesteldheid, hoedanigheid, mate waarin iets geschikt is om voor een bepaald doel gebruikt te worden.”

Dan heb is er nog ISO8402 die het volgende beschrijft:” Het is geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoefte.”
Zo zijn er nog veel meer omschrijvingen van kwaliteit.

Wanneer men in een project over kwaliteit heeft, moet van te voren vast gelegd worden wat men met kwaliteit bedoeld. In mijn betoog om aan te tonen, wie verantwoordelijk is van kwaliteit, ga ik van de omschrijving van de ISO-norm uit.

Vroeger liet ik mijn werkstukken altijd nakijken door mijn ouders. Zij vonden altijd wel fouten. Deze fouten werden dan duidelijk met mij besproken.
Ik leverde mijn werkstukken in. Wanneer ik dan toch hiervoor een onvoldoende kreeg, gaf ik natuurlijk mijn ouders de schuld. Waarom? Omdat zij het niet goed hadden nagekeken… vond ik. Om eerlijk te zijn, was ik gewoon lui geweest: ik was de enige schuldige.

Dit bovenstaande geldt ook voor de testers. Zij worden vaak beschuldigd van het vinden van te veel fouten, verkeerde fouten of het vinden van fouten op een verkeerd moment. Dan is er nog een projectmanager die van mening is dat niet alle fouten hoeven te worden gecorrigeerd, om het product toch op te leveren. Het gevolg: gebruikers komen die fouten in productie tegen.

Een tester heeft over het algemeen geen invloed op beslissingen die genomen worden, om fouten te laten zitten. Het enige wat een tester kan doen, is het vaststellen welke gebreken het product heeft. Het is de projectmanager die verantwoordelijk is voor eindkwaliteit. Hij is de enige die een beslissing kan nemen of fouten hersteld moeten worden of niet. De projectmanager is ook de enige die verantwoordelijk is voor de beslissing om het product op te leveren.

Vaak ontstaan misvattingen doordat managers en andere projectleden de tester verantwoordelijk te stellen voor het ontstaan van de fouten.
Een andere misvatting is dat managers vaak denken dat testers in staat zijn om de kwaliteit te waarborgen en de kwaliteit te kunnen garanderen.

Zoals ik al eerder heb uitgelegd, is een tester niet verantwoordelijk voor kwaliteit, omdat hij geen beslissingen kan uitoefenen. Daarnaast zijn testers niet betrokken bij het programmeren. Zij kunnen niet direct wijzigingen invoeren in de programmacode (broncode). Michael Bolton (www.developsense.com) schreef dat het werk van een tester geen kwaliteitszorg is, maar kwaliteitsondersteuning.

Tot slot is het belangrijk om de taken en de verantwoordelijkheid bij de juiste persoon te leggen. Wanneer de taken en verantwoordelijkheden tevens samenvallen met de doelstelling van de testafdelingen, zal de communicatie zonder ernstige conflicten verlopen.

In mijn volgende blog zal ik aangeven waar de tester wel verantwoordelijk voor is.