Deel 3 - Alle voor- en nadelen

Vorige keer hadden we ruim 15 minuten waarin we zagen HOE de tools nu precies met het te testen systeem praten. In deze aflevering ga ik de voordelen en nadelen op een rijtje zetten.Maar voordat we hierin duiken wil ik iets uit aflevering 1 nuanceren:

Is geautomatiseerd testen altijd een softwareproject erbij?

Dat was wel mijn stelling vorige keer, waarbij ik de nuancering bewust heb weggelaten. Gelukkig heb ik kritische volgers, zoals Derk-Jan de Grood. klopt als je start c.q. een backlog moet wegwerken. Maar als je het vanaf het begin goed neerzet is het anders. OK, dat moest even gezegd worden. Nu terug naar alle voor- en nadelen.

Voor- en nadelen

Een doordachte strategie voor geautomatiseerd testen vraagt inzicht in de mogelijkheden en onmogelijkheden en de valkuilen. Want “A fool with a tool is still a fool”!

En die éne vergeten valkuil kan je een hoop ellende bezorgen. En dat éne vergeten voordeel kan maken dat je jouw goede plan niet verkocht krijgt aan de beslissers in je organisatie.

Daarom ga ik nu álle mogelijke voor- en nadelen die we in de SmarTEST praktijk ervaren of die ik van anderen heb opgepikt met je doornemen. Ik heb het kaf van het koren gescheiden en ze snijden allemaal hout. Maar, uiteraard praten we niet over absolute waarheden. Spreekt een voor- of nadeel je niet aan of is het in jouw situatie niet relevant? Laat hem dan vooral rusten!

OK, daar gaan we dan, om te beginnen álle mogelijke voordelen, ik heb er 18:

1.      Het is snel - snellere feedback, hogere ‘velocity', testen minder op het kritieke pad

2.     Je kunt meer en vaker testen - de hogere snelheid maakt frequenter testen mogelijk

3.     Het maakt vollediger (regressie)testen mogelijk - met een betere dekkingsgraad en daardoor minder kans op productieverstoringen

4.     Die snelheid en volledigheid maakt je IT-delivery meer agile en meer wendbaar.

5.     Het is goedkoper je kosten zijn lager door onder andere minder menskracht voor de uitvoering. Daar moet ik wel bij zeggen dat snelle besparingen op korte termijn zeldzaam zijn: de kost gaat voor de baat uit. Zelfs op lange termijn zijn de directe kosten niet altijd lager dan bij handmatig testen. De winst zit dan in andere voordelen die zich uiteindelijk ook weer naar geld laten vertalen, zoals wendbaarheid, kwaliteit en volledigheid. Op termijn moeten de investeringen -direct of indirect-winstgevend zijn, anders moet je er niet aan beginnen.

6.     Het is een Brainsaver – want het routinewerk wordt je uit handen genomen en je houdt meer tijd over voor exploratieve, intelligente en creatieve testen,

7.     Het is Betrouwbaar -  want minder foutgevoelig, de tool doet precies wat je zegt, telkens opnieuw

8.     Je maakt het Herhaalbaar - want je doet elke keer exact hetzelfde en ‘bugs’ zijn makkelijker te reproduceren

9.     Het is Veelzijdig het maakt namelijk testen mogelijk die handmatig niet lukken omdat het te snel gaat of omdat er geen handmatige MMI interface is.

10.  Het is Nauwkeurig - maakt nauwkeuriger meten mogelijk, bijvoorbeeld van responstijden

11.  Alles wordt Traceerbaar - aantoonbaarheid en compliancy, achteraf is altijd traceerbaar wat precies is getest

12.  Het is leuk en Motiverend - meer uitdaging en motivatie voor de medewerkers; minder saai handmatig werk

13.  Het bespaart ook op andere manieren tijd - de gebruikte tools zijn ook handig voor het snel invoeren van grote hoeveelheden consistente (test)data via de schermen, dus mét invoervalidaties

14.  Je nut je omgevingen beter - uit  testen draaien ‘s nachts of zelfs 24x7

15.  Het ondersteunt Visualisatie - ondersteunt een continue visuele kwaliteitsindicatie van de software, zichtbaar voor iedereen in de organisatie, bijvoorbeeld via dashboards op de gangen

