De geschiedenis van testautomatisering beslaat inmiddels een periode van enkele tientallen jaren. Deze discipline is echter pas de laatste jaren écht in een stroomversnelling geraakt en ze lijkt nu voor het eerst ook definitief door te breken en zich te bestendigen, als een relatief volwassen vakgebied.
Deze ontwikkeling is een gevolg van onder andere de maturatie van tooling en frameworks, de adoptie door grote spelers zoals Google en de succesvolle opkomst van software development methodologieën die testautomatisering als randvoorwaarde hebben of waarvan testautomatisering een logisch gevolg is.
Omdat testautomatisering in deze zin genomen nog maar een relatief jong vakgebied is, bestaan er binnen dat vakgebied nog steeds een hoop misvattingen (en daarmee valkuilen). Zelfs ten aanzien van allerlei fundamentele thema’s. Deze misvattingen bestaan in een organisatie vaak niet alleen binnen allerlei (hogere) managementlagen en groepen van (meer direct betrokken) business stakeholders (zoals product owners), maar zelfs binnen allerlei groepen van practitioners (zoals developers en testers).

Met het bestaan van deze misvattingen word ik als consultant dan ook bijna dagelijks geconfronteerd. Alvorens te kunnen beginnen met het eigenlijke werk, is het vaak noodzakelijk om, herhaaldelijk, allerlei misvattingen uit de weg ruimen middels educatie van de betreffende mensen. Zo heb ik regelmatig te maken met verzet tijdens de introductie van tegen deze misvattingen indruisende practices, patterns en guidelines. En zoals gezegd, kan het daarbij de ene keer gaan om business stakeholders, dan om lijnmanagement en wederom een andere keer om practitioners binnen delivery teams. Vaak zijn de misvattingen ook hardnekkig en vergt het wegnemen ervan een inspanning die zelfs een substantieel deel van mijn tijd in beslag neemt. En soms zijn ze zo hardnekkig, dat mensen er in het implementatietraject alsnog aan vast blijven houden en daarmee de automatiseringsinspanning en/of -oplossing ongewild saboteren.

Belevingswereld

De leden van ieder van de genoemde groepen hebben een eigen, specifieke belevingswereld en kennen een eigen, specifiek idioom, waarin en waarmee men hetgeen zich op dagelijkse basis aandient, begrijpt, analyseert, waardeert, beoordeelt en met anderen bespreekt. Lijnmanagers denken dienovereenkomstig voornamelijk in business-strategische termen over automatisering na, als zijnde een strategisch en/of tactisch middel om een visie te verwerkelijken, om strategische doelen te realiseren en/of om overeengekomen operationele targets te behalen. Business owners, maar ook de practitioners binnen de delivery teams, denken vooral in termen van effectiviteits- en efficiencywinst op het vlak van de kwaliteit van hun processen en (daarmee) van hun producten: hoe kan het middel worden ingezet om in dezelfde of kortere tijd meer waarde voor de business op te leveren, zij het in termen van extra productfunctionaliteit en/of van meer productkwaliteit? Practitioners denken daarnaast ook in technische termen over een automatiseringsoplossing na, bijvoorbeeld in teststrategische of architecturale termen: welke testsoorten kunnen we met de oplossing automatiseren en hoe moeten we de oplossing daartoe structureren en opzetten, ook met het oog op lange termijn succes daarvan? De product owner is in dit laatste doorgaans minder geïnteresseerd en is vaak ook niet eens onderlegd om het belang van zulke overwegingen te kunnen inzien. Hetgeen trouwens vaak tot spanningen zal leiden, aangezien een product owner dan ook veelal verrast zal zijn door het grote aantal stories rondom de bouw en uitrol van een automation framework en de daarmee gemoeid gaande story points.
Zo denken managers dan bijvoorbeeld over de baten van testautomatisering in termen van een kortere time-to-market, groei in omzet/marktaandeel en/of een reductie van het aantal test fte’s; product owners in termen van een hogere velocity c.q. meer story points; en practitioners in termen van snellere feedback cycles, meer gevonden defecten en een hogere mate van repeatability van het testen. Merk trouwens op dat niet alleen veronderstelde baten zelf niet altijd (volledig) haalbaar zijn en gerealiseerd kunnen worden, maar dat ook de daadwerkelijk gerealiseerde baten per genoemd organisatieniveau niet altijd in elkaars verlengde zullen liggen. Met alle problemen van dien (waarover later meer).
Op dezelfde manier zijn nu ook de diverse misvattingen op het gebied van testautomatisering specifiek voor deze belevingswerelden, waarbij er uiteraard ook weer sprake van overlap kan (en regelmatig zal) zijn.

Misvattingen

