Deze blog post is de eerste in een reeks van posts ter wegneming van misvattingen rondom het thema testautomatisering. Zie hier voor het inleidende artikel.

Misvatting

“Testautomatisering is de oplossing voor al onze problemen rondom testen en kwaliteit.”

Toelichting

Dit is helaas nog steeds een gangbare opvatting onder voornamelijk, doch zeker niet uitsluitend, ongeïnformeerde stakeholders op (lijn-) managementniveau. Daarbij blijft deze misvatting ook vaak onuitgesproken. Vanwege dit impliciete karakter, blijft deze zienswijze doorgaans lang bestaan, omdat zij niet (of te laat) onderkend en daarmee ook niet (tijdig) gecorrigeerd wordt.

Soms manifesteert zich deze misvatting in iets minder absolute termen, doordat men er niet zozeer van uitgaat dat zonder meer alle (of tenminste de meeste) problemen opgelost zullen worden, maar men in ieder geval een aantal belangrijke voordelen veronderstelt die er niet zijn. Of dat men ervan uitgaat dat voordelen ook ten volle zullen worden gerealiseerd en niet slechts in beperkte mate. Of dat men ervan uitgaat dat één of meerdere problemen kunnen worden opgelost enkel door de inzet van testautomatisering, zonder daarnaast andere maatregelen te nemen of andere middelen in te zetten (d.i. zonder andere onderdelen of aspecten van het testen of van de bredere delivery chain te verbeteren). Of, tenslotte, dat men ervan uitgaat dat de veronderstelde voordelen gerealiseerd kunnen worden zonder bijkomende nadelen (of significante kosten) c.q. dat men de impact van deze nadelen onderschat.
Een aantal van deze fictieve en ‘utopische’ voordelen (alsmede genegeerde of onderschatte nadelen) zal ik in latere posts nog specifiek aankaarten en toelichten, omdat deze bijzonder vaak voorkomen en daarbij ook bijzonder grote schade kunnen aanrichten. Sommige daarvan zullen we, steeds bij wijze van voorbeeld, ook hieronder reeds aanstippen.

Werkelijkheid

Naar een realistischer beeld van de voordelen van testautomatisering

Automatisering als zodanig en in enge zin genomen, heeft vooral invloed op de efficiëntie van het (uitvoeren van het) testen, niet op de effectiviteit ervan. Testautomatisering is dan ook vooral een strategisch middel om te kunnen schalen. Uiteraard niet uitsluitend: er zijn immers allerlei andere (bijkomende) voordelen, zoals bijvoorbeeld een verhoogde mate van test case repeatability of het verhogen van het werkplezier en daarmee de motivatie van testers doordat hun werk afwisselender en uitdagender zal worden. Maar in eerste instantie is testautomatisering een instrument om te kunnen komen tot feedback cycles die in kortere tijd meer kunnen afdekken en die, vanwege deze snelheid, in dezelfde tijdspanne vaker kunnen worden doorlopen.
Ingeval van, bijvoorbeeld, een gebrekkig testontwerp, zal het automatiseren hiervan dan ook slechts resulteren in het sneller en vaker (en dus efficiënter) uitvoeren van ineffectieve tests. Hetgeen wederom zal leiden tot schijnzekerheid c.q. schijnveiligheid.
Dit brengt ons ook meteen op een eerste concrete voorbeeld van een vaak verondersteld voordeel van automatisering, te weten de onterechte verwachting dat we met testautomatisering binnen afzienbare tijd een uitputtende testdekking zullen bereiken of tenminste zullen benaderen. Het is namelijk precies deze veronderstelling die tot gevolg heeft dat men vervolgens ondoordacht overgaat tot het automatiseren van test designs waarvan de kwaliteit onbekend is en vaak te wensen over laat. Als we toch ‘alles’ kunnen testen, hoeven we niet meer kritisch en selectief te zijn ten aanzien van onze test designs, zo de naïeve gedachtegang. Het probleem daarbij is echter, dat het aanbrengen van een uitputtende mate van dekking meestal niet alleen onhaalbaar, maar zelfs onwenselijk is. Ik zal deze laatste (en volgens sommigen gedurfde) stelling in een latere post verder toelichten en beargumenteren. Ook onze geautomatiseerde test designs moeten dus nog steeds geïnformeerd zijn door (en geselecteerd middels) onze testintelligentie, in de vorm van bijvoorbeeld risicoanalyse en testtechnieken.
Maar zelfs m.b.t. het genoemde versnellingsaspect geldt dat er altijd ook andere factoren zijn, naast de testautomatisering, die de doorlooptijd van een test execution cycle kunnen oprekken. Daarom kan de testuitvoering, zelfs met automation in place, nog steeds een  bottle neck vormen binnen een development cycle.
Testautomatisering zal tekortkomingen in (al dan niet kritieke delen van) de overkoepelende testaanpak daarom niet wegnemen of compenseren!
Het algemene oplossingsvermogen van testautomatisering wordt dan ook, in de zojuist geschetste zin, vaak overschat. Deze overschatting bestaat, zoals eveneens al benoemd, in de vorm van ongeïnformeerde (d.i. naïeve), onrealistische verwachtingen aangaande potentiële voordelen, die niet expliciet (laat staan concreet) gemaakt zijn, maar die als onuitgesproken (en vage) veronderstellingen bestaan. Naast de voordelen die er uiteraard daadwerkelijk zijn, worden daardoor impliciet allerlei ‘fictieve’ voordelen geprojecteerd op de voorgestelde testautomatiseringsoplossing.
Testautomatisering wordt daarmee verheven tot een soort van heilige graal van kwaliteitsbewaking en risicomanagement, de ‘silver bullet’ die alle problemen op het vlak van testen en kwaliteit in haar eentje kan elimineren.
Dat klinkt misschien wat gechargeerd, maar in de praktijk kom je deze assumpties helaas nog maar al te vaak tegen.