16.  Het Brengt structuur - brengt rust, reinheid en regelmaat, want geautomatiseerd testen kan niet zonder een gestructureerd proces met stabiele omgevingen en schone testdata (maar ‘elk voordeel heb z’n nadeel’, zie de eerste bullet in het rijtje nadelen)

17.  Het draagt bij aan een soepel het build proces – GT is een onmisbare schakel in een geautomatiseerd build proces, continuous integration en in ‘test first’ softwareontwikkeling, TDD

18.  Performance testen kunnen niet zonder- maakt langdurig of zelfs continu testen met hoge en/of wisselende belastingen mogelijk (performance, load, stress, piek, soak, endurance, reliability testen)

 

Zo, dat waren ze alle 18. Ben je daar nog?  En we gaan gewoon door, nu met de nadelen en valkuilen. Dat zijn er gelukkig minder: slechts 12. Here we go:


1.     Het is een softwareproject erbij! - Het is een complex geheel van scripts, parameters, data en besturingslogica. Dat alles maken en onderhouden kost tijd en geld en is onderhoudsintensief. Dat dit bij ‘test first’ aanpakken minder van toepassing is hebben we overigens al gezien.

2.     Je bent Afhankelijk - van structuur, stabiele omgevingen en consistente testdata is groot. Alles moet exact kloppen, terwijl dat handmatig niet hoedt.

3.     Tools zijn Dom - geautomatiseerd testen is meer ‘checken’ dan testen en ontbeert de creativiteit en de flexibiliteit van de menselijke tester

4.     Het kost tijd en geld –afgezien van dure uren van dure specialisten zijn veel tools evenmin gratis en kosten selectie- en inkoopprocedures ook tijd en energie. Als je het goed doet verdien je dat allemaal ruimschoots terug, maar het initiele budget moet er wel zijn.

5.     Het is Complex - de tools brengen hun eigen complexiteit mee, vergen opleiding en beheer

6.     Het heeft zijn beperkingen - niet alle testen kunnen worden geautomatiseerd, de tools hebben hun beperkingen

7.     De analyse van de ‘fails’ in runverslagen kan tijdrovend zijn, met name als je dekkingsgraad groter en fijnmaziger wordt en de tool veel onterechte fouten rapporteert

8.     Tools kunnen beveiligingsrisico’s introduceren. Denk aan lekken, kwetsbaarheden bijvoorbeeld door poorten open te zetten en te linken naar mogelijk riskante cloud services

9.     Het gaat ten koste van het kritische testoog creativiteit wordt gestopt in tool-technische uitdagingen en niet meer in kritisch testontwerp. Ik denk hierbij aan testgoeroe Michael Bolton die de wereld afreist met zijn workshop ‘critical thinking for testers’.

10. Wat dacht je van Minder draagvlak: Handmatig testen brengt draagvlak, betrokkenheid en kennis bij de (gebruikers)testers en dat wordt minder bij geautomatiseerd testen

11.  En een hele gevaarlijke: Schijnzekerheid - het vertrouwen in de uitkomsten van geautomatiseerde testruns is vaak groot, maar dekking en kwaliteit van een geautomatiseerde testset zijn niet meer waard dan wat de bouwers erin gestopt hebben 

12.  Samenvattend: geautomatiseerd testen stelt hoge eisen en vergt een behoorlijk kennisniveau en volwassenheid van de organisatie

En dat waren alle twaalf nadelen en valkuilen.

Mocht je nu het gevoel hebben: ‘wat een bangmakerij en wat een spijkers op laag water, ik heb het al lang draaien en heb helemaal geen last van deze nadelen’ dan is dat een felicitatie waard. Gelukkig geldt voor al deze nadelen dat ze bij een intelligente strategie prima geneutraliseerd kunnen worden en blijkbaar heb je dat goed voor elkaar.

Even tussendoor: wat ik net heb gedaan is natuurlijk absoluut not done: je gaat in een podcast niet een lijst van 30 items zitten afwerken. Ik heb het toch gedaan omdat ik denk dat het nodig is. Als het je niet heeft gestoord, laat dan even weten. En als het je wel heeft gestoord, maar toch hebt doorgebeten: dankjewel, en feedback zoals “wil je dit nooooit meer doen” mag, graag zelfs. Let’s fail forward!

 

