Testautomatisering en keuzes maken

Testautomatisering kan heel waardevol zijn, maar wordt vaak te pas en onpas op een verkeerde manier in het proces toegepast.

Bij Bsure-Digital kunnen we toetsen wat de Testautomation maturity van een organizatie is

Om het waarom van testautomatisering te beantwoorden gebruiken we hiervoor het alombekende Administratieve organizatie proces

Huidige situatie

Leer de organizatie kennen en stem af met stakeholders wat de problemen binnen hun eigen en ketenprocessen zijn.
Breng de ideale producteisen vanuit de huidige situatie in beeld en maak een quality backlog. Probeer onafhankelijk te toetsen wat de best mogelijke oplossing is voor de klant. In de quality backlog leg je de stakeholders, en de kans maal schade vast. Op basis van bedrijfskritische software wordt er bepaald waar de focus moet liggen. Bestaan er al scripts voor testautomation? Moeten we het zo laten of gaan we het op een slimmere manier opzetten.

Nieuwe situatie

Lever een strategie en visie op middels een testautomation quality backlog, hou regelmatig discussies met de stakeholders over die visie. In die nieuwe situatie is het ideaal plaatje directe feedback en zou Shift Left de focus moeten hebben. Directe feedback is uiteraard essentieel om testautomation succesvol te maken. Vanuit de testpiramide zou dit moeten kloppen maar zelf ben ik meer voorstander van proces unittests dan geisoleerde unittests omdat die niet de waarom vraag beantwoorden,en ik als functioneel tester ben opgegroeid om daar altijd op te anticiperen.

En ik heb met mijn jarenlange ervaring gezien dat de meeste fouten vaak op integratie niveau liggen omdat de ketenprocessen nooit duidelijk zijn. Mijn persoonlijke advies zou naast proces unittesten er voor te zorgen om vanuit integratie op functioneel, infra, security en performance de meeste focus te leggen. Werkt dat goed dan voorkom je vaak heel veel incidenten! Gebruik testautomation als input voor monitoring.
Het belangrijkste om je nieuwe situatie succesvol te laten zijn is dat je de stakeholders binnen de organizatie goed kent, promoot zodat het binnen de cultuur gedragen kan worden. Betrek iedereen van developers tot CEO’s bij het proces en probeer het in begrijpelijke taal uit te leggen. Alleen dan kan testautomation binnen een organisatie succesvol worden.

Keuze Tools of Testcode.

Ik kom uit een wereld van Testcode(java/javascript en .Net) maar zie ook dat tools als Tosca/Katalon/UFT/Testcomplete een levensvatbaarheid hebben, mits ze op de juiste manier ingezet worden.
Het voordeel van test/development code is dat je echt Shift left kan developen, beheren en testen. CI/CD tools als jenkins/gitlab etc. bieden de mogelijkheid om direct de gedeployde en build code te unit,systeem, performance, en security testen vanuit de pipelines. Zelf ben ik er een groot voorstander van, maar zie ook dat als je hele bedrijfskritische processen wil gaan automaten (legacy) van bijv. 6 tot 8 keten applicaties bijv. dat tools als Tosca/UFT hier hun waarde hebben en dat dat goedkoper kan zijn om te managen, en ook qua kennis om te beheren.

Alles automatiseren of niet!

Ik hoor vaak dat het belangrijk is om alles te automatiseren. Hoewel ik het standpunt snap maak ik zelf vaak mee dat een testautomation specialist het bedrijfsproces niet snapt.
Dus mijn stelling, automatiseer zoveel mogelijk op het gebied van UI,API, beheer etc., maar wees kritisch WAAROM je het doet. Beheers en begrijp de klantprocessen en beheers de risicos, en maak bewuste taktische keuzes, en doe dan pas een succesvolle implementatie