Naar een realistischer beeld van de nadelen van testautomatisering

Daarnaast bestaan er, naast de evidente voordelen en baten, ook diverse, aan testautomatisering inherente nadelen, in de vorm van allerlei soorten tekortkomingen, beperkingen, risico’s en kosten.
Een voorbeeld van zo’n nadeel is bijvoorbeeld de aan testautomatisering inherente beperking van de zogenaamde ‘coverage lock-in’. Laten we daar bij wijze van illustratie iets dieper op ingaan.
Wanneer een menselijke tester handmatige GUI-level tests uitvoert volgens een vooropgezet plan, zoals bijvoorbeeld een testscript, dan zullen haar ook eventuele onregelmatigheden (d.i. onverwachte systeemgedragingen) opvallen die plaatsvinden in andere delen van het scherm dan die welke volgens het momenteel uitgevoerde testgeval de focus zouden moeten hebben. Een geautomatiseerde test daarentegen detecteert uitsluitend systeemoutput en -gedrag waarvoor ook expliciet validaties geprogrammeerd zijn. Een geautomatiseerde test heeft daardoor dus altijd een exclusieve focus op (specifieke soorten en ranges van) voorgedefinieerde verwachte resultaten.
Daarnaast zal een menselijke tester, althans wanneer zij ervaren en gemotiveerd is en als de tijd het toestaat, on-the-fly additionele testgevallen bedenken en uitvoeren, die variaties zijn op de voorgedefinieerde testgevallen of die zelfs volledig nieuw zijn. Dit zal doorgaans gebeuren op basis van de tot dan toe waargenomen systeemgedragingen en testresultaten en gedreven worden door de creativiteit, ervaring en intuïtie van de tester. Een geautomatiseerde test daarentegen zal, uiteraard, nooit on-the-fly zijn strategie kunnen aanpassen op basis van een door waarneming geïnformeerd leerproces. Er is geen dynamiek in zo’n test behalve de voorgeprogrammeerde.
Met andere woorden, geautomatiseerde tests missen (vooralsnog) de lerende intelligentie, creativiteit, intuïtie en ervaring van een (doorgewinterde) menselijke tester. Uiteraard kan een deel van die intelligentie, creativiteit, etc. erin geprogrammeerd worden. Maar dat zal voor een niet onaanzienlijk deel achteraf gebeuren. Namelijk ingeval van een geconstateerde tekortkoming in de dekking van die test, naar aanleiding van bijvoorbeeld gerapporteerde (missed) defects, false positives, etc. Oftewel, als het kwaad al is geschied. Er zijn veel meer voorbeelden van de beperkingen, tekortkomingen, risico’s en kosten van testautomatisering. Deze zullen in follow-up posts nader worden belicht.
Onder andere vanwege de veelal zeer eenzijdige (en, m.i. bewust, onvolledige) voorlichting door met name commerciële leveranciers, zijn zowel de directe gebruikers van het testautomatiseringsplatform (doorgaans delivery teamleden en eventueel testmanagers en/of testcoördinatoren) als ook de betrokken (groepen van) stakeholders zich van deze nadelen vaak niet (voldoende) bewust c.q. worden deze nadelen (zwaar) onderschat. En, zeker in combinatie met het overschatten van bepaalde voordelen (scriptless test automation, anyone?), kan dit zeer kwalijke gevolgen hebben.

