Sådan opretholder vi kvaliteten af dit akademi ved hjælp af visuel regressionstest

For nylig introducerede vi vores nye akademi-interface. Under udviklingen begyndte vi at bruge nogle nye teknikker til at hjælpe os med at forbedre vores arbejdsgang og opretholde en høj kvalitetsstandard for vores produkt. Vi forhindrer fejl i at opstå ved at arbejde komponentdrevet og ofte teste for utilsigtede visuelle ændringer (visuelle regressioner).

Komponentdrevet udvikling

I de senere år har en stor tendens inden for udvikling af brugergrænseflader været komponentdrevet udvikling (CDD). Komponenter er de mindste stykker af selvstændig funktionalitet, som tilfører værdi i sig selv. CDD er forankret i dette ved at skabe en byggeproces, der fungerer nedefra og op. Man opretter først små komponenter, som knyttes til større komponenter, der tilsammen udgør en funktion eller en side. Tænk på det som en cykel, der består af mindre dele. Du starter med at skabe to hjul og derefter et stel. Tilføj et rat, nogle pedaler og en kæde. Nu begynder det at ligne en cykel. Det er også sådan, vi har udviklet academy-interfacet.

Vi oplever mange fordele ved at arbejde på en komponentdrevet måde:

• Komponenter kan genbruges. Hvis du bygger et hjul, kan du bruge det til at bygge en større eller mindre cykel, eller måske endda en trehjulet cykel.

• Små komponenter er nemme at forstå.

• Komponenter er nemme at teste. Du kan teste, om hjulet virker, du behøver ikke at bekymre dig om hele cyklen endnu.

• At arbejde med komponenter fremskynder ofte vores udviklingsproces ved at give plug and play-løsninger.

• Udviklingen er fokuseret. Det er nemt at holde styr på komponentvariationer.

• Der er værktøjer til rådighed, som gør det nemt at holde styr på alle tilgængelige komponenter, som er skabt af kolleger.

Nogle eksempler på komponenter, vi har skabt, er: en knap, et pop-up-vindue, et multiple choice-svar og også en komplet login-side.

Storybook giver os mulighed for at udvikle komponenter uden for vores applikation i et isoleret miljø uden at bekymre os om afhængigheder eller om at ødelægge applikationen.

Historien om vores interface i Storybook

Når vi har skabt en masse komponenter, som er rygraden i vores brugerflade, organiserer vi dem i Storybook. Storybook er en komponentudforsker eller et komponentbibliotek. Det er en effektiv måde at holde styr på alle vores komponenter. Hver komponent får sin egen historie i Storybook, hvor alle mulige variationer af en komponent kan ses: 

Button component in StKnapkomponent i Storybook

For en knapkomponent er det f.eks. muligt at se en standardknap, en hævet knap, en ikke-hævet knap og en deaktiveret knap. Det er også muligt at interagere med komponenten for at se, hvordan det ændrer komponentens tilstand eller adfærd. Skriv f.eks. noget i login-formularen, og input-felterne fortæller dig, om inputtet er gyldigt:

Komponent til login-formular i Storybook

Storybook giver os mulighed for at udvikle komponenter uden for vores applikation i et isoleret miljø uden at bekymre os om afhængigheder eller om at ødelægge applikationen.

Vi bruger Storybook som et designværktøj, da vi har vedtaget en historiedrevet designstrategi. Når vi designer, skaber vi direkte noget, der er værdifuldt. I stedet for at skabe spildte Photoshop-overleveringer, som vi plejede at gøre før. Når vi tilføjer komponenthistorier til Storybook, bidrager vi automatisk til en levende stilguide eller et brugergrænsefladebibliotek. Det betyder, at en udvikler nemt kan vælge mellem en bred vifte af færdige komponenter til at tilføje til en funktion, de er i gang med at skabe. Det gør vores brugerflade konsekvent og relativt billig at udvikle:

Komponent til login-side i Storybook

Ved hjælp af add-ons har vi udvidet Storybook, så vi kan teste tilgængeligheden af hver enkelt komponent. Vi sørger for, at grænsefladen forbliver tilgængelig for brugere med visse begrænsninger:

Kontrol af tilgængelighed i Storybook

Visuel regressionstest med Percy

Tidligere talte vi om visuelle regressioner, som er utilsigtede visuelle ændringer. For at blive opmærksom på disse visuelle ændringer bruger vi et værktøj, der hedder Percy. Percy er et visuelt regressionstestværktøj, der kun bekymrer sig om visuel integritet.

Med Storybook kan jeg bygge og style komponenter isoleret, og jeg har altid et overblik over de forskellige scenarier, jeg har designet. Med hjælp fra Percy kender jeg altid effekten af de ændringer, jeg foretager.
Anouk
Front-End Developer & UX Designer

For hver komponent, vi har udviklet i vores Storybook-komponentbibliotek, bliver der taget et skærmbillede. Når vi ændrer en komponent, tages der et nyt skærmbillede, og de to sammenlignes med hinanden side om side. Forskelle markeres derefter med rødt for tydeligt at vise, hvad der er ændret:

Regressioner gjort synlige i Percy

Forskelle mellem den gamle og den nye version er markeret med rødt

Percy knytter sig direkte til vores kontinuerlige integrationspipeline (flowet fra idé til virkelighed) ved at underrette os om visuelle regressioner, før ændringerne går i luften. Efter en gennemgang af en af designerne bliver ændringer enten accepteret eller afvist. Percy giver også mulighed for at diskutere en bestemt ændring:

Percy er integreret i vores pipeline og fortæller os, at noget skal gennemgås

Alt dette hjælper os med at forhindre uønskede visuelle ændringer i at finde vej til jer, vores slutbrugere. Er der alligevel sluppet en visuel fejl igennem? Læs videre for at finde ud af, hvordan vi håndterer det i denne artikel.