Leestijd: 5 minuten
Quality Assurance. Een functietitel die steeds vaker voor komt op de loonstrookjes. Tester, of technische tester, wordt de functie ook wel genoemd. Of gewoon QA. Net zoals alle andere functietitels is het aan het woord alleen nog niet duidelijk wat de functie nu precies inhoudt, laat staan het belang van een QA binnen een project. Het wordt dus eens tijd om hier meer op in te gaan.
In feite zegt de functietitel al een hele hoop van wat de functie is: Quality Assurance. Vrij vertaalt is dit het verzekeren van de kwaliteit van een product. Tot zo ver de inkoppers.
In mijn ervaring is een QA veel meer dan de letterlijke vertaling van de functietitel. Een QA zijn vergt een bepaalde manier van denken, een bepaalde manier van doen, een bepaalde manier van helpen. Afhankelijk van de persoon achter de functietitel is de QA sterker in het ene ten opzichte van het andere.
Een QA is een autist
Mensen met autisme zijn door de manier waarop de denken in een aantal zaken super goed. Met name het focussen op 1 ding en zich daarin helemaal vastbijten is een eigenschap waar een QA veel van kan leren. Jezelf helemaal expert maken van een nieuwe functionaliteit of design, om vervolgens de fouten of bugs aan te kunnen wijzen, dat is het ultieme voor een QA. Met als uiteindelijke hoofddoel om ervoor te zorgen dat het product net weer een stapje beter wordt voor de gebruiker dan dat het nu is.
Als QA wordt er van mij verwacht dat ik op de kleine details let bij de implementatie. Uiteraard moeten de happy-flows van een nieuwe functionaliteit goed werken, maar het zijn juist die edge-cases waarin de meerwaarde van een QA zit. Om die edge-cases eruit te kunnen pikken is het van belang dat je als QA volledig weet wat de bedoeling is van de nieuwe toevoeging aan het product. Conclusie is, bijt je vast aan de nieuwe toevoeging, pluis uit hoe het echt moet en laat niet los voordat je ervan overtuigd bent dat de gebruiker er blij van wordt.
Een QA is een keeper in het team
Binnen een development team kennen we het allemaal: Is eindelijk na veel bloed, zweet en tranen een nieuwe functionaliteit toegevoegd, blijkt de applicatie op een andere plek te crashen. Het is niet altijd te voorkomen. Door elementen en onderdelen van een applicatie op verschillende plekken te gebruiken, kan het voorkomen dat die elementen op andere plekken omvallen.
Ook daarvoor is er de QA. Als een soort keeper in het team is het aan de QA om deze omgevallen domino stukjes op te sporen. Vaak komt dit naar voren tijdens de regressietest. Tijdens een regressietest gaat de QA namelijk door de gehele applicatie heen en komen dit soort omgevallen domino stukjes in theorie naar voren. In theorie, omdat de QA wel beperkingen heeft natuurlijk. Afhankelijk van de grootte van de applicatie, technische beperkingen en de tijd die de QA krijgt voor deze regressietest, zal de QA alles of slechts delen van de applicatie kunnen doorlopen. Om de vergelijking met sport aan te houden: Hoe groter het doel en hoe kleiner de keeper, hoe meer ballen er uiteindelijk toch het doel in gaan.
Een QA is een developer
Net als al het andere in ons leven, zijn de werkzaamheden van een QA ook aan trends onderhevig. Dé trend van nu is wel testautomatisering. Het lijkt het toverwoord te zijn op het gebeid van testen. Het is snel, accuraat en zorgt voor betere kwaliteit. Of dat echt zo is, valt te discussiëren, maar dat is een onderwerp voor een andere blog. Dit alles neemt niet weg dat voor bepaalde projecten testautomatisering wel degelijk voor een hogere kwaliteit kan zorgen van het product.
En dit brengt weer een nieuw aspect van QA-zijn met zich mee, namelijk het zijn van een developer. Niet een developer voor het product zelf, maar een developer voor de kwaliteit van het product.
Een QA is een communicator
Bij mijn werkzaamheden merk ik dat communicatie een van dé belangrijkste eigenschappen is van een QA. Vrijwel de hele dag ben ik aan het communiceren met de developers, de project managers, andere testers, designers en de klanten. En vergeet niet de communicatie tussen deze verschillende rollen.
Hierin zit een van de grootste meerwaardes van de QA. Niet zo zeer in het communiceren an sich, maar vooral in het stellen van vragen. Wat is precies veranderd? Hoe zou het moeten werken? Klopt het als ik A zie? Door dit soort vragen te stellen, wordt het voor iedereen die betrokken is bij het project duidelijker wat de bedoeling is van een bepaalde feature.
Daarbij is het belangrijk dat de QA duidelijk is. Duidelijk in wat hij of zij ziet, maar ook duidelijk in welke soort informatie hij of zij terug verwacht. Dit vraagt een bepaalde skill. Met een developer is het vaak nodig om op een ander technisch niveau te communiceren dan met een designer of met de klant.
Een QA is een team member to stay
In mijn ervaring, is een QA een essentieel onderdeel geworden van een development team. Niet alleen vanwege het hooghouden van de kwaliteit bij het testen van de tickets, maar ook zeker in alle stappen daarvoor en daarna. Het hele proces kan soms wel een ander oogpunt hebben, of extra vragen gebruiken. De QA is een van de personen die hier van nature goed in zou moeten zijn.
Natuurlijk is niet elke QA hetzelfde. De ene zal veel meer op de structuur zitten, terwijl de ander juist meer op de communicatie zit. Niks hierin is goed of fout. Het is aan de Project Manager of leidinggevende om de kwaliteiten van zijn of haar QA te zien en hierop te anticiperen. Net zoals bij alle andere personen in het team. Zolang er maar iemand in het team zit om zich te richten op de productkwaliteit. Want daar zou het uiteindelijk om moeten gaan. Niet alleen dat er een product op de markt is, maar ook dat een kwalitatief goed product is.