Impact misvatting

Het overschatten van voordelen en gelijktijdig onderschatten van nadelen zorgt vooral voor een ‘false sense of security’. Dit geeft wederom aanleiding tot een overmatig en ongefundeerd vertrouwen in het geautomatiseerde vangnet (overconfidence) en tot een ongezonde mate van afhankelijkheid van dat vangnet (overreliance). Deze ontwikkelingen zullen doorgaans leiden tot onvoorzichtigheid en slordigheid, doordat andere, essentiële momenten en aspecten van het testen zullen worden veronachtzaamd.
Het hebben (en laten bestaan) van onrealistische verwachtingen is daarmee één van de grootste risico’s bij het introduceren van testautomatisering en één van de grootste struikelblokken voor lange termijn succes. Op de (middel-) lange termijn, namelijk wanneer de verwachte voordelen zullen uitblijven en onverwachte nadelen zich zullen manifesteren, zal dit steevast leiden tot teleurstellingen doorheen alle lagen van de organisatie en daarmee uiteindelijk tot afnemend commitment.
Het is dan ook essentieel om deze verwachtingen te managen en, waar nodig, te corrigeren en te alignen. Het commitment van stakeholders (en anderen) moet gebaseerd zijn op expliciete, gedeelde en realistische verwachtingen omtrent zowel de voor- als de nadelen van testautomatisering. Zonder deze realiteitszin zal vroeger of later blijken dat de automatiseringsoplossing niet de geprojecteerde voordelen heeft en/of onverwachte nadelen met zich meebrengt. Daarmee zal, nogmaals, het commitment op termijn steeds verder afnemen.
Een ander effect van deze misvatting is vaak, dat practitioners onder zeer grote druk zullen komen te staan, aangezien een ongeïnformeerde stakeholder doorgaans niet-haalbare of moeilijk-haalbare resultaten van een delivery team, dat immers de aldus geïdealiseerde automatiseringsoplossing inzet, zal verwachten. Een dergelijke stakeholder zal de randvoorwaarden, beperkingen en kosten (veelal in termen van tijd/mankracht/restrisico’s), waaronder c.q. waarmee deze resultaten volgens het delivery team wel behaald kunnen worden, niet snel accepteren. Dit zal tot veel discussie, misverstanden en daarmee spanningen en onrust leiden.

Advies/maatregelen

Hanteer een breed perspectief

Testautomatisering alléén kan niet alle problemen rondom kwaliteit en testen oplossen. Zonder identificatie en wegneming van eventuele zwakke plekken in de overkoepelende testaanpak, zal het automatiseren van tests, zoals binnen die aanpak opgeleverd, enkel schijnveiligheid bewerkstelligen. Testautomatisering functioneert volledig geïntegreerd in die aanpak en is, in die zin, uiteindelijk niets meer (maar zeker ook niets minder) dan één van meerdere fundamentele succesfactoren voor een effectief testregime.
Het heeft alleen zin om omhoog te schalen als dat wat aldus geschaald wordt ook waardevol is. Immers: crap in, crap out. Maar dan alleen sneller.
Daarom moet gezorgd worden voor een effectieve overall testaanpak en -strategie op alle relevante vlakken (methoden, technieken, systemen en processen) en voor alle relevante kritieke momenten (zoals risicoanalyse en testontwerp) daarbinnen. Dit is een randvoorwaarde voor het succes van een testregime in het algemeen en voor testautomatisering in het bijzonder. De introductie van testautomatisering verandert niets aan dat gegeven. Daarmee wil ik niet zeggen dat ik voorstander ben van een zwaar opgetuigd en geformaliseerd testproces. Ik wil er alleen mee zeggen dat onze testintelligentie nog steeds relevant is en in de juiste vorm en in de vereiste mate moet worden ingebracht om onze geautomatiseerde test designs te informeren.

