Hur vi tog tillgänglighetstestningen till nästa nivå

Tidigt i vår tillgänglighetsresa grupperade vi i allmänhet tillgänglighetstestning i två kategorier: automatiserad och manuell. Den första för att snabbt hitta de mest uppenbara problemen som kan upptäckas med algoritmer och den andra för allt annat som krävde mer tid och uppmärksamhet för att hitta. Automatiserad testning passar bra i snabba processer som kontinuerlig integrering (CI), medan manuell testning krävde noggrann samordning med skickliga testare för att täcka allt som automatiserade verktyg inte kunde.

På vägen upptäckte vi att det faktiskt finns en gyllene medelväg mellan de här två tillvägagångssätten. I samarbete med Assistiv Labs kombinerade vi bättre processer med heltäckande tjänstetestning för att skapa ett arbetsflöde för testning som omdefinierar automatiserat och manuellt. Det är något mitt emellan, en hybridmetod som dramatiskt ökar den automatiska täckningen och minskar den manuella samordningsbördan.

Nu upptäcker vi tydliga problem som är lätta att åtgärda på timmar i stället för veckor. Våra nya processer tar automatiskt reda på vad som är brådskande och skickar problem till rätt team, som vanligtvis löser dem inom några dagar.

Resultaten har varit både tekniska och kulturella. Vi ger feedback om tillgänglighet mycket snabbare, team löser buggar snabbare och tekniker i hela Asana har börjat tänka annorlunda om tillgänglighetsproblem.

Skapa processer för att prioritera tillgänglighetsbuggar

I Asanas storlek är ett starkt prioriteringsramverk som stöds av processer och styrningsprinciper avgörande. Teamen behöver veta vad som behöver schemaläggas i deras backloggar och när, och vad som behöver uppmärksamhet just nu.

Men det är lätt att underskatta hur svårt det är att prioritera tillgänglighetsbuggar. Prioriteringen bygger på en svindlande matris av unika faktorer, inklusive hjälpteknik, webbläsare, påverkade användargrupper, användarfeedback, produktområde, svårighetsgrad för korrigering, lösningar, WCAG-överensstämmelse och historiskt sammanhang. Vissa buggar kan ha funnits under en lång tid, men upptäcktes först nyligen. Andra dyker upp med nya funktioner. Och vissa är regressioner – funktioner som tidigare var tillgängliga men som nu inte är det.

För att skapa ett ramverk definierade vi formellt olika typer av tillgänglighetsbuggar så att vi kunde utforma effektiva arbetsflöden kring var och en. Ett viktigt steg var att definiera vad som utgjorde en regression och vad som inte gjorde det.

regression (substantiv)

Ett dokumenterat (finns det någon dokumentation av att detta fungerade, såsom tidigare buggar, kommentarstrådar, skärmbilder eller skärminspelningar?), reproducerbart (kan en kollega reproducera det med hjälp av de beskrivna stegen?) problem som tidigare fungerade men inte längre gör det.

Regressioner kan naturligtvis få hög prioritet – det sista någon vill är att tillgängligheten ska försämras. Detta kan i många fall förenkla prioriteringen avsevärt.

Det finns dock en hake. Regressioner definieras av ögonblicksbilder före och efter. En före-ögonblicksbild kan till exempel vara en video där funktionen fungerar och en efter-ögonblicksbild kan vara en video där ett nytt problematiskt resultat visas. Buggar har naturligtvis efter-ögonblicksbilder. Men att hitta före-ögonblicksbilden kräver vanligtvis att man gräver djupt.

Utan en pålitlig källa till före-ögonblicksbilder var det ofta inte värt att ta sig tid att undersöka om en bugg kunde prioriteras som en regression. Det var här en ny typ av automatisering visade sig vara oerhört användbar.

Fullständig automatisering av tillgänglighet

Fullt automatiserade tester är inte nya för tillgänglighetstestning eller för Asana. Tidigare gav axe DevTools och jsx-a11y för React oss en bred, horisontell täckning. Men de är ytliga. Vi ansåg att token-uppskattningen på 30 % för automatiserade tester i hela branschen var ganska nära de WCAG-kriterier som vi uppnådde. Begränsad täckning innebar att manuell testning fortfarande hittade buggar som automatiserade verktyg hade missat.

Vi behövde verktyg som kunde gå djupare. Verktyg som var mer i linje med våra principer för användarundersökningar och styrning. Och det är vad vi hittade med Assistiv. Tester för Assistivs heltäckande tjänst skrivs från grunden av Assistivs tekniker baserat på användarflöden och testparametrar som vi tillhandahåller. Sviten innehåller kortkommandon, riktiga skärmläsare, webbläsare och maskinvision som drivs av Assistiv Labs-molnet. Resultatet är mer än en simulering, där händelser överförs till en maskin på samma sätt som en mänsklig användare skulle göra, vilket maximerar täckningen av WCAG och bredare tillgänglighetsfrågor.