Voorbeelden van misvattingen op lijnmanagement en stakeholder niveau zijn allerlei onrealistische verwachtingen omtrent hetgeen testautomatisering wel en niet voor je kan doen en betekenen. Dat is, welke problemen het wel en welke het niet voor je kan oplossen. En welke kosten en baten je daarbij moet verwachten. En welke de tekortkomingen, beperkingen en risico’s zijn, die er mogelijkerwijs mee gemoeid gaan. Er is vaak ook onenigheid omtrent deze onderwerpen. En vaak wordt deze onenigheid pas zichtbaar als het te laat is. Namelijk als het (grootste deel van het) implementatietraject voltooid is en het blijkt dat de daadwerkelijke baten, etc. niet (volledig) aansluiten bij de voorstellingen daaromtrent van (een deel van) het management en/of de stakeholders.
Bij practitioners, met name developers en test (automation) engineers, bestaan er bijvoorbeeld nog steeds allerlei misvattingen (en grote verschillen in opvattingen) rondom de vraag hoe je testautomatisering zou moeten opzetten en inrichten (zelfs gegeven eenzelfde situatie of context), teneinde niet alleen een effectieve en efficiënte oplossing, maar (vooral) ook een toekomstvaste oplossing te verkrijgen. ‘Toekomstvast’ in de zin dat de oplossing beschikt over de daartoe vereiste kwaliteiten, zoals daar bijvoorbeeld zijn: herbruikbaarheid, onderhoudbaarheid, portabiliteit en overdraagbaarheid. De oplossing moet immers niet alleen een huidig probleem voor ons oplossen, maar we moeten er ook op toezien dat de oplossing in de nabije of verdere toekomst niet zelf tot een probleem zal (ver-) worden. Dat is, de oplossing moet ook in de toekomst niet alleen effectief onze problemen kunnen blijven oplossen, maar als middel daartoe ook zelf werkbaar en onderhoudbaar blijven. Oftewel we moeten de oplossing ontwerpen en bouwen vanuit een lange termijn perspectief. En m.b.t. het antwoord op de vraag hoe je dat laatste precies moet doen, bestaan er een hoop (deels klassieke) misvattingen en lopen de meningen bovendien sterk uiteen: Welke design patterns moeten we toepassen in onze oplossing? Welke abstractielagen moeten we aanbrengen? Welke automatiseringsinterfaces moeten we kiezen? Moeten we een data-driven test design ondersteunen? Hoe moeten we binnen de oplossing met de test data omgaan? Wat brengen wel en wat niet onder binnen onze setup/teardown mechanismen? Etc.

Spraakverwarring

Al deze misvattingen evenals de verschillen in opvattingen blijven trouwens mede bestaan door het feit dat zelfs het spreken over testautomatisering problematisch is, omdat er vaak niet eens een gedeeld begrippenapparaat is. Auteurs van boeken en artikelen, vendors/leveranciers en practitioners in het veld gebruiken dezelfde termen vaak in uiteenlopende betekenissen. Deze spraakverwarring zorgt bij automatiseringsinspanningen dan ook voor veel miscommunicatie, doordat de betrokkenen (stakeholders en practitioners) veelal ongemerkt langs elkaar heen praten. Op zijn minst zal dit tot vertraging leiden.
Dit drieledige probleem (d.i. misvattingen, divergerende opvattingen en gebrek aan terminologische fixatie) komt helaas binnen veel organisaties voor. Zeker binnen de meeste van de organisaties waar ik zelf word ingezet.

Aanzet tot verdere discussie

Het is dan ook belangrijk dat wij, d.i. de community van testautomatiseringsexperts en -professionals, de heersende fundamentele misvattingen wegnemen en daarnaast een gedeeld idioom ontwikkelen in termen waarvan we vervolgens de discussie met elkaar kunnen aangaan over een aantal belangrijke onderwerpen en, idealiter, tot een minimale (d.i. werkbare) mate van consensus omtrent deze onderwerpen kunnen komen. Onderwerpen zoals onze verwachtingen van hetgeen testautomatisering voor ons kan doen en hoe we deze automatisering moeten opzetten om de geformuleerde doelen ook te kunnen behalen.
Als bijdrage aan dit streven naar verheldering en aan dit komen tot een inhoudelijke ‘common ground’, wil ik met een reeks van posts typische misvattingen op het gebied van testautomatisering wegnemen. Misvattingen die soms ook al eerder, door anderen, aan de kaak gesteld zijn, maar die desondanks nog steeds erg veel voorkomen. Het is juist in deze tijd, waarin meer automatiseringsinspanningen dan ooit worden aangegaan, van belang om deze misvattingen voorgoed uit de weg te ruimen, zodat zij ons niet kunnen blijven achtervolgen en steeds opnieuw voor verstoring op de werkvloer kunnen zorgen. Daarbij wil ik ook steeds van de gelegenheid gebruik maken om een aantal fundamentele begrippen te verhelderen, door ze nader te omschrijven en ze, waar mogelijk, van een expliciete, eenduidige definitie te voorzien.
Ik hoop dat dit als uitgangspunt voor (en opstap naar) verdere discussierondes kan dienen, aangezien ik, uiteraard, noch de pretentie, noch de ambitie heb om dit allemaal in mijn eentje te doen. 🙂

To be continued …

Mijn eerste post zal zich richten op de wegneming van een misvatting die ik in de praktijk helaas nog veel te vaak tegenkom. Hetgeen menige doorgewinterde testautomatiseerder wellicht zal verbazen. Immers, het aantonen van de onwaarheid van deze misvatting zal voor de ervaren automatiseerder overkomen als het intrappen van een open deur. Echter, voor een beduidend deel van degenen die hun eerste stappen zetten binnen de discipline van de testautomatisering zal het een behoorlijke eye-opener zijn. Ik kom deze mensen nog dagelijks tegen. Voor hen is deze eerste post dan ook geschreven.