Kom tot een geïnformeerde automatiseringsstrategie

Eerste stap: Voorlichten

Informeer (d.i. ‘educate’) niet alleen de practitioners, maar (vooral) ook de relevante business stakeholdergroepen met betrekking tot een aantal fundamentele, ‘mission-critical’ onderwerpen. Met ‘mission-critical onderwerpen’ bedoel ik hier die onderwerpen, ten aanzien waarvan teleurgestelde verwachtingen sterk afnemend commitment en afnemende buy-in met betrekking tot de automatiseringsinspanning en -oplossing tot gevolg zullen hebben.
Het informeren moet hier in eerste instantie en voornamelijk bestaan uit het wegnemen van de meest gebruikelijke en gevaarlijke misvattingen ten aanzien van deze onderwerpen. Onderwerpen zoals de mogelijke kosten, baten/voordelen, beperkingen, tekortkomingen, randvoorwaarden/constraints en risico’s m.b.t. testautomatisering. Geef daarbij steeds een aantal typische voorbeelden van zulke misvattingen, maar ook van hetgeen dan wel mogelijk en realistisch is.
Sluit bij dit alles ook zoveel mogelijk aan bij de typische belevingswereld van de betreffende groep. In geval van bijvoorbeeld het educaten van lijnmanagement is het essentieel om te wijzen op de grenzen van (bijvoorbeeld) de mogelijke baten van testautomatisering, in die termen waarin zij over deze onderwerpen verwachtingen zullen formuleren. Bijvoorbeeld in termen van een drastische reductie van het aantal test fte’s. De misvatting die hieraan ten grondslag ligt, is bijvoorbeeld tweeledig, namelijk enerzijds dat virtualiter de ‘gehele’ testuitvoering zal kunnen worden overgeheveld naar de testautomatiseringsoplossing en anderzijds dat de testautomatiseringsinspanning slechts een fractie zal zijn van de huidige inspanningen op testgebied. Niet alleen wordt ‘testen’ daarmee gereduceerd tot ‘testuitvoering’, maar ook wordt het nieuwe, arbeidsintensieve nieuwe taakdomein rondom de testautomatisering niet onderkend.
Merk tenslotte op dat het bij dit alles a.h.w. om een eerste, algemene introductie tot testautomatisering gaat en niet om een interactieve sessie om te komen tot concrete, context-specifieke doelen, scope, constraints, etc. voor de betreffende organisatie. Hier willen we nog uitsluitend het algemene conceptuele kader voor zulke een sessie scheppen, teneinde deze sessie te informeren en daarmee efficiënt en effectief te kunnen laten zijn.

Tweede stap: Strategie bepalen

