Geautomatiseerd testen: help business en IT van elkaar houden

Bij ACA maken we gebruik van de agile methodologie in onze projecten. We werken nauw samen met onze klanten om oplossingen te leveren die hun daadwerkelijke bedrijfsproblemen oplossen. Bovendien streven wij ernaar deze snel op te lossen. Deze aanpak heeft zijn waarde keer op keer bewezen, omdat het op een zo kort mogelijke termijn zoveel mogelijk feedback vergaart.

Sommige klanten dwingen van oudsher grondige handmatige gebruikersacceptatietests af, voordat een software-wijziging live mag gaan. De reden ligt voor de hand: hun bedrijf is sterk afhankelijk van deze software, dus alle risico's en financiële gevolgen die eruit voortvloeien moeten worden uitgesloten. Dus is handmatig testen nadat het ontwikkelingsproces is afgerond volkomen logisch, toch?

Of misschien toch niet? Het lijkt misschien onlogisch, maar ons team heeft vaak gemerkt dat handmatig testen indirect juist meer risico en problemen veroorzaakt, niet minder! We zouden zelfs willen stellen dat het lijkt op een virus. Een virus dat elk deel van de organisatie infecteert, en vaak volkomen onopgemerkt! Hoe is dit mogelijk? Handmatig testen is helaas niet slechts de laatste controle die het hoort te zijn. Het is een proces. Een proces dat van invloed is op de manier waarop je met veranderingsmanagement omgaat, resources inplant, en verantwoordelijkheden toekent en verschuift.

Handmatig testen: meer kosten en risico's

Volkomen helder, toch?

Misschien toch niet. Ik vat het even samen:

1. Omdat handmatig testen tijd kost, resulteert het in te weinig en dus te grote releases. Dit heeft als gevolg:

• Riskante go-lives
• Trage feedback
• Lastige dependencies, hotfixes als complicerende factor

2. Vanwege het extra vangnet schuift de verantwoordelijkheid weg van het ontwikkelteam. Dit leidt onvermijdelijk tot ontbrekende geautomatiseerde testscenario's en controles, wat leidt tot het volgende:

• Onvoldoende vertrouwen in toekomstige go-lives
• Verplichte (of ontbrekende) handmatige regressietesten bij toekomstige wijzigingen
• Bugs (na verloop van tijd)

Dit alles kost serieus veel geld en brengt ook serieus veel risico's met zich mee!

Maak van geautomatiseerd testen de norm!

In plaats van de specifieke details van elk probleem aan te pakken, nemen we liever een relatief kleine actie om alle problemen bij de wortel aan te pakken. We hebben geprobeerd de misplaatste opvatting weg te nemen dat deze manier van handmatig testen en bewijs verzamelen veel waarde toevoegt.

We gebruikten al een enorme hoeveelheid geautomatiseerde testen als onderdeel van ons test-driven ontwikkelingstraject. Hoe kunnen we hier meer mee doen? We zijn begonnen met onze huidige testgewoonten uitleggen aan onze zakelijke gebruikers. Daarna zijn we voor een concreet project samen scenario's gaan vaststellen. Als laatste hebben we ervoor gezorgd dat ze voortdurend inzicht hadden in de resultaten.

Stap 1: leer de business wat geautomatiseerd testen inhoudt

Welke soorten geautomatiseerde testen zijn er al? Welke garanties bieden ze? Welke garanties bieden ze niet?

De business houdt zich bezig met bedrijven. Zij zijn niet op de hoogte van applicatie-architectuur, laat staan dat ze weten wat een geautomatiseerde test eigenlijk is. Je kunt het uitvoeren van een geautomatiseerde test (meestal) niet zien, dus hoe kun je er ooit op vertrouwen? Als gevolg daarvan draait een verminderde afhankelijkheid van handmatig testen niet om wat werkwijzen veranderen en wat controles toevoegen. In de kern gaat het erom dat je mensen inzicht geeft en hun vertrouwen wint.

Dit is wat we precies hebben uitgelegd:

• Wij werken test-driven: geen enkele functie wordt geïmplementeerd voor er een test is opgesteld. Deze test moet ook eens mislukken, voordat de functie wordt geïmplementeerd. Dan weten we namelijk dat we op het juiste testen.
  
• Het is onmogelijk om een verandering op te leveren zonder dat alle testen gelukt zijn (dit is wat wij ontwikkelaars een succesvolle 'build' noemen). Niet alleen nieuwe testen voor een nieuw verhaal, maar ook de testen van alle eerdere verhalen.
  
