Het vak van de software tester is de voorbije jaren onder invloed van de Agile adoptie flink in beweging geweest. Even leek het er op dat de taken van de tester door de developers overgenomen zou worden. Maar de tester is terug van (eigenlijk nooit) weg geweest en moet van alle markten thuis zijn. Een tester een T-shaped-profiel hebben, kennis van programmeren hebben, toolexpert zijn, een strategie uitstippelen en kunnen sturen (om de leemte van de testmanager in te vullen) en voldoende communicatief vaardig zijn om met de business te kunnen sparren. Er zijn echter ontwikkelingen op het gebied van softwareontwikkeling waardoor er ruimte voor / behoefte aan specialisten ontstaat. Hieronder volgen een viertal voorbeelden van deze ontwikkelingen.
De Shift-Left strategie
De Shift-Left strategie, het principe dat testen onderdeel uitmaakt van elke stap in het ontwikkeltraject om zo fouten vooraf te voorkomen in plaats van achteraf te ontdekken, maakt dat testers kennis moeten hebben van de producten, processen, requirements, ontwerpen en architectuur. Op die manier zijn ze in staat om scenario’s te ontwikkelen die als input dienen voor de te ontwikkelen applicatie. Deze strategie wordt onder andere binnen Test Driven en Behaviour Driven Development toegepast. De tester heeft geen testbasis meer in termen van design of user story, maar moet deze zelf mede opstellen en in sommige gevallen daarvoor nog input ophalen bij business stakeholders.
De Shift-Right strategie
De Shift-Right strategie, het testen in productie, geeft een DevOps-team de mogelijkheid om het gebruik van klanten in de productieomgeving te monitoren om vervolgens snel kleine wijzigingen te implementeren. De drie aandachtsgebieden van deze strategie zijn performance, opbrengsten en waardering. Deze strategie is goed bruikbaar voor applicaties waarbij het gebruik en gedrag van klanten input is voor wijzigingen. Daarnaast is het uitgangspunt dat niet elk event vooraf te bedenken en dus te testen is. Dat maakt dat testers een strategie moeten kunnen opstellen om onverwachte events in een dynamische omgeving vast te kunnen stellen. Een goed voorbeeld is het monitoren van het gedrag van bezoekers op een website met behulp van Google Tag Manager. Het kunnen vergaren en verwerken van grote hoeveelheden data en de resultaten kunnen vertalen naar bruikbare feedback vereist specifieke kennis.
Integratie van tools
De verdere implementatie van de Agile werkwijze, het opzetten van DevOps-teams en de behoefte aan Continuous Delivery (CD) maakt dat er steeds meer gebruik gemaakt wordt van een geïntegreerde set van verschillende tools. Het maken van testscripts en het integreren van tooling vereist kennis van tools en programmeren. Door het toenemend aantal tools, de mogelijkheden die ze bieden en de behoefte aan een strategie om die op een geïntegreerde manier in te zetten maakt dat van een test engineer specialistische kennis op het gebied van geautomatiseerd testen gevraagd wordt.
Verhoogde eisen aan non-functional requirements
De laatste jaren worden meer applicaties ontwikkeld die door klanten van opdrachtgevers gebruikt kunnen worden. Het is de normaalste zaak van de wereld dat een klant zelf zijn bankzaken, verzekeringen, hypotheek of energieverbruik kan beheren. De noodzaak om een veilige, gebruikersvriendelijke en snelle applicatie te ontwikkelen, maakt dat er op die non-functionele gebieden specifieke eisen zijn. Het testen van de niet functionele eisen vereist specifieke kennis en ervaring. Daarom zijn er momenteel testers die zich specifiek richten op performance, security en user experience.
Conclusie
Door het implementeren van DevOps-teams speelt testen een continue rol bij het ontwikkelen en beheren van software. Dat gecombineerd met het feit dat meerdere aspecten met specialistische kennis en tooling getest moeten worden, maakt dat er specialisatie op het vakgebied van testen noodzakelijk is. Het testen verplaatst zich naar links en naar rechts, maar het is onderweg noodzakelijk om verschillende specialisten de testwerkzaamheden uit te laten voeren in samenwerking met de overige teamleden. Bij het samenstellen van een team of programma moet je daar terdege rekening mee houden. Je mag niet verwachten dat developers alle technische-, business- en testexpertise bezitten om de groeiende diversiteit aan testen uit te voeren. Als je het zo beschouwt, bestaat dé tester inderdaad niet meer!
