Door Rob van Steenbergen
Gezocht: test automation engineer, technisch tester, technical test analyst. Dit zijn een aantal vacatures die je nu vooral tegenkomt. Zelfs bij de vacature ‘functioneel tester’ zie je bijvoorbeeld dat ervaring met programmeren in Java een vereiste is. Dit is als je bekend bent met de huidige markt geen verrassing op zich, het is al jaren zo dat er van testers wordt verwacht dat men technischer wordt en in ieder geval bekend moet zijn met minstens één programmeertaal. Het kan natuurlijk doorslaan en dat zie ik ook. Testers die meer programmeur aan het worden zijn en vooral testen aan het automatiseren zijn. De perspectief op kwaliteit en hoe deze het meest efficiënt onderzocht kan worden verliest focus in dit soort gevallen bij de tester. Een voorbeeld hiervan is ook beschreven in het artikel van Eric Spaargaren uit 2016
Het is ook wel lastig om als full stack tester aan het werk te zijn, een automatische suite onderhouden op meerdere niveau’s. Het daarnaast ook daadwerkelijk onderzoek doen op een stuk software krijgt van de tester hierdoor niet de volledige aandacht. Waar de focus op automatisering is, wordt de creativiteit en de eigenschappen van ‘de mens’ minder belangrijk. Dit terwijl gebruikers van de software nog wel ‘de mens’ blijft.
Iedereen verantwoordelijk
De balans lijkt te gaan naar ‘testen is geautomatiseerde controlesystemen bouwen’ en kwaliteit meer naar ‘het gehele team’. De testexpertise wordt een belangrijk onderdeel van iedereen die bezig is met het ontwikkelen van een softwareproduct. Eigenlijk een positief verhaal als je het op deze manier bekijkt, we roepen het al jaren: ‘Iedereen is verantwoordelijkheid voor kwaliteit’ en nu gaan we naar een fase in de ICT waar het ook daadwerkelijk gevraagd wordt van ‘iedereen’ om zich te verdiepen in de kwaliteit. En degene met de testervaring en kennis kan hier een coachende en begeleidende rol in pakken.
Detectief
De laatste trend, wat niet nieuw is, maar ondertussen ook steeds meer in de picture komt, is het ‘preventief’ tegenover ‘detectief’. Omdat iedereen betrokken zou moeten zijn bij kwaliteit kan ook iedereen over mogelijke risico’s nadenken. Sommige risico’s lijken duidelijk, bijvoorbeeld het gebruik van Angular geeft risico’s met performance, geen designer voor de GUI geeft mogelijke usability issues, een specificatie is nog niet goed genoeg uitwerkt als het de sprint in gaat, et cetera. Als tester met ervaring kan je van tevoren al bijna de mogelijke issues raden als je een stuk software krijgt.
Maar goed, iedereen verantwoordelijkheid voor de kwaliteit, dat heeft wel een bepaalde volwassenheid en discipline van de organisatie nodig. Professionaliteit in niet alleen de juiste software maken, maar ook de discipline om je los te koppelen van de details, te de-focussen van deze details en overzichtelijk te krijgen en te houden waar we aan kwaliteit kunnen winnen. Betere specificaties, meer aandacht voor en door de gebruiker, voorspellen van risico’s, liefst zo vroeg mogelijk. Kortere feedback loops dichter bij de bron. Dat is nogal een uitdaging, maar een welkome, denk ik.
Risico’s als de basis van testen
Toen ik in 1997 begon, wist nog ‘niemand’ echt wat testen was, nu heeft iedereen er een mening over. De basis is nog steeds de risico’s die we nemen. Daaromheen verandert de implementatie van de maatregelen bij deze risico’s. Als we maar niet vergeten dat we in de risico-business zitten. Of je nu een devops engineer, testautomation specialist, business tester, testengineer of functioneel tester bent.
Aan de hand van de risico’s besluit je wat je gaat onderzoeken op gebied van kwaliteit, een handmatige test om de ‘unknown unknowns’ te vinden of een geautomatiseerde ‘check’ om bepaalde risico’s in je regressie te vermijden. Of verdiepen in de processen waarmee specificaties worden bedacht en uitgewerkt.
Lang leve de kwaliteit
Het vakgebied ‘kwaliteit’ in de ICT groeit en wordt steeds interessanter. Hierbij geldt natuurlijk dat je je niet gek moet laten maken door de over-aandacht op de automatisering, maar dat je dit moet blijven zien als ‘toolgebruik ter ondersteuning van het onderzoek doen op kwaliteit van de ICT’. Altijd al een valkuil geweest, maar lijkt mij iets om te blijven benadrukken.
