Hur vi upprätthåller kvaliteten i din akademi med hjälp av visuell regressionstestning

Nyligen introducerade vi vårt nya gränssnitt för akademiker. Under utvecklingen började vi använda några nya tekniker som hjälper oss att förbättra vårt arbetsflöde och upprätthålla en hög kvalitetsstandard för vår produkt. Vi förhindrar att buggar uppstår genom att arbeta komponentdrivet och genom att ofta testa för oavsiktliga visuella förändringar (visuella regressioner).

Komponentdriven utveckling

Under de senaste åren har en stor trend inom utvecklingen av användargränssnitt varit komponentdriven utveckling (CDD). Komponenter är de minsta delarna av en fristående funktionalitet som ger ett mervärde på egen hand. CDD förankrar detta genom att skapa en byggprocess som fungerar nerifrån och upp. Du skapar först små komponenter som kopplas till större komponenter, som tillsammans utgör en funktion eller en sida. Tänk på det som att en cykel är uppbyggd av mindre delar. Du börjar med att skapa två hjul och sedan en ram. Lägg till en ratt, några pedaler och en kedja. Nu börjar det se ut som en cykel. Det var så vi utvecklade gränssnittet för akademiker också.

Vi upplever många fördelar med att arbeta komponentdrivet:

• Komponenter är återanvändbara. Om du bygger ett hjul kan du använda det för att bygga en större eller mindre cykel, eller kanske till och med en trehjuling.

• Små komponenter är lätta att förstå.

• Komponenter är lätt testbara. Du kan testa om hjulet fungerar, du behöver inte oroa dig för hela cykeln ännu.

• Att arbeta med komponenter påskyndar ofta vår utvecklingsprocess genom att tillhandahålla plug and play-lösningar.

• Utvecklingen är fokuserad. Det är lätt att hålla reda på komponentvariationer.

• Det finns verktyg för att enkelt hålla reda på alla tillgängliga komponenter som har skapats av kollegor.

Några exempel på komponenter som vi har skapat är: en knapp, ett popup-fönster, ett flervalssvar och även en komplett inloggningssida.

Storybook gör det möjligt för oss att utveckla komponenter utanför vår applikation i en isolerad miljö, utan att behöva oroa oss för beroenden eller att applikationen går sönder.

Berättelsen om vårt gränssnitt i Storybook

När vi har skapat en mängd komponenter som utgör ryggraden i vårt gränssnitt organiserar vi dem i Storybook. Storybook är en komponentutforskare eller ett komponentbibliotek. Det är ett effektivt sätt att hålla reda på alla våra komponenter. Varje komponent får sin egen historia i Storybook, där alla möjliga variationer av en komponent kan ses: 

Knappkomponent i Storybook

För en knappkomponent är det t.ex. möjligt att visa en standardknapp, en upphöjd knapp, en nedhöjd knapp och en inaktiverad knapp. Det är också möjligt att interagera med komponenten för att se hur det ändrar komponentens tillstånd eller beteende. Om du t.ex. skriver in något i inloggningsformuläret kommer inmatningsfälten att visa om inmatningen är giltig:

Komponent för inloggningsformulär i Storybook

Storybook gör det möjligt för oss att utveckla komponenter utanför vår applikation i en isolerad miljö, utan att behöva oroa oss för beroenden eller att applikationen går sönder.

Vi använder Storybook som ett designverktyg, eftersom vi har antagit en berättelsedriven designstrategi. När vi designar skapar vi direkt något som är värdefullt. Istället för att skapa slösaktiga Photoshop-handoffs som vi brukade göra tidigare. När vi lägger till komponentberättelser i Storybook bidrar vi automatiskt till en levande stilguide eller ett användargränssnittsbibliotek. Det innebär att en utvecklare enkelt kan välja bland ett brett utbud av färdiga komponenter att lägga till i en funktion som de håller på att skapa. Det gör att vårt gränssnitt blir konsekvent och relativt billigt att utveckla:

Komponent för inloggningssida i Storybook

Med hjälp av tilläggsprogram har vi utökat Storybook så att vi kan testa tillgängligheten för varje komponent. Vi ser till att gränssnittet förblir tillgängligt för användare med vissa begränsningar:

Kontroll av tillgänglighet i Storybook

Visuell regressionstestning med hjälp av Percy

Tidigare talade vi om visuella regressioner som är oavsiktliga visuella förändringar. För att bli medveten om dessa visuella förändringar använder vi ett verktyg som heter Percy. Percy är ett visuellt regressionstestverktyg som bara bryr sig om visuell integritet.

Med Storybook kan jag bygga och styla komponenter isolerat, och jag har alltid en överblick över de olika scenarion jag designat. Med hjälp av Percy vet jag alltid vilken inverkan de ändringar jag gör har.
Anouk
Front-End Developer & UX Designer

För varje komponent som vi har utvecklat i vårt komponentbibliotek Storybook görs en skärmdump. När vi ändrar en komponent tas en ny skärmdump och de två jämförs med varandra sida vid sida. Skillnader markeras sedan med rött för att tydligt visa vad som har ändrats:

Regressioner synliggjorda i Percy

Skillnader mellan den gamla och den nya versionen är markerade med rött

Percy är direkt kopplad till vår pipeline för kontinuerlig integration (flödet från idé till verklighet) genom att meddela oss om visuella regressioner innan ändringarna går live. Efter en granskning av en av formgivarna accepteras eller avslås ändringarna. Percy möjliggör också en diskussion om en viss förändring:

Percy integreras i vår pipeline och berättar att något behöver ses över

Allt detta hjälper oss att förhindra att oönskade visuella förändringar når ut till er, våra slutanvändare. Råkade en visuell bugg ändå slinka igenom? Fortsätt läsa för att ta reda på hur vi hanterar det i den här artikeln