• Onze applicaties zijn gelaagd en elke laag biedt zijn eigen garanties. Voor de technische lezer: wij gebruiken een variant op de zeshoekige architectuur, want die ontkoppeling van de technologie perfect bleek aan te sluiten bij het verstrekken van zakelijke garanties.
  

Onze business domain laag is zich totaal niet bewust van enige technologie of infrastructuur, dus deze mogen nooit afbreuk doen aan de garanties die de testen op deze domeinlaag bieden.

Onze use-case laag vertrouwen alleen op infrastructuur voor wat betreft high-level business, bijv. voor iets waarbij 'save' of 'find' kan worden gebruikt. De testen garanderen correcte resultaten voor de acties en query's in deze laag, mits de infrastructuur correct is.

Concrete keuzes voor technologie/infrastructuur vormen invoegtoepassingen aan de grenzen van onze applicaties. Vergelijk het met een printer die op een computer wordt aangesloten: Excel weet niet welk type printer je gebruikt, Excel weet alleen dat het apparaat iets kan afdrukken. Als de invoegtoepassingen ('printer') werken, werken de use-cases (acties en query's) ook.

Wij testen ook alle lagen samen met behulp van click-through UI-testen. Deze testen kunnen zichtbaar worden gemaakt en bestrijken alle onderdelen in de integratie; daarom zorgen ze bij bedrijven voor veel vertrouwen. Er zijn wel enkele hiaten in onze geautomatiseerde teststrategie. Sommige integraties met een infrastructuur of externe diensten kunnen niet gemakkelijk geautomatiseerd worden geverifieerd. Dit is waar manueel testen een rol kan spelen.

"The business should not waste their time by checking whether a certain message appears when you click on a certain button."

Het bedrijf moet zijn tijd niet verspillen met het nagaan of een bepaald bericht wel verschijnt wanneer je op een bepaalde knop klikt. Het doel is niet om zakelijke gebruikers in ontwikkelaars te veranderen, maar om hen te laten zien waarom het vertrouwen van ontwikkelaars in deze testen vanzelfsprekend is. Dus overstelp ze niet met technische details, maar vraag liever waar ze zich zorgen over maken en geef geduldig antwoord. Ze zullen zich niet alle details herinneren en dat hoeft ook niet. Maar het vertrouwen zal beklijven. Pas nadat je dat vertrouwen hebt gewonnen, zullen ze veranderende testgewoontes accepteren. Sterker nog, we hebben gemerkt dat ze er dan zelf om vragen!

Stap 2: Bepaal samen de testscenario's

Wat zijn bedrijfskritische scenario's? Welke controles zijn nodig om voldoende vertrouwen te geven voor een livegang? Dit zijn vragen die we nu behandelen tijdens de uitwerking van het verhaal. Als gevolg daarvan zijn de daaruit voortvloeiende geautomatiseerde testen nu een op te leveren onderdeel van elk verhaal geworden.

Manuele testen zijn vaak gericht op lange end-to-end bedrijfsprocessen. Zelfs als elk deel van het proces afzonderlijk bewezen perfect werkt en jij bent de persoon die de schakelaar om moet zetten voor de productie: zou jij je dan 100% zeker voelen? Voor degenen die dapper genoeg zijn om 'ja' te zeggen: dat is of omdat je alles tot in detail weet, of omdat je niet genoeg weet!

Daarom hebben wij ons geconcentreerd op dezelfde end-to-end bedrijfsstromen, gesimuleerd door de geïntegreerde applicatie door te klikken (met uitzondering van slechts enkele minder belangrijke externe diensten).

Stap 3: Zorg voortdurend voor inzicht

Je bent het eens geworden over de juiste geautomatiseerde testscenario's, maar hoe weten de gebruikers in het bedrijf dat ze correct zijn uitgevoerd? Hoe konden we hen daarbij het bewijs leveren dat ze verplicht moeten documenteren? Daarom hebben we als laatste stap een gedetailleerd testrapport toegevoegd, waarin alle uitgevoerde stappen in een Given-When-Then formulier worden weergegeven.

Door op een stap te klikken wordt een pop-up geopend met schermafbeeldingen en een logboek van alle uitgevoerde controles. Dit levert onze zakelijke gebruikers het bewijs dat de juiste dingen zijn gecontroleerd en biedt daardoor vertrouwen.

✅ Positieve effecten op de invoering van automated testing

We hebben deze nieuwe manier van samenwerken ongeveer 6 maanden geleden ingevoerd voor meerdere ontwikkelingsgolven op een nieuwe applicatie. Gedurende dit project hebben we veel positieve effecten opgemerkt:

• Minder tijd verspild aan manueel testen.
• Meer vertrouwen. We hebben al eerder veel testen geschreven, maar deze nieuwe
  aanpak stimuleert ons om de juiste scenario's en controles te gebruiken: die waar onze eindgebruikers het meest aan hebben. Aangezien er niet langer een mismatch is, hebben zowel de gebruikers binnen een bedrijf als de ontwikkelaars veel meer vertrouwen in de go live.
  
• Concreet bewijs. Wanneer we een verandering moeten doorvoeren (functioneel of technisch, bijvoorbeeld upgrades), komen de volgende vragen altijd als eerste naar boven: "Wat is de impact hiervan? Kan er iets kapotgaan?" We kunnen nu gewoon verwijzen naar het testrapport, waarin alle belangrijke bedrijfsstromen zijn opgenomen.
• Eenvoudiger plannen. Vanwege een geringere tijdsafhankelijkheid van het bedrijf, kunnen we sommige veranderingen eerder oppakken, of flexibeler met tijdlijnen omgaan.
• Belicht blinde vlekken in het testproces. Aangezien de ontwikkelaars nu meer verantwoordelijk worden gehouden, voelen zij de gezonde druk om ervoor te zorgen dat er geen blinde vlekken overblijven na het testen. Dergelijke blinde vlekken worden nu gedekt door aanvullende geautomatiseerde testen en gezondheidscontroles. In uitzonderlijke gevallen kan er een kleine handmatige test nodig zijn voor een specifiek hiaat in het testproces, in plaats van een heel tijdrovend bedrijfsproces.
• Verbeterde verhaalkwaliteit. De focus van de verhalen is verschoven naar goed functionerende bedrijfsscenario's. Bijvoorbeeld, in plaats van een verhaal voor een indieningsscherm dat al velden heeft om 'goedkeurders' te selecteren, worden deze velden nu alleen toegevoegd aan het verhaal dat de goedkeuringen uitvoert. Op die manier is het moeilijker om in de val te lopen van 'functies' implementeren die eigenlijk geen functionaliteit toevoegen.

⚠️ Valkuilen

Hoewel we ongelooflijk positief zijn over deze nieuwe manier van werken, zijn er nog steeds enkele valkuilen waar we voor op moeten passen.

• Teveel end-to-end testen. De testpiramide bevordert het schrijven van de meeste testen op unit-niveau, omdat unit-testen sneller, makkelijker te debuggen en minder vatbaar zijn voor willekeurige storingen die geen verband houden met de applicatiecode. We hebben geprobeerd om de end-to-end scenario's te beperken door een op risico's gebaseerde aanpak te kiezen: als een defecte functie geen risico vormt is testen op de lagere niveaus (bijv. unit-testen) voldoende. Bijvoorbeeld: als een annuleerknop niet werkt, kan de gebruiker gewoon zijn browservenster sluiten.
• Natuurlijke drang om terug te vallen op handmatig testen. Voor kleine veranderingen kost handmatig testen en bewijs verzamelen immers niet zo heel veel tijd. Dergelijke testen zullen echter waarschijnlijk niet worden herhaald voor toekomstige wijzigingen. Daarom is het belangrijk om ze te behandelen als verkennende testen in plaats van een vangnet, waardoor de verantwoordelijkheid bij het team en overeengekomen testscenario's blijft liggen.

➡️ Next steps

Wij vinden deze nieuwe manier van werken een enorme verbetering, maar dit is nog maar het begin. Dit zien wij als de volgende stappen:

• Verminder de focus op het end-to-end niveau. Wij willen graag inzicht geven in geselecteerde testen op lagere niveaus, waarbij de nadruk altijd ligt op de goedkoopste testen die voldoende vertrouwen bieden.
• Maak er een gewoonte van om testscenario's en controles samen met het bedrijf
  te bespreken, zodat het de standaard manier van werken wordt.
• Ga door met de verschuiving naar links. De overeengekomen testscenario's moeten de enige echte voorwaarde zijn voor livegang en tijdrovende livegang-goedkeuringen van verschillende stakeholders vervangen. Dit zal onze time-to-production voor hotfixes en functies drastisch verkorten, waardoor onze klant uiteindelijk de weg naar continue levering in kan slaan.
• Behandel software als een levend product. In plaats van alleen te plannen en veranderingen goed te keuren in grote brokken voor grote projecten, moet het een gewoonte worden om voortdurend te evolueren en applicaties aan te passen aan veranderende bedrijfsbehoeften.

Wat vind jij? Wat vind jij (niet) goed aan onze aanpak? We horen het graag van je!