Blogserie geautomatiseerd testen deel 2: de nieuwe tester

In mijn vorige blog stelde ik vast: geautomatiseerd testen wordt langzamerhand onvermijdelijk. In deze aflevering zet ik nog even op een rijtje wat geautomatiseerd testen nu eigenlijk is en wat dat betekent voor ‘de nieuwe tester’.

Wat is geautomatiseerd testen?

Het lijkt zo vanzelfsprekend, maar ik kom zoveel misverstanden tegen dat ik er graag even mijn definitie tegenaan gooi: “Geautomatiseerd testen is het onbemand en dynamisch testen van een IT-systeem”. De invoer komt van een tool en niet van een mens. De tool vergelijkt daarbij de respons van het systeem met de verwachte respons en rapporteert de afwijkingen. Maar niet ieder testtraject is hetzelfde. Er zijn diverse vormen van geautomatiseerd testen te onderscheiden die ieder hun eigen voor- en nadelen kennen.

De capture/playback methode

In de simpelste vorm met de hoogste knuffelfactor werkt geautomatiseerd testen als volgt: breng het te testen systeem in de lucht en voer een test uit via een machine waarop ook de test tool is geïnstalleerd. De test tool registreert de handelingen van de tester én de respons van het geteste systeem in een script. Dit script kan daarna onbeperkt uitgevoerd worden. De tool simuleert daarbij de handelingen van de tester en gaat na of de respons gelijk is aan de verwachting, zoals de eerste keer vastgelegd. Snel, compleet en herhaalbaar. Dit is capture/playback, de methode die het meest aantrekkelijk lijkt maar het minst aantrekkelijk is. We zullen later zien waarom en betere alternatieven bespreken zoals programmeren, componeren en genereren van scripts.

Bouwen met tools is niet ‘geautomatiseerd bouwen’

Geautomatiseerd testen Valori.pngGeautomatiseerd testen is niet hetzelfde als het gebruik van tools. Een bouwvakker gebruikt een scala van tools zoals een hamer, beitel en betonmolen. Maar hij doet daarmee nog niet aan ‘geautomatiseerd bouwen’. Ook testers gebruiken allerlei tools voor testdata generatie, link checking, test management, bevindingenbeheer, enzovoort. Maar we spreken pas van geautomatiseerd testen als de tool min of meer zelfstandig en onbemand de interactie met de te testen applicatie van de mens overneemt.

Continuous [… dinges]

Traditioneel ‘Application Lifecycle Management’ is een vorm van mijlpaalbesturing met veel controles, overdrachtsdocumenten en handmatig overzetten naar een volgende omgeving. Daar zijn qua rust, stabiliteit en risicobeheersing goede redenen voor. Maar wie hier met een ‘lean’ bril naar kijkt, ziet veel wachtmomenten en andere vormen van verspilling (‘waste’). De gewenste continue en soepele flow van vernieuwende IT met een hoge business waarde ontbreekt.

Geen wonder dat er vanuit de ontwikkelaarswereld ‘continuous’ alternatieven zijn ontstaan: Continuous Integration, Continuous Delivery en Continuous Deployment. En geen wonder dat we gebruik en beheer (‘operations’) in de feedback cyclus hebben getrokken: DevOps. Zonder automatisering van handmatig werk is dat allemaal onmogelijk en het motto is dan ook: ‘automatiseer alles, in alle fasen’ en hou tijd over voor leuke, creatieve en belangrijke dingen: ‘build – test- deploy - hug - dance!’.

Testers komen hijgend achteraan

Deze beweging komt vooral van onderaf, vanuit de ontwikkelaars, en in mindere mate vanuit de traditionele testgemeenschap. Testers zien plotseling ontwikkelaars die meer ‘test aware’ worden. Ze omarmen uit eigen beweging Behaviour Driven Development (BDD) en Test Driven Development (TDD) en willen daarmee veel dichter bij de gebruikers en het bedrijfsproces staan. De ontwikkelaars kiezen daarvoor liefst tools zonder GUI, die eenvoudig in de scripts van het geautomatiseerde build-framework passen.

De nieuwe tester

De traditionele ‘onafhankelijke, niet-technische’ testers moesten plotseling hun toegevoegde waarde verdedigen en buiten de oude kaders gaan denken. In agile teams is kwaliteitsborging niet langer het exclusieve domein van testers en ook daarin is een nieuwe dynamiek ontstaan: de strikte scheiding tussen developer en tester is er niet meer. Geautomatiseerd testen draagt daar sterk aan bij. Want dat heeft een hoger technologiegehalte dan handmatig testen en schreeuwt om nauwe samenwerking tussen testers en developers. Dat vraagt om een nieuwe generatie ‘full-stack’ testers: testers die de verschillende lagen van de ‘technology stack’ en van de test automation piramide (later meer hierover) begrijpen en op elk niveau kunnen schakelen. Zowel met infraspecialisten en developers als met de business gebruikers.

De nieuwe valkuil

Toch zie ik veel ‘nieuwe testers’ in een nieuwe valkuil belanden: teveel focus op techniek en daardoor vervreemding van de stakeholders en eindgebruikers. Terwijl ze vroeger de vooruitgeschoven post van de business waren zijn ze nu een verlengstuk van development. Dat heeft voordelen voor de samenwerking met het development team, maar de gebruikers ervaren de andere kant van de medaille: zij kunnen het nieuwe jargon van hun ‘eigen’ testers niet meer volgen en de geautomatiseerde test scripts niet meer lezen en op waarde schatten. Hierdoor loopt de samenwerking op inhoud terug.

T-shaped en full-stack

Een goede full-stack tester is ‘T-shaped’, kent deze valkuil en blijft wél de de taal van de business spreken. Ja, hij of zij kan zo nodig technisch de diepte van de technology stack in: de verticale poot van de T. Maar hij of zij is ook breed van boven: communicatief en met gevoel voor business en gebruikers. Dat zit in de bovenkant van de T en ook in de bovenste laag van de ‘technology stack’. En die laag is onverminderd van belang, want kwaliteit gaat tenslotte verder dan techniek en blijft mensenwerk.

Volgende keer

Tot zover dit stukje ‘people side’ van de people-process-tools uitdaging die we aangaan met geautomatiseerd testen. Volgende keer zetten we alle (maar dan ook alle!) mogelijke voor- en nadelen van geautomatiseerd testen op een rijtje. Ik heb al een stuk of 25 voor- en nadelen klaar staan. Graag nodig ik je uit om jouw input te leveren, antwoord gegarandeerd. Wordt vervolgd!