Slik opprettholder vi kvaliteten på akademiet ditt ved hjelp av visuell regresjonstesting

Nylig introduserte vi vårt nye akademigrensesnitt. Under utviklingen begynte vi å ta i bruk nye teknikker for å forbedre arbeidsflyten og opprettholde en høy kvalitetsstandard for produktet vårt. Vi forebygger feil ved å jobbe komponentdrevet og teste ofte for utilsiktede visuelle endringer (visuelle regresjoner).

Komponentdrevet utvikling

De siste årene har en stor trend innen utvikling av brukergrensesnitt vært komponentdrevet utvikling (CDD). Komponenter er de minste delene av selvstendig funksjonalitet som tilfører verdi i seg selv. CDD bygger på dette ved å skape en byggeprosess som fungerer nedenfra og opp. Du lager først små komponenter som knyttes til større komponenter, som til sammen utgjør en funksjon eller en side. Tenk på det som en sykkel som består av mindre deler. Du begynner med å lage to hjul, deretter en ramme. Legg til et ratt, noen pedaler og et kjede. Nå begynner det å se ut som en sykkel. Det var slik vi utviklet grensesnittet for akademiet også.

Vi opplever mange fordeler ved å jobbe komponentdrevet:

• Komponenter kan gjenbrukes. Hvis du bygger et hjul, kan du bruke det til å bygge en større eller mindre sykkel, eller kanskje til og med en trehjulssykkel.

• Små komponenter er enkle å forstå.

• Komponenter er enkle å teste. Du kan teste om hjulet fungerer, du trenger ikke å bekymre deg for hele sykkelen ennå.

• Å jobbe med komponenter gjør ofte utviklingsprosessen raskere ved å tilby plug-and-play-løsninger.

• Utviklingen er fokusert. Det er enkelt å holde oversikt over komponentvarianter.

• Det finnes verktøy som gjør det enkelt å holde oversikt over alle tilgjengelige komponenter som er laget av kolleger.

Noen eksempler på komponenter vi har laget, er en knapp, et popup-vindu, et flervalgssvar og en komplett påloggingsside.

Med Storybook kan vi utvikle komponenter utenfor applikasjonen i et isolert miljø, uten å bekymre oss for avhengigheter eller at applikasjonen går i stykker.

Historien om grensesnittet vårt i Storybook

Når vi har laget mange komponenter som utgjør ryggraden i grensesnittet vårt, organiserer vi dem i Storybook. Storybook er en komponentutforsker, eller et komponentbibliotek. Det er en effektiv måte å holde oversikt over alle komponentene våre på. Hver komponent får sin egen historie i Storybook, der alle mulige varianter av en komponent kan vises: 

Knappekomponent i Storybook

For en knappekomponent er det for eksempel mulig å vise en standardknapp, en hevet knapp, en uhevet knapp og en deaktivert knapp. Det er også mulig å interagere med komponenten for å se hvordan det endrer komponentens tilstand eller atferd. Hvis du for eksempel skriver inn noe i påloggingsskjemaet, vil inndatafeltene fortelle deg om inndataene er gyldige:

Innloggingsskjema-komponent i Storybook

Med Storybook kan vi utvikle komponenter utenfor applikasjonen i et isolert miljø, uten å bekymre oss for avhengigheter eller at applikasjonen går i stykker.

Vi bruker Storybook som et designverktøy, ettersom vi har valgt en historiedrevet designstrategi. Når vi designer, skaper vi noe som er verdifullt. I stedet for å sløse bort tid på Photoshop-arbeid, slik vi pleide å gjøre før. Når vi legger til komponenthistorier i Storybook, bidrar vi automatisk til en levende stilguide eller et brukergrensesnittbibliotek. Det betyr at en utvikler enkelt kan velge fra et bredt utvalg av ferdiglagde komponenter for å legge til en funksjon de er i ferd med å skape. Grensesnittet vårt blir konsekvent og relativt billig å utvikle:

Innloggingssidekomponent i Storybook

Ved hjelp av tilleggsprogrammer utvidet vi Storybook, slik at vi kan teste tilgjengeligheten til hver enkelt komponent. Vi sørger for at grensesnittet forblir tilgjengelig for brukere med visse begrensninger:

Tilgjengelighetskontroll i Storybook

Visuell regresjonstesting ved hjelp av Percy

Tidligere snakket vi om visuelle regresjoner, som er utilsiktede visuelle endringer. For å bli oppmerksomme på disse visuelle endringene bruker vi et verktøy som heter Percy. Percy er et verktøy for visuell regresjonstesting som kun bryr seg om visuell integritet.

Med Storybook kan jeg bygge og style komponenter isolert, og jeg har alltid oversikt over de ulike scenariene jeg har designet. Ved hjelp av Percy vet jeg alltid effekten av endringene jeg gjør.
Anouk
Front-End Developer & UX Designer

For hver komponent vi har utviklet i Storybook-komponentbiblioteket vårt, blir det tatt et skjermbilde. Når vi endrer en komponent, tas det et nytt skjermbilde, og de to sammenlignes med hverandre side om side. Forskjeller markeres med rødt for å vise tydelig hva som er endret:

Regresjoner synliggjort i Percy

Differences between the old Forskjeller mellom den gamle og den nye versjonen er markert med rødt

Percy er direkte knyttet til vår kontinuerlige integrasjonspipeline (flyten fra idé til virkelighet), ved å varsle oss om visuelle regresjoner før endringer går live. Etter en gjennomgang av en av designerne blir endringene enten akseptert eller avvist. Percy gjør det også mulig å diskutere en bestemt endring:

Percy er integrert i pipelinen vår og forteller oss at noe må gjennomgås

Alt dette hjelper oss med å hindre at uønskede visuelle endringer når frem til dere, sluttbrukerne våre. Har en visuell feil likevel sluppet gjennom? Les videre for å finne ut hvordan vi håndterer det i denne artikkelen