Redactie: Lisa Gelijns ● lisa.gelijns@mail.com
Auteur: Ben Erren ● erren.ben@gmail.com
Een discussie met Robert Werkhoven zette mij aan om mijn ervaringen te delen op TestNetNieuws. Hij gaf aan dat mijn toekomstvisie op testen en kwaliteit, nieuwe inzichten kan geven.
Door mijn jarenlange ervaring in de ICT heb ik de evolutie van losstaande systemen naar steeds complexere ketens van systemen ervaren.
Sinds 2006 ben ik werkzaam als zelfstandig ondernemer. Daarnaast draag ik mijn kennis en kunde over door les te geven op HBO niveau. Dit triggert mij om bij te blijven in het vakgebied en de veranderingen binnen de ICT te blijven volgen.
Daarnaast ben ik aan het promoveren aan de Radboud universiteit met als onderwerp: “Sturen op aanpassingsvermogen” met als ondertitel: “Wendbare organisaties”.
Wat voor testopdrachten krijg je zoal?
Meestal krijg ik geen testopdrachten, maar zet ik testopdrachten uit. Gezien mijn expertise zit ik meer aan de klant- en gebruikerszijde van het acceptatietraject. Bij verschillende implementatietrajecten heb ik het acceptatieproces vanuit de klantorganisatie aangestuurd. Je ziet dan dat de gebruikers en stakeholders, in tegenstelling tot de ontwikkelaars van de software, veel meer kijken naar de implementatie van hun werkprocessen en de hun bekende functionaliteit in applicaties. “Kan ik nog doen wat ik altijd heb gedaan?” in plaats van “Hee, wat een leuke mogelijkheden heb ik er nu bij gekregen!”.
Ontwikkelaars testen doorgaans de nieuwe functionaliteit en of deze naar eigen inzicht “werkt” (Lees: geen systeemfouten tot gevolg hebben). Of de nieuw ingebouwde functionaliteit ook de juiste functionaliteit is, wordt vaak pas bij het uitvoeren van de acceptatietests geconstateerd. Ook wordt vanuit ontwikkelteams in de praktijk vaak te weinig focus gelegd op de usability van oplossingen. Dit wordt in de hand gewerkt door op een verkeerde manier, kortcyclisch en onder hoge tijdsdruk te ontwikkelen.
Een voorbeeld: In de jaren ’80 werd bij de ontwikkeling van een nieuwe module voor een grote applicatie ter ondersteuning van de studiefinanciering, voor elke actie een aparte toets gebruikt. Teruggaan in het scherm was toets A, stoppen toets B, etc. Bij de ontwikkeling van een andere module voor deze applicatie werden echter andere toetsen gedefinieerd voor dezelfde acties. Helemaal logisch voor de ontwikkelaars, maar een crime voor de gebruikers. Het resultaat hiervan was dat de gebruikers bepaalde modules niet meer gebruikten en andere modules oneigenlijk gingen gebruiken.
Dit probleem trof ik in 2016 aan. De gebruikers zagen door de bomen het bos niet meer. Dit soort situaties vragen om een professionele tester die de consistentie bewaakt.
De investering van een organisatie in nieuwe software heeft dan als resultaat het oneigenlijk gebruik of de weigering van het gebruik. Hierdoor neemt de effectiviteit en efficiëntie van de organisatie af.
Het betrekken van gebruikers binnen het ontwikkelproces zou eerder moeten plaatsvinden. Dan kan bepaald worden of de ontwikkeling van de nieuwe functionaliteit de gebruikers ook daadwerkelijk ondersteunt en/of tijd bespaart. Dit om desinvesteringen van de organisatie te voorkomen.
Aan welke testopdracht heb je goede herinneringen en waarom?
Dat is moeilijk te zeggen. Alle implementaties waarbij ik betrokken was, hebben bijgedragen aan het beeld waar ‘testen’ naar toe beweegt. Testen wordt gezien als een onderdeel van softwareontwikkeling. Hierbij ligt de focus meer op de realisatie van de software, dan op het verhogen van de acceptatiekansen. Het is goed dat de wereld tegenwoordig beseft, dat testen niet het afvalputje is, maar een middel dat noodzakelijk is om de gevraagde kwaliteit te waarborgen. Ook beseffen organisaties steeds meer dat testen geen kostenpost is waarop bezuinigd kan worden. Mede door de verandering en de steeds grotere integratie van ketens, wordt het belang van testen steeds groter. Het dient als een verzekering voor de continuïteit van de bedrijfsvoering. Ik zie dan ook een verschuiving van testen naar kwaliteit als een onafhankelijke functie binnen het acceptatieproces van organisaties.
Dit is te vergelijken met de functie van IT-security. Tegenwoordig heeft ieder bedrijf een CISO (chief information security officer ) terwijl dit een aantal jaren geleden een activiteit was bij ICT.
Natuurlijk zal binnen de softwareontwikkeling altijd getest moeten worden om te controleren of hetgeen gebouwd is ook werkt. Infrastructurele testen, performancetesten, integratietesten, ketentesten, securitytesten en functionele testautomatisering zie ik in de toekomst meer als aparte disciplines. Ze kunnen als onderdeel van het acceptatieproces worden ingezet door de stakeholders, met name de beheerders, om de compliancy van projecten vast te stellen.
Van welke testervaring heb je veel geleerd en wat heb je geleerd?
Er is niet één ervaring waar ik het meest van heb geleerd. Ik heb het meest geleerd in de combinatie van studie en ervaring. Hierdoor heb ik inzicht gekregen in het hele testproces. En ik heb geleerd om om te gaan met verandering. Dat 100% testen niet haalbaar is, maar wel het streven. Dat vanzelfsprekendheden niet worden benoemd, maar het succes wel kunnen maken of breken. Dat testen de verzekering wordt voor organisaties. Dat het er voor zorgt dat de organisatie naar een volgend level kan groeien. Dat testen op een ander niveau binnen organisaties moet worden ingestoken. Hoe dan ook; testen is verdomd leuk om te doen en brengt voldoende uitdagingen met zich mee.
Aan wie geef je deze rubriek door?
John Hehanussa
NieuwsMagazine