De visie van onze collega Silvio Cacace op de toepassing van testautomation.

In organisaties die Agile, DevOps en Continuous delivery hebben omarmd is de behoefte aan een kortere time-to-market van nieuwe functionaliteiten toegenomen. Dit verlangt ook een verandering van testen. wij vragen ons af, hoe we er voor kunnen zorgen dat door de veranderende organisatie structuur, het doel van testen “een uitspraak doen over de kwaliteit van het testobject” niet uit het oog wordt verloren. Deze blog geeft is geschreven voor een ieder die in mindere mate technisch onderlegd is.

Gelukkig zijn er inmiddels heel wat tools voorhanden die ons als tester kunnen helpen bij al deze uitdagingen. Denk hierbij aan tools voor het bevindingenbeheer, testmanagementtools, zgn. scan-tools, testdata generatie tools en niet te vergeten tools die de testuitvoering kunnen overnemen. Van deze laatste tools zijn TestComplete, Tosca en Selenium enkele bekende voorbeelden. Het groten voordeel van deze tools is dat de testuitvoering geautomatiseerd kan worden. En zelfs hierbij kunnen weer andere tools worden ingezet zoals het Cucumber framework (Specflow voor .Net) om de uitgeschreven test gevallen (uitgeschreven in Gherkin) te vertalen naar uitvoerbare code.

Met de beschikbaarheid van de tools voor de testuitvoering, hoeven we ons als tester geen zorgen meer te maken dat we steeds opnieuw de vaak saaie handmatige handelingen keer op keer moeten uitvoeren. Daarnaast kunnen we de testen zo vaak herhalen als nodig is en kunnen we complete regressietests geheel geautomatiseerd uitvoeren. Met de implementatie van een dergelijke tool zijn we er echter niet. We zullen deze tool namelijk moeten ‘voeden’ met testgevallen. Daarnaast willen we aan het einde van de test nog steeds een uitspraak doen over de kwaliteit van hetgeen getest is en we willen als tester inzage kunnen geven in de testdekking van de geautomatiseerde testuitvoering.

Als we terugdenken aan het ‘klassieke’ testen, zien we dat we ten behoeve van het opstellen van de testgevallen gebruik maakten van allerlei voorhanden zijnde formele testspecificatietechnieken. Denk hierbij bijvoorbeeld aan Elementaire Vergelijking Techniek (EVT), Beslistabellen, Dataflowtest, CRUD, ect. We gebuikte deze technieken om voor de diverse risicogebieden (na uitvoering van de risicoanalyse) de juiste testgevallen te ontwikkelen met de gewenste testdekking. Maar hoe werkt dit nu met geautomatiseerd testen? Worden de testgevallen die we geautomatiseerd uitvoeren nog steeds zo gestructureerd opgezet en kunnen we dan na de testuitvoering nog steeds iets zeggen over de kwaliteit van het testobject en over de behaalde testdekking?
Het antwoord is helaas vaak ‘Nee’.

Het zegt daarom in het algemeen ook niet zoveel als men de testuitvoering heeft geautomatiseerd. Wat er is geautomatiseerd is veel belangrijker om te weten. Als je bijvoorbeeld de regressietest van systeem A geheel geautomatiseerd kunt uitvoeren met 1 druk op de knop, maar deze regressietest slechts bestaat uit een aantal testgevallen die bedacht zijn door een toevallige voorbijganger, wat zegt dat dan over de kwaliteit van de regressietest? Of als je een functionele test automatiseert waarin je alleen testgevallen met betrekking tot de zgn. happy flows opneemt, dan worden alle uitzonderingen niet getest. Als dit een bewuste en afgestemde keuze is, is dit natuurlijk prima. Mogelijk dat voor dat stuk functionaliteit het risico van de foutkans heel laag was. Maar vaak zien we dat dit juist alleen de keuze is van degene die op dat moment de tool aan het ‘voeden’ is met testgevallen en hierbij helemaal geen afstemming plaatsvindt met de opdrachtgever.

Met andere woorden, met het inzetten van een tool voor de testuitvoering zijn we er echter niet. We zullen ons altijd moeten afvragen wat er getest moet worden en met welke diepgang, uiteraard in overleg met de opdrachtgever. We zien hierdoor al steeds vaker dat de aanpak van Behaviour Driven Development (BDD) wordt ingezet, waarbij het gedrag van de eindgebruikers als uitgangspunt geldt. Het kan immers niet zo zijn dat we alle testen kunnen automatiseren met de meest geavanceerde tools, maar achteraf niemand echt weet wat er nu eigenlijk is geautomatiseerd en dus werkelijk is getest.

We zullen ons dus altijd moeten afvragen…..Wat testen we nu eigenlijk?