Come abbiamo migliorato i test di accessibilità
All'inizio del nostro percorso verso l'accessibilità, in genere raggruppavamo i test di accessibilità in due categorie: automatizzati e manuali. Il primo per individuare rapidamente i problemi più semplici rilevabili con gli algoritmi e il secondo per tutto il resto, che richiedeva più tempo e attenzione per essere trovato. Quelli automatizzati si adattano bene a processi rapidi come l'integrazione continua (CI), mentre quelli manuali richiedono un attento coordinamento con tester qualificati per coprire tutto ciò che gli strumenti automatizzati non sono in grado di fare.
Lungo il percorso abbiamo scoperto che in realtà esiste un punto di equilibrio tra questi due approcci. In collaborazione con Assistiv Labs, abbiamo combinato processi migliori con test di servizio end-to-end per creare un flusso di lavoro di test che ridefinisce l'automatizzato e il manuale. Si tratta di una via di mezzo, un approccio ibrido che aumenta notevolmente la copertura automatizzata e riduce il sovraccarico di coordinamento manuale.
Ora individuiamo problemi chiari e facili da risolvere in poche ore invece che in settimane. I nostri nuovi processi individuano automaticamente ciò che è urgente e inviano i problemi ai team giusti, che in genere li risolvono in pochi giorni.
I risultati sono stati sia tecnici che culturali. Forniamo feedback sull'accessibilità molto più velocemente, i team risolvono i bug più rapidamente e i tecnici di Asana hanno iniziato a pensare ai problemi di accessibilità in modo diverso.
Creare processi per assegnare la priorità ai bug di accessibilità
Alla scala di Asana, un solido Framework di definizione delle priorità supportato da processi e principi di governance è fondamentale. I team devono sapere cosa deve essere programmato nei loro backlog e per quando, e cosa richiede attenzione in questo momento.
Ma è facile sottovalutare quanto sia difficile assegnare la priorità ai bug di accessibilità. La priorità si basa su una matrice vertiginosa di fattori unici, tra cui tecnologie assistive, browser, gruppi di utenti interessati, feedback degli utenti, area di prodotto, difficoltà di correzione, soluzioni alternative, conformità alle WCAG e contesto storico. Alcuni bug potrebbero esistere da molto tempo, ma essere stati rilevati solo di recente. Altri compaiono con le nuove funzionalità. E alcuni sono regressioni: funzionalità che prima erano accessibili ma ora non lo sono più.
Per creare un framework, abbiamo definito formalmente diversi tipi di bug di accessibilità in modo da poter progettare flussi di lavoro semplificati per ciascuno di essi. Un passaggio essenziale è stato definire cosa costituisse una regressione e cosa no.
regressione (s)
Un problema documentato (esiste una traccia del suo funzionamento, come bug precedenti, thread di commenti, screenshot o registrazioni dello schermo?), riproducibile (un collega è in grado di riprodurlo seguendo i passaggi indicati?) che in precedenza funzionava e ora non funziona più.
Le regressioni possono naturalmente ricevere un'alta priorità: l'ultima cosa che si vuole è un regresso dell'accessibilità. In molti casi, questo può semplificare notevolmente la definizione delle priorità.
Tuttavia, c'è un problema. Le regressioni sono definite da istantanee del prima e del dopo. Ad esempio, un'istantanea precedente potrebbe essere un video della funzionalità funzionante e un'istantanea successiva potrebbe essere un video di un nuovo risultato problematico. I bug hanno naturalmente istantanee successive. Ma trovare l'istantanea precedente di solito richiede una ricerca approfondita.
Senza una fonte affidabile di istantanee precedenti, spesso non valeva la pena di indagare se un bug potesse essere considerato una regressione. È qui che un nuovo tipo di automazione si è rivelato immensamente utile.
Automazione dell'accessibilità end-to-end
I test completamente automatizzati non sono una novità per i test di accessibilità o per Asana. Storicamente, axe DevTools e jsx-a11y per React ci hanno fornito una copertura ampia e orizzontale. Ma sono superficiali. Ritenevamo che la stima del 30% token per i test automatizzati in tutto il settore fosse abbastanza vicina ai criteri WCAG che stavamo raggiungendo. La copertura limitata significava che i test manuali trovavano ancora bug che gli strumenti automatizzati non avevano rilevato.
Avevamo bisogno di strumenti in grado di andare più a fondo. Strumenti più strettamente allineati ai nostri principi di ricerca sugli utenti e di governance. Ed è quello che abbiamo trovato con Assistiv. I test per il servizio end-to-end di Assistiv sono scritti da zero dai progettisti di Assistiv in base ai flussi utente e ai parametri di test che forniamo. Le suite includono tasti di scelta rapida, veri lettori di schermo, browser e visione artificiale basata sul cloud di Assistiv Labs. Il risultato è più di una simulazione, con eventi trasmessi a una macchina nello stesso modo in cui farebbe un utente umano, massimizzando la copertura delle WCAG e dei problemi di accessibilità più ampi.
L'automazione end-to-end dell'accessibilità è radicalmente diversa dall'automazione tradizionale, poiché interagisce con Asana per svolgere le attività nello stesso modo in cui farebbe un tester manuale. È possibile coprire fino al 75% dei criteri WCAG, a seconda dello scenario di test. E ci sono ancora esperti di pensiero critico in carne e ossa che vigilano su tutto. Sia Asana che Assistiv sono coinvolte nella progettazione di azioni rappresentative degli utenti e nella revisione dei risultati, migliorando drasticamente il livello dei test automatizzati in termini di portata, frequenza e accuratezza.
Unire le forze
Con un solido framework di definizione delle priorità e una nuova automazione che è passata dal trovare una minoranza di bug a trovarne la maggioranza, abbiamo implementato un potente flusso di lavoro di definizione delle priorità.
In primo luogo, i test automatizzati vengono sincronizzati con la pipeline di progettazione esistente di Asana. I nuovi problemi vengono rilevati quasi in tempo reale e correlati alle modifiche al codice che probabilmente li hanno causati.
Successivamente, un ingegnere di Assistiv esegue una revisione per filtrare i falsi positivi e crea un problema nel backlog di Asana con l’impatto contestualizzato sull’utente e le indicazioni per le azioni correttive. Poiché i test automatizzati vengono eseguiti in modo continuo, è prontamente disponibile un'istantanea precedente e le regressioni possono essere facilmente classificate. Manteniamo flussi di lavoro automatizzati di Asana che indirizzano il problema al team corretto.
In pratica, questo significa che le regressioni vengono solitamente segnalate entro 24 ore da una distribuzione e documentate in modo che siano facilmente comprensibili per gli ingegneri senza esperienza in materia di accessibilità. Ciò consente al nostro team per l'accessibilità di impostare uno SLA per la gestione delle regressioni e di lasciare che se ne occupino i team per lo sviluppo dei prodotti. Nessuno deve decidere quale regressione viene prima, seconda o per ultima. Sono solo bug che richiedono attenzione.
Questo decentramento si traduce direttamente in un programma più sostenibile e in esperienze più inclusive per gli utenti finali. Abbiamo molto più controllo e impatto, molto più spazio per la creatività, perché non dobbiamo costantemente spegnere gli incendi. E questo a sua volta significa che siamo più felici ed efficienti.
Il ROI di cicli di feedback più rapidi
Un bug che passa inosservato per settimane o mesi è costoso da correggere. Qualcuno deve assegnarlo al team appropriato e assicurarsi che riceva la priorità. L'ingegnere a cui viene assegnato probabilmente non è lo stesso che lo ha causato. Anche quando lo è, è difficile recuperare il contesto dimenticato, cambiare marcia o coordinarsi con altri team per risolvere il debito tecnico che è sorto nelle settimane e nei mesi successivi.
Per quantificare il problema, uno studio di IBM molto citato ha rilevato che costa 30 volte di più scoprire i bug in produzione rispetto a quelli rilevati durante la fase di progettazione. Questo sembra vero.
Quando gli ingegneri distribuiscono un aggiornamento al mattino, qualsiasi prova di regressione normalmente inizia a comparire prima della fine della giornata lavorativa. Il ciclo di feedback è così breve che i nostri test end-to-end sono stati i primi ad avvisarci di bug generici dell'interfaccia utente, non limitati ai lettori di schermo o alla navigazione da tastiera, in più occasioni.
Quando i progettisti hanno iniziato a ricevere un feedback più rapido dai test end-to-end, abbiamo notato una riduzione del sovraccarico cognitivo legato alla definizione delle priorità. L'ambiguità è scomparsa. Gli ingegneri pensavano: “Sono responsabile di questo perché l'ho rilasciato stamattina. Ieri funzionava e oggi non funziona, devo correggerlo subito.” La correzione dei bug di accessibilità diventa come la memoria muscolare.
In Asana, i bug di accessibilità sono semplicemente bug. E vengono corretti.
Un modo migliore di automatizzare l'accessibilità
Prima di adottare i test di accessibilità end-to-end, il nostro team per l'accessibilità aveva fatto progressi significativi. Dal punto di vista delle operazioni, i team di design e progettazione avevano documentato i processi di revisione, le definizioni di regressione e gli SLA in atto. Per quanto riguarda i test, c'erano soluzioni automatizzate per resoconti rapidi ma superficiali e un controllo qualità manuale per controlli approfonditi ma che richiedevano tempo.
Con il test end-to-end, abbiamo una soluzione tecnica che integra e si sovrappone all'impegno esistente. Le regressioni vengono documentate prima, con maggiori dettagli e con più prove. Praticamente nessuno perde tempo con segnalazioni di bug che non sono traducibili in azioni o riproducibili.
Ora abbiamo un quadro chiaro di quali bug sono nuovi e quali vecchi, di quali flussi utente influenzano e di chi è responsabile della correzione. Possiamo giocare d’anticipo e concentrarci sulla nostra vision per l’accessibilità di Asana in futuro.
Informazioni sugli autori: Cameron Cundiff (Technical Lead) e Jiaxin Zheng (Technical Program Manager) sono entrambi membri del gruppo Development Lifecycle, dedicato a fornire strumenti che consentano agli sviluppatori di portare le idee in produzione in modo rapido, solido e piacevole.
