Come manteniamo la qualità della vostra accademia utilizzando i test di regressione visiva

Di recente abbiamo introdotto la nuova interfaccia dell'accademia. Durante lo sviluppo, abbiamo iniziato a utilizzare alcune nuove tecniche che ci aiutano a migliorare il nostro flusso di lavoro e a mantenere un elevato standard qualitativo del nostro prodotto. Preveniamo i bug lavorando in modo guidato dai componenti e testando spesso i cambiamenti visivi non voluti (regressioni visive).

Sviluppo guidato dai componenti

Negli ultimi anni una grande tendenza nello sviluppo delle interfacce utente è stata lo sviluppo guidato dai componenti (CDD). I componenti sono i più piccoli pezzi di funzionalità autonoma, che aggiungono valore da soli. Il CDD si basa su questo principio, creando un processo di creazione che funziona dal basso verso l'alto. Si creano prima piccoli componenti che si collegano a componenti più grandi, che insieme costituiscono una funzionalità o una pagina. Pensate a una bicicletta composta da parti più piccole. Si inizia creando due ruote, poi un telaio. Si aggiunge un volante, dei pedali e una catena. Ora inizia ad assomigliare a una bicicletta. È così che abbiamo sviluppato anche l'interfaccia dell'accademia.

Abbiamo riscontrato numerosi vantaggi nel lavorare in modo orientato ai componenti:

• I componenti sono riutilizzabili. Se si costruisce una ruota, la si può usare per costruire una bicicletta più grande o più piccola, o magari anche un triciclo.

• I piccoli componenti sono facili da capire.

• I componenti sono facilmente testabili. È possibile testare se la ruota funziona, senza doversi preoccupare dell'intera bicicletta.

• Lavorare con i componenti spesso accelera il nostro processo di sviluppo, fornendo soluzioni plug and play.

• Lo sviluppo è mirato. È facile tenere traccia delle variazioni dei componenti.

• Ci sono strumenti disponibili per tenere facilmente traccia di tutti i componenti disponibili che sono stati creati dai colleghi.

Alcuni esempi di componenti creati sono: un pulsante, una finestra pop-up, una risposta a scelta multipla e una pagina di login completa.

Storybook ci permette di sviluppare componenti esterni alla nostra applicazione in un ambiente isolato, senza preoccuparci delle dipendenze o della rottura dell'applicazione.

La storia della nostra interfaccia in Storybook

Dopo aver creato molti componenti che costituiscono la spina dorsale della nostra interfaccia, li organizziamo in Storybook. Storybook è un esploratore di componenti o una libreria di componenti. È un modo efficiente per tenere traccia di tutti i componenti. Ogni componente ha la sua storia in Storybook, dove si possono vedere tutte le possibili varianti di un componente: 

Componente pulsante in Storybook

Per un componente pulsante, ad esempio, è possibile visualizzare un pulsante predefinito, un pulsante sollevato, un pulsante non sollevato e un pulsante disattivato. È anche possibile interagire con il componente per vedere come cambia lo stato o il comportamento del componente. Ad esempio, è possibile digitare qualcosa nel modulo di login e i campi di input diranno se l'input è valido:

Componente del modulo di login in Storybook

Storybook ci permette di sviluppare componenti esterni alla nostra applicazione in un ambiente isolato, senza preoccuparci delle dipendenze o della rottura dell'applicazione.

Utilizziamo Storybook come strumento di progettazione, poiché abbiamo adottato una strategia di progettazione basata sulle storie. Quando progettiamo, creiamo direttamente qualcosa di valore. Invece di creare sprechi con Photoshop come facevamo prima. Quando aggiungiamo storie di componenti a Storybook, contribuiamo automaticamente a una guida di stile vivente o a una libreria di interfacce utente. Ciò significa che uno sviluppatore può scegliere facilmente da un'ampia gamma di componenti preconfezionati da aggiungere a una funzione che sta creando. In questo modo la nostra interfaccia è coerente e relativamente economica da sviluppare:

Componente della pagina di login in Storybook

Utilizzando i componenti aggiuntivi abbiamo esteso Storybook, in modo da poter testare l'accessibilità di ogni componente. Assicurandoci che l'interfaccia rimanga accessibile agli utenti con determinate limitazioni:

Controllo dell'accessibilità in Storybook

Test di regressione visivi con Percy

Prima abbiamo parlato di regressioni visive, ovvero di cambiamenti visivi non intenzionali. Per rendersi conto di queste modifiche visive, si usa uno strumento chiamato Percy. Percy è uno strumento di verifica della regressione visiva che si preoccupa solo dell'integrità visiva.

Con Storybook posso costruire e modellare i componenti in modo isolato e ho sempre una panoramica dei diversi scenari che ho progettato. Con l'aiuto di Percy, conosco sempre l'impatto delle modifiche apportate.
Anouk
Sviluppatore front-end & UX Designer

Per ogni componente che abbiamo sviluppato nella nostra libreria di componenti Storybook, viene realizzato uno screenshot. Quando cambiamo un componente, viene fatta una nuova schermata e le due vengono confrontate l'una con l'altra. Le differenze sono segnate in rosso per mostrare chiaramente cosa è cambiato:

Regressioni visibili in Percy

Le differenze tra la vecchia e la nuova versione sono segnate in rosso.

Percy si collega direttamente alla nostra pipeline di integrazione continua (il flusso che va dall'idea alla realtà), notificandoci le regressioni visive prima che le modifiche vengano pubblicate. Dopo una revisione da parte di uno dei designer, le modifiche vengono accettate o rifiutate. Percy consente anche di discutere una determinata modifica:

Percy si è integrato nella nostra pipeline dicendoci che c'è qualcosa da rivedere

Tutto questo ci aiuta a evitare che le modifiche visive indesiderate arrivino a voi, i nostri utenti finali. Ma vi è sfuggito un bug visivo? Continuate a leggere per scoprire come lo gestiamo in questo articolo.