Automatisering av tillgänglighet från början till slut skiljer sig radikalt från traditionell automatisering och interagerar med Asana för att utföra uppgifter på samma sätt som en manuell testare skulle göra. Det är möjligt att täcka upp till 75 % av WCAG-kriterierna, beroende på testscenariot. Och det finns fortfarande experter med kritiskt tänkande som övervakar allt i realtid. Personer från både Asana och Assistiv är involverade i att utforma representativa användaråtgärder och granska resultaten, vilket drastiskt höjer nivån på automatiserad testning när det gäller omfattning, frekvens och noggrannhet.

Kombinera krafter

Med ett starkt prioriteringsramverk på plats och en ny automatisering som gick från att hitta en minoritet av buggar till majoriteten, implementerade vi ett kraftfullt prioriteringsarbetsflöde.

Först synkroniseras automatiserade tester med Asanas befintliga teknikpipeline. Nya problem upptäcks nästan i realtid och korreleras med de kodändringar som sannolikt orsakade dem.

Därefter granskar en tekniker från Assistiv för att filtrera bort falska positiva resultat och skapar ett ärende i Asanas backlog med kontextualiserad användarpåverkan och vägledning för åtgärder. Eftersom automatiserade tester körs kontinuerligt är en ögonblicksbild av tidigare tillstånd lätt tillgänglig och regressioner kan enkelt klassificeras. Vi upprätthåller automatiserade Asana-arbetsflöden som skickar problemet till rätt team.

I praktiken innebär det att regressioner vanligtvis flaggas inom 24 timmar efter en implementering och dokumenteras på ett sätt som är lätt att förstå för tekniker utan bakgrund inom tillgänglighet. Det gör det möjligt för vårt tillgänglighetsteam att fastställa en SLA för att hantera regressioner och låta produktteam ta hand om det. Ingen behöver argumentera för vilken regression som ska prioriteras först, som andra eller som sist. De är bara buggar som behöver åtgärdas.

Denna decentralisering leder direkt till ett mer hållbart program och mer inkluderande slutanvändarupplevelser. Vi har mycket mer handlingsfrihet och inflytande, mycket utrymme för kreativitet eftersom vi inte ständigt behöver släcka bränder. Och det i sin tur innebär att vi är gladare och effektivare.

Avkastning på investering i snabbare feedbackslingor

En bugg som går oupptäckt i veckor eller månader är dyr att åtgärda. Någon måste prioritera den till rätt team och se till att den prioriteras. Teknikern som den tilldelas är sannolikt inte samma tekniker som orsakade den. Även när de är det är det svårt att gräva fram det bortglömda sammanhanget, ändra inriktning eller samordna med andra team för att reda ut den tekniska skuld som har uppstått under de mellanliggande veckorna och månaderna.

I en mycket citerad IBM-studie fann man att det kostar 30 gånger mer att upptäcka buggar i produktionen än de som upptäcks under designfasen. Det låter sant.

När ingenjörer distribuerar en uppdatering på morgonen börjar eventuella tecken på regressioner normalt att dyka upp innan slutet av arbetsdagen. Feedbacken kommer så snabbt att våra end-to-end-tester vid flera tillfällen har varit de första som har varnat oss för generiska buggar i användargränssnittet, inte begränsade till skärmläsare eller tangentbordsnavigering.

När ingenjörerna började få snabbare feedback från end-to-end-testning märkte vi en minskning av den kognitiva belastningen vid prioritering. Tvetydigheten försvann. Ingenjörerna tänkte: ”Jag är ansvarig för det här eftersom jag levererade det i morse. Det fungerade igår och det är trasigt idag, jag måste åtgärda det nu.” Att fixa tillgänglighetsbuggar blir som ett muskelminne.

På Asana är tillgänglighetsbuggar bara buggar. Och de åtgärdas.

Ett bättre sätt att automatisera tillgänglighet

Innan vi införde heltäckande tillgänglighetstestning gjorde vårt tillgänglighetsteam betydande framsteg. På verksamhetssidan hade design- och teknikteam dokumenterade granskningsprocesser, regressionsdefinitioner och servicenivåavtal på plats. När det gällde testning fanns det automatiserade lösningar för snabba men ytliga rapporter och manuell kvalitetssäkring för noggranna men tidskrävande granskningar.

Med helomfattande testning har vi en teknisk lösning som kompletterar och ligger ovanpå befintliga insatser. Regressioner dokumenteras tidigare, mer i detalj och med mer bevis. Praktiskt taget ingen slösar tid på buggrapporter som inte är genomförbara eller reproducerbara.

Nu har vi en tydlig bild av vilka buggar som är nya och vilka som är gamla, vilka användarflöden de påverkar och vem som är ansvarig för att åtgärda dem. Vi kan ligga före i utvecklingen och fokusera på vår vision för Asanas tillgänglighet i framtiden.

Om författarna:  Cameron Cundiff (teknisk ledare) och Jiaxin Zheng (teknisk programchef) är båda medlemmar i Development Lifecycle-gruppen, som är dedikerad till att tillhandahålla verktyg som gör det möjligt för utvecklare att ta idéer till produktion snabbt, robust och på ett trevligt sätt.