TestAutomatisering & PerformanceTesten

Don’t be a fool, get the right tool!

Heb jij weleens een keuze gemaakt voor een tool die achteraf gezien toch niet de verstandigste bleek? Helaas een ervaring die veel IT professionals weleens opdoen. En gezien de tools in de moderne ontwikkelomgevingen niet meer aan te slepen zijn, denk ik dat dit nog weleens vaker het geval gaat zijn.. Als testautomatiseerders hebben wij binnen PerformanceArchitecten veel ervaring met het selecteren van de juiste tool. In deze blog een paar tips die er voor zorgen dat jij blij wordt van je toolkeuze in plaats van je eraan te ergeren!

Wanneer je het hebt over test-automatisering gaat het al snel over het gebruik van tools. Er zijn immers vele tientallen, zo niet honderden tools op de markt. Sommige tools zijn breed inzetbaar, maar er zijn ook specialistische tools. Bovendien komen ze met uiteenlopende prijskaartjes, van open-source tot enterprise licenties. Maar hoe kies je nu de tool die het best past bij jouw teams, producten en organisatie? Dat het in de praktijk behoorlijk lastig is, blijkt wel uit de volgende drie situaties die wij in de praktijk vaak tegenkomen als wij bij een organisatie binnenkomen:

  • Er is ooit gekozen voor een tool of suite die gericht is op het geautomatiseerde end-to-end testen. Het benodigde onderhoud is alleen een beetje onderschat..
  • Technisch blijkt de gekozen tool een schot in de roos, maar bij de selectie zijn toch wat randvoorwaarden over het hoofd gezien..
  • De ontwikkelaars in het team uiten veel weerstand tegen het gebruik van de door de organisatie voorgeschreven tooling..

Herkenbaar? Lees hieronder welke valkuilen hieraan ten grondslag liggen en welke lessen we hieruit kunnen trekken. Tot slot nog een aantal handvatten die van pas kunnen komen wanneer jouw team of organisatie voor een toolselectie staat. Hoewel deze blog toegespitst is op testautomatiseringstools, zullen de genoemde criteria, valkuilen en best practices ook van toepassing zijn op toolselecties in andere vakgebieden.

Valkuil 1 – “Testautomatisering = het automatiseren van testen”

Allereerst zien we vaak dat men de huidige testaanpak en bijbehorende testgevallen als uitgangspunt nemen wanneer een testautomatiseringsaanpak (met bijbehorende tooling) bepaald wordt. Dat is erg voor de hand liggend, omdat met de bestaande testaanpak ook voldoende inzicht in de kwaliteit van de software verkregen kon worden. Toch kleeft er ook een probleem aan deze aanpak. De bestaande testgevallen worden hoogstwaarschijnlijk met de hand uitgevoerd op de gebruikersinterface van een applicatie. Wanneer je diezelfde handelingen wilt gaan automatiseren, dan wordt de focus van de toolselectie automatisch gericht op front-end of end-to-end testtools. Eigenlijk is de testtool dus al gekozen voordat de testaanpak goed uitgedacht is. Het resultaat kan zijn dat er een geautomatiseerde testset ontstaat die zich voornamelijk in de GUI afspeelt, waardoor de testen relatief traag zijn en lastig onderhoudbaar zijn. In de praktijk uit zich dat vaak in testen die altijd op rood staan en uiteindelijk een oplossing die geen waarde toevoegt voor het team en het ontwikkelproces.

Valkuil 2 – “Er zijn meer randvoorwaarden dan de technische fit”

Een toolselectie gaat vaak op een organische manier. Er wordt een bepaalde uitdaging ervaren waar vast een oplossing voor is. Hierop wordt een onderzoekje gedaan waarbij gekeken wordt of we iemand kennen die een geschikte tool weet, of er wordt wat gegoogeld en nadat we hebben gecheckt of de technische requirements kloppen doen we on the go een proof of concept. Zeker bij open source tooling iets wat vaak laagdrempelig is. Helaas is het vaak zo dat er verderop in de tijd toch belemmeringen opduiken die vooraf niet waren voorzien. Denk aan ondersteuning die ontbreekt door een te kleine, inactieve community, of later in het ‘project’ benodigde functionaliteiten die er niet zijn. Maar ook aan ontbrekende skills in het team om de oplossing volop te adopteren, of weerstand elders in de organisatie. Uiteindelijk zien we dan dat het initiatief een stille dood sterft en alle moeite voor niets is geweest.

Valkuil 3 – “One tool does it all”

De derde valkuil die we in de praktijk vaak tegenkomen is dat men probeert alle (typen) geautomatiseerde testen van een team, of zelfs de hele organisatie, onder te brengen in één tool of framework. Op het eerste oog klinkt het ideaal dat je een totaaloplossing hebt voor allerlei testsoorten. Een dergelijke testsuite bestaat doorgaans uit verschillende componenten voor het bouwen, inplannen en analyseren van de geautomatiseerde testen. Deze opzet heeft echter wel een keerzijde. Het blijkt namelijk niet of nauwelijks te integreren in het bestaande ontwikkelproces, waardoor testautomatisering een afgezonderd eilandje wordt. Het resultaat is dan dat een dergelijke oplossing slecht geadopteerd wordt door het ontwikkelteam.

Ditzelfde probleem zien we ook geregeld bij “low-code” tools, waarbij de testen begrijpelijk zijn voor “personen uit de business”. Het klinkt ideaal dat de projectmanager of product owner zonder code-kennis zelf testen kan schrijven door middel van hapklare componenten, maar in de praktijk komt daar doorgaans weinig van terecht. Het resulteert echter wel in weerstand bij de teamleden die in hun dagelijkse werk op deze tool aangewezen zijn: de ontwikkelaars of testers.

