Visual Regression Testing, of visuele regressie testen, is een categorie van testen die zich focust op het identificer
en 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 van de latere stappen in de build pipeline te plaatsen zodat het volledig automatisch kan, maar als er vaak verschillen zijn (wat niet per-sé regressie, achteruitgang, hoeft te zijn) leidt dit tot veel vals positieven die toch handmatig verwerkt moeten worden. Je kan er dan ook voor kiezen om deze testen op gezette tijden uit te voeren als onderdeel van de Definition of Done van een work-item. Ook helpt het ontwikkelaars om in controle te blijven als ze wijzigingen in de stylesheets moeten doen waar impact mogelijk is door de gehele applicatie heen.
Veel VRT frameworks hebben de mogelijkheid om te “approven”. We hebben dit al eerder gezien bij Approval Testing. Ook met Approval Testing is het mogelijk om schermen met elkaar te vergelijken, maar omdat dit een onderdeel in het grotere geheel van Approval Testing is, zijn de mogelijkheden beperkt. Specifieke VRT frameworks hebben vaak meer mogelijkheden door alleen bepaalde schermregionen te testen waardoor de testset een stuk fijnmaziger wordt. Deze regionen worden vaak bepaald door wat er getoond wordt binnen een onderdeel van de HTML-DOM. Selecties van welk onderdeel dat is, gebeurt bijvoorbeeld via xpath expressies of CSS paden.
Bepaalde VRT frameworks kunnen headless draaien, dat betekent: testen zonder dat er een browser geopend hoeft te worden; wat een significante versnelling kan betekenen. Ook kan je vaak aangeven op welk device (in het geval van mobile), welke browser, of op welke schermformaat je wilt testen. Deze testen kunnen deels parallel worden uitgevoerd, wat de totale doorlooptijd van de testen flink verkort.
Waarom zou je Visual Regression Testing willen? Door de gehele CI/CD pipeline te automatiseren kunnen we steeds sneller nieuwe features naar productie brengen. Onze unit, integratie en acceptatie testen controleren of we geen ongewenste features hebben geïntroduceerd in de nieuwe code, maar dat is over het algemeen op het gebied van data, gedrag of processen. Maar stel dat er per ongeluk een dansende pony in je applicatie verschijnt, dan is het voor een geautomatiseerd proces heel moeilijk om te detecteren dat de ongewenste visuele wijziging heeft plaatsgevonden terwijl het voor een menselijke gebruiker overduidelijk is dat er een verandering is opgetreden. VRT kan hiervoor een oplossing bieden. Dat is echter wel afhankelijk van de website die je wilt testen. Als het een website betreft met veel dynamische content, zoals een nieuwssite, dan is het de vraag of VRT veel toegevoegde waarde heeft. De dynamische content zal immers uitgesloten moeten worden van de test. Indien de website zeer statisch is zal er waarschijnlijk weinig veranderen en zal de toegevoegde waarde van VRT ook laag zijn. De toegevoegde waarde van VRT zit vooral in het feit dat automatisch gecontroleerd kan worden of bepaalde wijzigingen op de website onbedoelde bij-effecten hebben op de layout van de website.
Hoe doe je Visual Regression Testing? Nagenoeg alle VRTs werken volgens de Capture, Test, Approve workflow:
Capture: Je definieert als eerste schermen en/of regionen die je op een herhaalbare wijze automatisch kan tonen. Van dit scherm of deze regio maak je een schermafdruk, of capture. Dit is de baseline.
Test: Bij een nieuwe iteratie wordt van dezelfde regio een capture gemaakt en tegen de baseline capture aangehouden. Indien er een verschil is zal dit gemeld worden, bijvoorbeeld in een testrapport.
Approve: Een menselijke gebruiker kan het rapport doornemen te Approven, (de nieuwe capture wordt de baseline), of een incident aan te maken als er daadwerkelijk regressie is opgetreden.
Soorten Visual Regression Testing frameworks Op het web zijn er verschillende VRT frameworks te vinden. De verschillen zitten hem in het platform: as-a-service, betaald of open source; de gebruikte taal (JavaScript, Ruby, .NET, Java); onderliggende capture technieken (Selenium al dan niet met PhantomJS, Chromium) en mogelijkheden. Ook onderscheiden de frameworks zich in ondersteuning, community en mate van ontwikkel activiteit, dus in hoeverre het framework onderhouden wordt. Vooral bij browsertesting is dat laatste belangrijk omdat nieuwe browsers de capture functionaliteit kunnen breken van bestaande tools. Hieronder vind je een incomplete lijst van veel genoemde frameworks die laat zien aan welke keuzes je moet denken. Applitools: Dit framework werkt tweeledig. Capturen moet lokaal gebeuren met behulp van applitools eyes library. Dit kan op een tal van omgevingen: Web, iOS, Androis en tal van test frameworks: Appium, Selenium, Protractor en veel meer. Het vergelijken van captures gebeurt as-a-service. De screenshots worden naar applitools verzonden via de API. Je logt in op de website van applitools en daar kan je via een erg gelikte gebruikers interface de verschillen zien en eventueel een nieuwe baseline instellen. Een aparte management tool is handig voor projecten waar het approven door een andere partij wordt gedaan (business gebruikers of testers) dan degene die het framework heeft ingericht.
VisualReview: Werk je met Protractor en vind je de API oplossing handig maar doe je dat liever on premise (op je eigen server), dan kan je terecht bij VisualReview. Het management is wat minder gebruiksvriendelijk en de opties zijn iets minder uitgebreid. De laatste commit op het project is ook al even geleden, wat kan duiden op een verlaten project.
WebdriverCSS: een andere tool die in eerste instantie veelbelovend lijkt in zijn mogelijkheden is WebdriverCSS. Het leunt zwaar op zijn grote broer WebdriverIO, dus een goede keus als je dit framework al gebruikt. Helaas is de laatste commit van webdriverCSS ook al van twee jaar geleden. Het gebruikt standaard PhantomJS en kan dus headless capturen. Het blinkt uit in het definiëren van regio’s en het instellen van toleranties.
BackstopJS: een NodeJS library die zeer goed te configureren is met regio’s en pre-capture scripts. Gecapturede files worden lokaal opgeslagen en kunnen via een handige web interface vergeleken worden met de baseline. De open source library wordt goed onderhouden en support daardoor de nieuwste technieken zoals headless chrome en puppeteer. Het is echter erg Chrome georiënteerd, dus minder geschikt voor multi browser testen.
Screenster: deze service neemt je het meeste werk uit handen. Je geeft via de webinterface de URL, device, browser en resolutie op. Om op de juiste plek binnen de webapplicatie te komen kan je ook een klikpad opnemen. Vanaf wordt er gecaptured en kan er vergeleken worden met een nieuwe iteratie. Op deze manier is het ultra low-code en heel bruikbaar voor teamleden die geen ontwikkelaars zijn. Ook heeft Screenster integratiemogelijkheden om de eerder geconfigureerde testen in een geautomatiseerde build te hangen.
Zelf aan de slag? Wil je zelf aan de slag, dan zou ik eens beginnen met BackstopJS. Dit framework heeft voldoende ondersteuning, maar door het open source karakter kan je er ook lekker mee kunnen knutselen zodat je beter kan begrijpen hoe VRTs werken. Open source projecten zijn wat dat betreft vaak beter geschikt om mee te experimenteren. Ook in vergelijking met andere open source VRTs steekt deze er boven uit: De grote gebruikerspopulatie en de actieve ontwikkeling in BackstopJS (gemiddeld wekelijks download van 11.500 en veel pull requests), het gemak waarmee het framework geïnstalleerd en geconfigureerd kan worden, mede door de duidelijke documentatie en het gemak waarmee een baseline gecreëerd kan worden en de testen kunt uitvoeren.
Installatie en gebruik
Eigenlijk wijst de Github pagina van BackstopJS voor zichzelf. Die is erg volledig en bevat meer voorbeelden dan we hier kunnen omschrijven. Toch hieronder een aantal tips en een snelle plug-and-play instructie.
Tip: Zorg ervoor dat de laatste versie van NodeJS is geïnstalleerd (BackstopJS werkt alleen met NodeJS 8.0 en hoger)
Open een command prompt (CMD/Git Bash/PowerShell) en navigeer naar de map waar je project staat (of waar een nieuw project moet komen te staan). Voer vervolgens de volgende stappen uit:
npm install -g backstopjs
backstop init
backstop test
#Bij deze stap zullen de tests falen omdat er nog geen baseline-screenshots zijn gecreëerd. In de volgende stap worden die wél gedefinieerd.
backstop approve
#Hiermee worden de screenshots die zijn genomen tijdens bovenstaande stap opgeslagen om als baseline te dienen voor toekomstige tests (m.a.w. de website wordt tijdens een test met deze screenshots getoetst op wijzigingen).Tip: als alternatief voor stap 3 en 4 kan initieel ook het commando ‘backstop reference’ worden gebruikt om – zonder een initiële test – baseline-screenshots aan te maken.
Het is mogelijk om meerdere scenario’s te testen en te configureren en deze parallel te laten uitvoeren. Deze scenario’s kunnen gebruikmaken van custom scripts om de website in een bepaalde staat te krijgen: denk hierbij aan het inloggen op een website om een gesloten domein te testen of het invoeren van een rekeningnummer om een bepaald mutatieoverzicht te kunnen testen. Handige commando’s hierbij zijn:
backstop reference – maak/update screenshots die als uitgangssituatie zal worden gebruikt
backstop test – vergelijk set van baseline-screenshots met nieuwe set van screenshots
backstop approve – sla de resultaten van de laatste test op als nieuwe baseline
Conclusie Visual Regression Testing lijkt in eerste instantie erg geschikt om afbeeldingen op een website te controleren. Echter kom je er al gauw achter dat afbeeldingen niet vaak wijzigen en als ze wel vaak wijzigen, (denk aan een nieuws website), je ze niet wilt meenemen in je visuele regressie test. Waar VRTs juist wel geschikt voor zijn is het checken van ongewenste effecten van veranderingen in de stylesheet of pagina structuur. Welk type framework je voor je VRT kiest hangt af van veel factoren: op welk moment in het build proces doe je deze testen, wie implementeert het, hoe technisch zijn de approvers, op welk platform wil je de applicatie testen etc. In dit artikel stippen we er vijf aan en laten al zien dat ze onderling best kunnen verschillen. We gaan iets dieper in op BackstopJS, een open source tool met een brede community en veel potentie. Echter beperkt het zich tot voornamelijk de Chrome browser en zal je thuis moeten zijn in NodeJS. Maak je al gebruik van WebdriverIO in je testen, dan kan je kiezen voor WebdriverCSS. In andere gevallen kan je bijvoorbeeld meer geholpen zijn met een service en een makkelijke gebruikersinterface en ben je best bereid daarvoor te betalen. We horen graag welk VRT Framework jij gebruikt of zou willen gebruiken en waarom.
Comments