Met dit kader ‘in place’ kunnen we onze stakeholders in een volgende stap helpen om hun verwachtingen expliciet, concreet en realistisch te maken en deze ook op elkaar af te stemmen (te ‘alignen’). Daardoor ontstaat er een gedeeld en gedragen beeld van zowel de voordelen, als de nadelen (zoals beperkingen en kosten) en risico’s die aan de geprojecteerde testautomatiseringsoplossing (kunnen) kleven.
Een goede manier om dit te doen is middels het formuleren van een gezamenlijke automatiseringsstrategie binnen de groep (of groepen van) stakeholders. Een volgende post zal dieper ingaan op vorm en inhoud van een testautomatiseringsstrategie en op de plek die zij inneemt binnen een traject dat moet worden doorlopen om te komen tot een effectieve, geïntegreerde en toekomstvaste automatiseringsoplossing. Ik zal daarom op deze plek slechts een korte schets geven.
In één of meerdere interactieve sessies (work shops) help je de stakeholders in eerste instantie met het voor henzelf en anderen expliciet maken van hun zorgen rondom testen en kwaliteit: wat zijn eigenlijk de problemen, tekortkomingen en risico’s die wij op deze gebieden ervaren en die wij met testautomatisering menen te kunnen oplossen? Vanuit deze ‘negatieve’ context kunnen de stakeholders vervolgens, ‘positief’, hun verwachtingen ten aanzien van de testautomatiseringsoplossing formuleren in termen van de strategische, high-level doelen (waarin o.a. verwachte voordelen verdisconteerd zijn) en scope (waarin o.a. verwachte beperkingen verdisconteerd zijn) en de daarbij volgens hen geldende constraints (waarin o.a. verwachte kostsoorten verdisconteerd zijn) en risico’s. De onderkende (‘positieve’) doelen en scope moeten daarbij aansluiten bij de eerder geformuleerde (‘negatieve’) problemen, behoeftes en tekortkomingen rondom het testregime. Waarom dit laatste belangrijk is, zal in de genoemde vervolg-post toegelicht worden.
De geformuleerde strategie, in termen van de high-level doelen, scope/etc., zal vervolgens het design van het framework sturen, aangezien de te bouwen oplossing zal moeten zijn toegesneden op het realiseren van de doelen, binnen de gestelde scope en met inachtneming van de onderkende constraints. Daarmee zal zij de gewenste en verwachte voordelen realiseren en enkel de geanticipeerde en ingecalculeerde nadelen, d.i. beperkingen en kosten, met zich meebrengen.
In de genoemde vervolg-post zal ik dit verder concretiseren en ook illustreren aan de hand van voorbeelden uit de praktijk.
Merk ten slotte op dat deze aanpak een zwaar opgetuigde, top-down benadering lijkt te impliceren. Dit lijkt dan wederom haaks te staan op de huidige trend, waarbij teams juist op eigen initiatief, dus bottom-up, en binnen een agile context automatiseringsinspanningen initiëren en doorvoeren. Zelfs in grotere organisaties, waar zulke initiatieven in het verleden vaak vanuit/door het management werden genomen en waar zelfs (op zeer kortzichtige wijze) complete automatiseringsoplossingen bij wijze van decreet de organisatie in werden geduwd, is deze trend zichtbaar. Zoals echter zal blijken in mijn vervolg-post, is het ook bij een bottom-up benadering niet alleen verstandig, maar zelfs noodzakelijk om een automatiseringsstrategie in samenwerking met de stakeholders op te stellen. Ook zal blijken dat zo’n strategie op een zeer pragmatische en inspanningsarme wijze kan worden verkregen.

Samenvatting

Testautomatisering is weliswaar een noodzakelijke, doch niet voldoende voorwaarde voor een effectief test regime.
Terwijl het een open deur zou moeten zijn, blijkt dit gegeven in de praktijk niet voor iedereen evident te zijn. Integendeel, met name onder ongeïnformeerde stakeholders op management niveau, heerst vaak de opvatting dat testautomatisering niet allen een conditio sine qua non is, maar zelfs de ‘alleen zaligmakende’ oplossing voor al onze problemen rondom testen en kwaliteit.
Enkele van de gevaren die in deze misvatting schuilen zijn: de intrede van schijnveiligheid; het ontstaan van misverstanden en spanningen tussen (met name) practitioners en hun stakeholders en de daarmee verband houdende onrust en verstoringen. Het grootste risico voor het succes van testautomatisering zelf ligt in een sterk slinkend vertrouwen en commitment doorheen de organisatie in de automatiseringsoplossing en -inspanningen, naar aanleiding van de onvermijdelijke teleurstelling van deze verwachting.
Van de diverse maatregelen die genomen kunnen worden om deze gevaarlijke misvatting weg te nemen, zijn het grondig informeren van stakeholders en het opstellen van een breed gedragen automatiseringsstrategie de twee belangrijkste.
Lange termijn commitment en buy-in doorheen alle lagen van een organisatie en daarmee ook lange termijn succes, is dan ook uitsluitend mogelijk op een voedingsbodem van expliciete, gedeelde en vooral realistische verwachtingen.