Wanneer (niet) geautomatiseerd testen?

Moeten we alle testen automatiseren? Het antwoord is: nee, dat moet je niet willen want geautomatiseerd testen is niet de ‘silver bullet’ voor elke situatie.

Ten eerste is en blijft testen een creatief proces omdat het bijna per definitie gaat over uitzonderingssituaties die niet of minder goed zijn gedocumenteerd en waar eerder niet goed genoeg over is nagedacht. De beste testideeën ontstaan vaak door ‘critical thinking’ tijdens handmatige testuitvoering. Het zogenaamde ‘exploratief testen’, is de voorkeuraanpak voor testen van nieuwe functionaliteit in agile teams. Eigenlijk is dat het echte testwerk, in tegenstelling tot het automatiseerbare ‘checken’.

Ten tweede is het hands-on werken met een nieuw systeem waardevol voor draagvlak, kennisdeling, betrokkenheid en training van de gebruikers. De gebruikers leveren de bevestiging dat het systeem inderdaad ‘fit-for-purpose’ is en misschien komen er ‘vergeten’ requirements boven water. Dit soort zaken zijn een belangrijke meerwaarde van handmatig testen én leveren weer input voor nieuwe geautomatiseerde testen.

Ten derde zijn er genoeg situaties waarin de kosten niet opwegen tegen de baten of waarbij de technische beperkingen te groot zijn. Ik zal later de kwantitatieve business case behandelen. Hieronder volgen een aantal kwalitatieve overwegingen voor wel of niet automatiseren.

Wanneer/wat wel automatiseren?

Wanneer/wat wellicht niet automatiseren?

Als testen vaak herhaald worden in het kader van nieuwe sprints en releases

Bij minder dan 2x per jaar testen

Als het testobject redelijk stabiel is

Als het testobject nog sterk in ontwikkeling is en bestaande functies voortdurend wijzigen. Het voortdurend moeten aanpassen van de scripts wordt dan misschien te arbeidsintensief.

Als handmatige testuitvoering tijdrovend en foutgevoelig is.

Bij simpele testen die eenvoudig en snel handmatig uitgevoerd en beoordeeld kunnen worden

Als er geen GUI is of als handmatig meten niet precies genoeg kan. Voorbeeld: het meten van transactietijden of het interveniëren in transacties die je niet kunt timen als tester.

Als het niet zo heel precies hoeft en gebruikersvalidatie via de GUI voldoende is.

Als de gebruikers er geen moeite mee hebben dat ze niet meer zelf ‘aan de knoppen zitten’.

Als de gebruikers persoonlijk de acceptatietesten willen doen, ook voor draagvlak en opleiding

Als de testen voorspelbaar zijn en consistent dezelfde uitkomst moeten geven.

Bij onvoorspelbaar gedrag, geen goede specs of uitkomsten die een genuanceerd menselijk oordeel of ingrijpen vereisen.

Bij legacy systemen die worden ‘vernieuwbouwd’ of een nieuwe schil krijgen.

Bij einde levensduur applicaties

Als de applicatie voldoet aan standaarden, gangbare (web)interfaces en protocollen

Als de applicatie geen gestandaardiseerde GUI of API interfaces heeft en dus moeilijk ‘herkend’ wordt door de test tools.

Als de nadruk ligt op functionaliteit, gebruikersinteractie en performance

Voor non-functional kwaliteitsaspecten als gebruikersvriendelijkheid, vormgeving, leerbaarheid en aanpasbaarheid. Die laten zich minder makkelijk geautomatiseerd testen.

Als externe interfaces beschikbaar of makkelijk te simuleren zijn. Denk aan stubs, drivers, service virtualisatie en Docker

Als externe interfaces niet beschikbaar, niet stabiel en niet eenvoudig te simuleren zijn.

Als de applicatie veel functionaliteit heeft en de testuitvoering arbeidsintensief is

Als de applicatie beperkte functionaliteit heeft en de nadruk op de data ligt. In dat geval ligt de uitdaging bij slimme vergelijkingssoftware en niet bij automatiseren van handelingen via de GUI.

Voor administratieve systemen, ook rondom embedded software en IoT.

Geautomatiseerd testen van de echte embedded en IoT functies kan wel, maar niet met generieke tooling. Dit vergt specifieke tools.