Hoe we de kwaliteit van uw academie behouden met behulp van visuele regressietests

Recentelijk hebben we onze nieuwe academie-interface geïntroduceerd. Tijdens de ontwikkeling zijn we enkele nieuwe technieken gaan gebruiken om onze workflow te verbeteren en de kwaliteit van ons product hoog te houden. We voorkomen bugs door component-gedreven te werken en vaak te testen op onbedoelde visuele veranderingen (visuele regressies).

Componentgestuurde ontwikkeling

De laatste jaren is componentgedreven ontwikkeling (CDD) een grote trend in de ontwikkeling van gebruikersinterfaces. Componenten zijn de kleinste stukjes zelfstandige functionaliteit die op zichzelf waarde toevoegen. CDD sluit hierop aan door een bouwproces te creëren dat van onder naar boven werkt. Je maakt eerst kleine componenten die aansluiten op grotere componenten, die samen een functie of pagina vormen. Zie het als een fiets die is opgebouwd uit kleinere onderdelen. Je begint met het maken van twee wielen, dan een frame. Voeg een stuur, enkele pedalen en een ketting toe. Nu begint het op een fiets te lijken. Zo hebben we ook de academie-interface ontwikkeld.

We ervaren talloze voordelen van componentgestuurd werken:

• Onderdelen zijn herbruikbaar. Als je een wiel bouwt, kun je het gebruiken om een grotere of kleinere fiets te bouwen, of misschien zelfs een driewieler.

• Kleine onderdelen zijn gemakkelijk te begrijpen.

• Componenten zijn gemakkelijk te testen. Je kunt testen of het wiel werkt, je hoeft je nog geen zorgen te maken over de hele fiets.

• Het werken met componenten versnelt vaak ons ontwikkelproces doordat plug-and-play-oplossingen worden geboden.

• De ontwikkeling is doelgericht. Het is eenvoudig om variaties in onderdelen bij te houden.

• Er zijn tools beschikbaar waarmee u eenvoudig alle beschikbare onderdelen kunt bijhouden die door collega's zijn gemaakt.

Enkele voorbeelden van componenten die we hebben gemaakt zijn: een knop, een pop-upvenster, een meerkeuzeantwoord en ook een complete aanmeldpagina.

Storybook stelt ons in staat om componenten buiten onze applicatie te ontwikkelen in een geïsoleerde omgeving, zonder ons zorgen te maken over afhankelijkheden of het breken van de applicatie.

Het verhaal van onze interface in Storybook

Nadat we veel componenten hebben gemaakt die de ruggengraat van onze interface vormen, organiseren we ze in Storybook. Storybook is een componentenverkenner of componentenbibliotheek. Het is een efficiënte manier om al onze componenten bij te houden. Elk component krijgt zijn eigen verhaal in Storybook, waar alle mogelijke variaties van een component kunnen worden bekeken: 

Knopcomponent in Storybook

Voor een knopcomponent is het bijvoorbeeld mogelijk om een standaardknop, een verhoogde knop, een niet-verhoogde knop en een uitgeschakelde knop te bekijken. Het is ook mogelijk om interactie aan te gaan met de component om te zien hoe dat de status of het gedrag van de component verandert. Typ bijvoorbeeld iets in het aanmeldingsformulier en de invoervelden vertellen je of de invoer geldig is:

Aanmeldingsformulier component in Storybook

Storybook stelt ons in staat om componenten buiten onze applicatie te ontwikkelen in een geïsoleerde omgeving, zonder ons zorgen te maken over afhankelijkheden of het breken van de applicatie.

We gebruiken Storybook als een ontwerptool, omdat we een verhaalgedreven ontwerpstrategie hebben aangenomen. Wanneer we ontwerpen, creëren we direct iets dat waardevol is. In plaats van verspillende Photoshop-handoffs te maken, zoals we voorheen deden. Wanneer we componentverhalen toevoegen aan Storybook, dragen we automatisch bij aan een levende stijlgids of gebruikersinterfacebibliotheek. Dit betekent dat een ontwikkelaar gemakkelijk kan kiezen uit een breed scala aan kant-en-klare componenten om toe te voegen aan een functie die hij aan het maken is. Hierdoor is onze interface consistent en relatief goedkoop om te ontwikkelen:

Aanmeldingspagina component in Storybook

Met add-ons hebben we Storybook uitgebreid, zodat we de toegankelijkheid van elk onderdeel kunnen testen. We hebben ervoor gezorgd dat de interface toegankelijk blijft voor gebruikers met bepaalde beperkingen:

Toegankelijkheid controleren in Storybook

Visueel regressietesten met Percy

Eerder hadden we het over visuele regressies, onbedoelde visuele veranderingen. Om ons bewust te worden van deze visuele veranderingen, gebruiken we een tool genaamd Percy. Percy is een hulpmiddel voor visuele regressietests dat zich alleen bekommert om visuele integriteit.

Met Storybook kan ik geïsoleerd componenten bouwen en stylen, en ik heb altijd een overzicht van de verschillende scenario's die ik heb ontworpen. Met de hulp van Percy weet ik altijd wat de impact is van de wijzigingen die ik aanbreng.
Anouk
Front-End Developer & UX Designer

Voor elk onderdeel dat we in onze Storybook-componentenbibliotheek hebben ontwikkeld, wordt een screenshot gemaakt. Wanneer we een component wijzigen, wordt er een nieuw screenshot gemaakt en worden de twee naast elkaar gelegd. Verschillen worden rood gemarkeerd om duidelijk te maken wat er is veranderd:

RegressRegressies zichtbaar gemaakt in Percy

De verschillen tussen de oude en nieuwe versie zijn rood gemarkeerd

Percy sluit direct aan op onze continue integratiepijplijn (de stroom van idee naar realiteit), door ons op de hoogte te stellen van visuele regressies voordat wijzigingen live gaan. Na een beoordeling door een van de ontwerpers worden wijzigingen geaccepteerd of geweigerd. Percy maakt het ook mogelijk om over een bepaalde wijziging te discussiëren:

Percy geïntegreerd in onze pijplijn die ons vertelt dat er iets moet worden herzien

Dit alles helpt ons om te voorkomen dat ongewenste visuele wijzigingen hun weg vinden naar jullie, onze eindgebruikers. Is er toch een visuele bug doorheen geglipt? Lees dan verder om erachter te komen hoe we daar in dit artikel mee omgaan