Een website die zelf regelmatig kijkt of alles nog naar behoren werkt: de ideale wereld. Het opzetten van een dergelijk systeem kost wel enige inspanning, maar wat heb je er eigenlijk aan? Ook bij IMPRES houden we ons sinds enige tijd ook bezig met Test Automation, deze blog geeft een impressie hoe het bij ons toegepast wordt.

Waarom Test Automation?

Het leven van een tester ziet er tijdens de ontwikkeling van een website ongeveer zo uit: Je stelt een flink aantal flows op, doorloopt deze, en waarborgt zo de kwaliteit van de website. De developers voeren nieuwe wijzigingen door aan de website en de flows kunnen opnieuw doorlopen worden. Een mooie en simpele werkwijze, echter met tientallen codewijzigingen per dag wordt het met de beste wil van de wereld een onbegonnen taak. Gelukkig biedt hier Test Automation de uitkomst: handmatige tests worden omgezet in stukken code en deze worden vervolgens bij elke code deploy uitgevoerd. Op deze manier worden breaking changes snel opgespoord en kan de tester bezig met andere belangrijke taken

Dat klinkt tof! Hoe dan?

Bij IMPRES werken we het liefst met Laravel en dit framework maakt het erg makkelijk om Test Automation op te zetten. Het begint met twee eenvoudige commando’s:

	composer require --dev laravel/dusk

	php artisan dusk:install

Hierna staat alles meteen klaar om de eerste tests te schrijven! Voordat we meteen in het wilde weg beginnen te typen is het verstandig om ons aan enkele structuurregels te houden om het overzicht te bewaren.

  • In de Browser map zetten we de tests neer, gesplitst per onderwerp
  • Per websitepagina maken we een nieuw bestand aan in de Pages map. Unieke locators en functies voor een pagina worden hierin gezet. Locators en functies welke op meerdere pagina’s gebruikt worden stoppen we in de aanwezige ‘Page.php’
  • Componenten van de website welke op meerdere plekken gebruikt worden, zoals een menu, geven we een eigen plekje in de Components map.

Nodig is het niet want alles in één bestand proppen zou ook prima werken. Echter even snel een bepaalde functie erbij pakken of uitzoeken wat precies de huidige dekking is wordt dan wel een uitdaging. Er is nog één andere vraag die we onszelf moeten stellen:

Wat willen we automatiseren?

Elk denkbaar scenario automatiseren is niet te doen. Naast dat het je zo’n 3 levens kost is het ook nog eens niet heel nuttig.
Ook hier gaan we ons aan enkele basisregels houden en maken we keuzes wat we wel en niet willen automatiseren:

  • Kritieke flows

Wat is het hoofddoel van de website? Is het puur een website voor het tonen van informatie, of kunnen gebruikers een eigen pakket samenstellen? In beide gevallen wil je minstens één flow die het hoofdproces van de website doorloopt en valideert of alles getoond wordt en correct werkt.

  • Repetitieve flows

Hieronder vallen de flows die niet meteen als kritiek zouden opvallen, maar wel door elke gebruiker doorlopen worden. Denk aan inloggen of producten aan een winkelmand toevoegen.

  • Tijdbesparende flows

Kunnen er nieuwe gebruikers aangemaakt worden, of is er een proces met tientallen formulieren om zo op de ideale verzekering uit te komen? Wat handmatig minuten tijd zou kosten wordt met automation een kwestie van seconden.

  • Basis functionaliteit

Functionaliteit van een website die niet direct onder een complete flow valt, maar wel van belang is voor een goede gebruikerservaring. Zoekfunctionaliteit en werkende knoppen of menu’s vallen hieronder.

Met bovenstaande regels in het achterhoofd zal je uiteindelijk een lijst aan flows krijgen die één of meerdere van deze regels omvangen. De klant hierbij betrekken is ook absoluut een aanrader, zij hebben voornamelijk bij kritieke flows het beste in beeld wat hieronder valt. Handmatige tests zullen ook zeker niet overbodig worden. Bepaalde onderwerpen zijn lastig of zelfs onmogelijk in code om te zetten, zoals het controleren of het uiterlijk van een website in orde is.

Test schrijven

Laravel Dusk heeft ondertussen het project voor ons opgezet en we weten welke flows gemaakt moeten worden. Oftewel, we kunnen aan de slag! Wat je voornamelijk nodig gaat hebben zijn drie dingen:

De juiste Laravel Dusk functie, een goede locator en een variabele.

Met de functie bepaal je wat er gebeurt, denk aan klikken, typen of valideren. De locator wijst het object aan waar iets mee moet gebeuren, bijvoorbeeld een zoekveld of menuknop. De variabele is vrij breed inzetbaar en kan je zien als de waarmee of het onderwerp. Soms gebruik je het voor een productnaam of zoekterm, maar ook als je wilt valideren of een specifieke tekst aanwezig is. De opbouw verder is eigenlijk vrij logisch, je doorloopt het proces exact zoals een gebruiker dat zou doen. Als voorbeeld een webshop:

  • Ik klik op het zoekveld
  • Ik typ de zoekterm “melk” in en druk op “zoeken”
  • Ik voeg drie pakken melk toe aan mijn mandje

Onbewust zitten hier nog enkele stappen tussen die zeker niet vergeten moeten worden, de voornaamste reden van testen is namelijk valideren! Je kan hierbij denken aan:

  • Geeft de zoekterm correcte resultaten weer?
  • Zitten er uiteindelijk daadwerkelijk 3 pakken melk in het mandje?
  • Is de totaalprijs gelijk aan 3 pakken melk?

In de bovenstaande afbeelding zien we voornamelijk Laravel functies (geel) en variabelen (rood), de locators worden in de functies zelf gedefinieerd zodat we deze niet elke keer mee hoeven te geven. De functie ‘search’ ziet er bijvoorbeeld zo uit:

test automation

Als we deze functie aanroepen geven we een zoekterm mee. De functie weet zelf al hoe het zoekveld gevonden kan worden, voert onze zoekterm in en klikt vervolgens op zoeken. Nu is dit slechts een simpel voorbeeld maar in principe is elke fysieke handeling die een gebruiker kan doen ook in code te realiseren.

Automatisch Aftrappen

We hebben nu een arsenaal aan tests, ze zijn echter nog niet helemaal automatisch. Gelukkig is dit eenvoudig in te regelen. Het deploy traject loopt bij IMPRES via Buddy en omdat onze tests binnen hetzelfde Laravel project zitten hoeven we slechts één extra stap toe te voegen: “php artisan dusk”

Als er nu nieuwe code gedeployed wordt zal, voordat de code daadwerkelijk op de hoofdbranche komt, gekeken worden of de tests ook correct doorlopen worden.
Mocht door een wijziging een test falen, dan worden we hiervan op de hoogte gesteld en zal de nieuwe code eerst gefixed moeten worden.

En dan? Klaar?

Niet helemaal. Hoewel het meeste werk erop zit, het schrijven van de tests, betekent dat niet dat er geen werk meer is. Wanneer aan een website nieuwe functionaliteit wordt toegevoegd of de huidige werking aangepast wordt, zal dit ook inhouden dat de Test Automation onder de loep moet worden genomen. Het is dan ook zaak om alles op orde te houden en de tests succesvol én relevant te laten blijven. Al met al is het een investering die zeker zijn vruchten afwerpt. We blijven scherp op de kwaliteit die we leveren en houden nauwlettend de betrouwbaarheid van codewijzigingen in de gaten. Wie wordt daar nou niet blij van!