De sleutel tot succes

Op de één of andere manier is het lastig voor veel teams om voor de juiste tool te kiezen. Soms terwijl er een complex traject voor is opgezet, maar ook bij laagdrempelige selecties. De sleutel tot succes? Maak in ieder geval gebruik van de volgende handvatten.

  1. Bedenk dat een tool alleen maar een hulpmiddel is. Het wordt alleen een succes als eerst goed nagedacht is over de aanpak. Pas daarna is het mogelijk de tool te kiezen die daar het best bij ondersteunt. PerformanceArchitecten ondersteunt hier graag bij!
  2. Doe een goede omgevingsanalyse. Beter hier even aandacht aan geven en dit te checken bij je stakeholders, dan er later achter te komen dat het toch niet past. Ik gebruik altijd één van onze checklisten om snel te kunnen checken of we niet iets vergeten.
  3. Als je effectief en flexibel wil zijn als team heb je een tool nodig dat goed integreert bij jouw werkzaamheden. Wij onderzoeken daarom altijd of het aansluit bij de werkwijze van iedereen die met de tool werkt.

Herken je dit? Of heb je wellicht nog wat aanvullingen? Wij vinden het leuk wanneer je contact opneemt. Ook als je gewoon eens vrijblijvend wil sparren over een toolkeuze bij jou in de organisatie! Mocht je het een leuke blog hebben gevonden, volg ons voor meer in de toekomst!

Dit bericht is geplaatst in Testautomatisering en getagd in #toolselectie Test Automation Testautomatisering

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Nieuws

Blijf op de hoogte

Don’t be a fool, get the right tool!

30/06/2020

Heb jij weleens een keuze gemaakt voor een tool die achteraf gezien toch niet de verstandigste bleek? Helaas een ervaring die veel IT professionals weleens opdoen. En gezien de tools in de moderne ontwikkelomgevingen niet meer aan te slepen zijn, denk ik dat dit nog weleens vaker het geval gaat zijn.. Als testautomatiseerders hebben wij […]

Performance en de cloud

27/05/2020

Eén van de meest genoemde voordelen van de cloud is de in theorie oneindige schaalbaarheid. Zo zou het niet meer nodig zijn om als organisatie veel reservecapaciteit in te richten om pieken op te vangen en de performancerisico’s zouden helemaal verdwijnen. Maar is dat wel altijd zo? Wanneer wel, wanneer niet? Duidelijk is, dat wanneer […]

Ervaringen Performance.Now() 2019

13/12/2019

Ervaringen conferentie PerfNow

Performance test in de pipeline

25/10/2019

In deze blog geef ik kort en bondig neer in welke opzet en met welke tooling ik performancetesten heb geïntegreerd in de pijplijn bij mijn huidige opdracht.

Circle-CI, van code naar webserver met één klik.

13/09/2019

Wanneer je ‘vroeger’ een website had, waren er altijd flink wat handelingen nodig om files via een FTP client op een webserver te krijgen. Vandaag de dag, met behulp van een verscheidenheid aan tooltjes, is dat een fluitje van een cent. Daarnaast krijg je een arsenaal aan mogelijkheden mee als builden, testen, etc.. In deze […]

Een korte intro in data-analyse met R

10/07/2019

Een blog over hoe je met behulp van R grote hoeveelheden data kan analyseren. Een tool dat je helpt bij de analyse van bijvoorbeeld load- en stresstestresultaten.

Installatie Oracle ATS op Windows

28/03/2019

Handleiding over hoe je Oracle ATS installeert op Windows (Versie 13.x of hoger)

Postman API testen in CI

01/02/2019

beschrijving van hoe je jouw Postman collectie laat draaien vanuit Jenkins en hoe je hierbij een praktisch JUnit test report krijgt.

Workshop ‘Stop de Magie!’ bij Qquest

04/12/2018

In het kader van de 4e techday van Qquest heeft Chris met ondersteuning van HenkJaap een workshop gegeven. Basis was de presentatie en demo ‘No more magic’ van Bas en Chris, welke al een groot succes was op de TestAutomationDay en TestNet. Centraal bij het onderwerp ‘No more Magic’ staat het idee dat er bij […]

Visual Regression Testing – Wat is het en wat heb je eraan?

07/11/2018

Visual Regression Testing, of visuele regressie testen, is een categorie van testen die zich focust op het identificeren van visuele wijzigingen tussen iteraties of versies van een website. Dit kan handmatig door schermen of schermafdrukken te vergelijken, maar het is beter herhaalbaar en sneller te testen door dit automatisch te doen. Het mooiste is om deze testen als een […]

Meer efficiency en flexibiliteit in API’s

04/10/2018

Er wordt steeds meer gebruik gemaakt van GraphQL API. Tijdens mijn laatste opdracht heb ik hier dan ook mee gewerkt.. Graag deel ik mijn ervaringen hierover in een aantal blogs. In deze eerste blog wil ik het graag hebben over de uitdagingen met REST API en hoe GraphQL deze oplost. Maar eerst even een korte […]

Impact tooling op performance: Dynatrace

21/09/2018

In deze blog geef ik kort de resultaten weer van een onderzoekje dat ik bij één van mijn laatste opdrachten heb gedaan naar de impact van het gebruik van de tool Dynatrace op de infrastructuur waar het op draait. Mocht je gebruik maken van tooling als Dynatrace of op een andere manier geïnteresseerd zijn in […]