Hoe we toegankelijkheidstesten naar een hoger niveau hebben getild

In het begin van onze toegankelijkheidsreis groepeerden we toegankelijkheidstests over het algemeen in twee categorieën: geautomatiseerd en handmatig. De eerste om snel algoritmisch detecteerbare, laaghangende problemen op te sporen en de tweede voor al het andere dat meer tijd en aandacht vereiste om te vinden. Geautomatiseerde tests passen goed in snelle processen zoals continue integratie (CI), terwijl handmatige tests zorgvuldige coördinatie met bekwame testers vereisten om alles te dekken wat geautomatiseerde tools niet konden.

Onderweg ontdekten we dat er eigenlijk een sweet spot is tussen deze twee benaderingen. In samenwerking met Assistiv Labs hebben we betere processen gecombineerd met end-to-end servicetesten voor een testworkflow die geautomatiseerd en handmatig opnieuw definieert. Het is iets tussenin, een hybride aanpak die de geautomatiseerde dekking drastisch verhoogt en de overhead voor handmatige coördinatie vermindert.

Nu vangen we duidelijke, eenvoudig op te lossen problemen op in uren in plaats van weken. Onze nieuwe processen zoeken automatisch uit wat er dringend is en sturen problemen naar de juiste teams, die ze meestal binnen enkele dagen oplossen.

De resultaten zijn zowel technisch als cultureel. We geven veel sneller feedback over toegankelijkheid, teams lossen bugs sneller op en engineers binnen Asana zijn anders gaan denken over toegankelijkheidsproblemen.

Processen bouwen om prioriteit te geven aan toegankelijkheidsbugs

Op de schaal van Asana is een sterk prioriteringsraamwerk, ondersteund door processen en bestuursprincipes, essentieel. Teams moeten weten wat er voor wanneer in hun backlogs moet worden gepland en wat er op dit moment aandacht nodig heeft.

Maar het is gemakkelijk om te onderschatten hoe moeilijk het is om prioriteit te geven aan toegankelijkheidsbugs. Prioriteit is gebaseerd op een duizelingwekkende matrix van unieke factoren, waaronder ondersteunende technologieën, browsers, getroffen gebruikersgroepen, gebruikersfeedback, productgebied, moeilijkheidsgraad van de oplossing, tijdelijke oplossingen, WCAG-conformiteit en historische context. Sommige bugs bestaan misschien al lang, maar zijn pas onlangs gedetecteerd. Andere verschijnen met nieuwe functies. En sommige zijn regressies - functionaliteit die vroeger toegankelijk was, maar nu niet meer.

Om een raamwerk te creëren, hebben we formeel verschillende soorten toegankelijkheidsbugs gedefinieerd, zodat we voor elk ervan gestroomlijnde workflows konden ontwerpen. Een essentiële stap was het definiëren van wat een regressie was en wat niet.

regressie (n)

Een gedocumenteerd (is er een verslag van dat dit werkte, zoals eerdere bugs, reactie-threads, schermafbeeldingen of schermopnames?), reproduceerbaar (kan een collega het reproduceren met behulp van de beschreven stappen?) probleem dat voorheen werkte en nu niet meer.

Regressies kunnen natuurlijk een hoge prioriteit krijgen - het laatste wat iemand wil is dat de toegankelijkheid achteruitgaat. Dit kan in veel gevallen de prioritering sterk vereenvoudigen.

Er is echter een addertje onder het gras. Regressies worden gedefinieerd door momentopnamen van voor en na. Een momentopname van ervoor kan bijvoorbeeld een video zijn van de functionaliteit die werkt en een momentopname van erna kan een video zijn van een nieuw problematisch resultaat. Bugs hebben van nature after-snapshots. Maar het vinden van de momentopname van de situatie voor vereist meestal diep graven.

Zonder een betrouwbare bron van voor-momentopnamen was het vaak de tijd niet waard om te onderzoeken of een bug als een regressie kon worden geprioriteerd. Dit is waar een nieuw soort automatisering enorm nuttig bleek te zijn.

End-to-end-automatisering van toegankelijkheid

Volledig geautomatiseerde tests zijn niet nieuw voor toegankelijkheidstesten of voor Asana. Historisch gezien boden axe DevTools en jsx-a11y voor React ons een brede, horizontale dekking. Maar ze zijn oppervlakkig. We vonden dat de token-schatting van 30% voor geautomatiseerde tests in de hele sector redelijk dicht bij de WCAG-criteria lag die we haalden. Beperkte dekking betekende dat handmatige tests nog steeds bugs vonden die geautomatiseerde tools hadden gemist.

We hadden tools nodig die dieper konden gaan. Tools die beter aansluiten op onze principes voor gebruikersonderzoek en governance. En dat is wat we hebben gevonden bij Assistiv. Tests voor de end-to-end-service van Assistiv worden vanaf het begin geschreven door Assistiv-engineers op basis van gebruikersflows en testparameters die wij leveren. De suites bevatten sneltoetsen, echte schermlezers, browsers en machine vision, mogelijk gemaakt door de Assistiv Labs-cloud. Het resultaat is meer dan simulatie, waarbij gebeurtenissen op dezelfde manier naar een machine worden verzonden als een menselijke gebruiker zou doen, waardoor de dekking van WCAG en bredere toegankelijkheidsproblemen wordt gemaximaliseerd.

End-to-end automatisering van toegankelijkheid is radicaal anders dan traditionele automatisering en werkt samen met Asana om Taken uit te voeren op dezelfde manier als een handmatige tester dat zou doen. Het is mogelijk om tot 75% van de WCAG-criteria te dekken, afhankelijk van het testscenario. En er zijn nog steeds live, kritisch denkende experts die over alles waken. Mensen van zowel Asana als Assistiv zijn betrokken bij het ontwerpen van representatieve gebruikersacties en het beoordelen van de resultaten, waardoor de lat voor geautomatiseerd testen drastisch wordt verhoogd wat betreft omvang, frequentie en nauwkeurigheid.

Krachten bundelen

Met een sterk prioriteringsraamwerk en nieuwe automatisering die overschakelde van het vinden van een minderheid van bugs naar de meerderheid, implementeerden we een krachtige prioriteringsworkflow.

Ten eerste worden geautomatiseerde tests gesynchroniseerd met de bestaande engineeringpijplijn van Asana. Nieuwe problemen worden bijna in realtime gedetecteerd en gecorreleerd met de codewijzigingen die ze waarschijnlijk hebben veroorzaakt.

Vervolgens beoordeelt een Assistiv-engineer om valse positieven eruit te filteren en schrijft hij een probleem in de backlog van Asana met gecontextualiseerde gebruikersimpact en herstelbegeleiding. Omdat geautomatiseerde tests continu worden uitgevoerd, is een momentopname van de situatie van voor de wijziging direct beschikbaar en kunnen regressies eenvoudig worden geclassificeerd. We onderhouden geautomatiseerde Asana-workflows die het probleem naar het juiste team routeren.

In de praktijk betekent dit dat regressies meestal binnen 24 uur na een implementatie worden gemarkeerd en gedocumenteerd op een manier die gemakkelijk te begrijpen is voor engineers zonder een achtergrond in toegankelijkheid. Dat stelt ons toegankelijkheidsteam in staat om een SLA in te stellen voor het aanpakken van regressies en het aan productteams over te laten. Niemand hoeft te beargumenteren welke regressie als eerste of tweede of als laatste komt. Het zijn gewoon bugs die aandacht nodig hebben.

Deze decentralisatie vertaalt zich direct in een duurzamer programma en meer inclusieve eindgebruikerservaringen. We hebben veel meer zeggenschap en impact, veel ruimte voor creativiteit, omdat we niet constant brandjes blussen. En dat betekent op zijn beurt dat we gelukkiger en effectiever zijn.

De ROI van snellere feedbackloops

Een bug die weken of maanden onopgemerkt blijft, is duur om op te lossen. Iemand moet deze triageren naar het juiste Team en ervoor zorgen dat er prioriteit aan wordt gegeven. De engineer aan wie de taak is toegewezen, is waarschijnlijk niet dezelfde engineer die de bug heeft veroorzaakt. Zelfs als dat wel het geval is, is het moeilijk om de vergeten context op te graven, van richting te veranderen of met andere teams te coördineren om de technische schuld te ontwarren die in de tussenliggende weken en maanden is ontstaan.

Uit een veel geciteerde IBM-studie bleek dat het 30 keer meer kost om bugs in productie te ontdekken dan bugs die tijdens de ontwerpfase worden gevonden. Dat klinkt waar.

Wanneer engineers 's ochtends een update implementeren, zullen eventuele tekenen van regressies normaal gesproken voor het einde van de werkdag beginnen op te duiken. De feedbacklus is zo kort dat onze end-to-end-tests de eerste zijn geweest die ons bij meerdere gelegenheden hebben gewaarschuwd voor algemene UI-bugs, niet beperkt tot schermlezers of toetsenbordnavigatie.

Toen engineers sneller feedback kregen van end-to-end-testen, merkten we een vermindering van de cognitieve overhead van prioritering. De onduidelijkheid was verdwenen. Engineers dachten: "Ik ben hier verantwoordelijk voor omdat ik het vanmorgen heb verzonden. Het werkte gisteren en het is vandaag kapot, ik moet het nu oplossen." Het oplossen van toegankelijkheidsbugs wordt als spiergeheugen.

Bij Asana zijn toegankelijkheidsbugs gewoon bugs. En ze worden opgelost.

Een betere manier om toegankelijkheid te automatiseren

Voordat we end-to-end toegankelijkheidstesten gingen toepassen, had ons toegankelijkheidsteam al aanzienlijke vooruitgang geboekt. Aan de Operations-kant hadden ontwerp- en engineeringteams gedocumenteerde beoordelingsprocessen, regressiedefinities en SLA's. Als het om testen ging, waren er geautomatiseerde oplossingen voor snelle maar oppervlakkige rapporten en handmatige QA voor grondige maar tijdrovende audits.

Met end-to-end hebben we een technische oplossing die de bestaande inzet aanvult en er bovenop zit. Regressies worden eerder gedocumenteerd, met meer detail en met meer bewijs. Vrijwel niemand verspilt tijd aan bugrapporten die niet uitvoerbaar of reproduceerbaar zijn.

Nu hebben we een duidelijk beeld van welke bugs nieuw zijn en welke oud, welke gebruikersflows ze beïnvloeden en wie verantwoordelijk is voor het verhelpen ervan. We kunnen voorop lopen en ons concentreren op onze visie voor de toegankelijkheid van Asana in de toekomst.

Over de auteurs:  Cameron Cundiff (Technisch Leider) en Jiaxin Zheng (Technisch Programmamanager) zijn beide lid van de Development Lifecycle-groep, die zich toelegt op het leveren van tools waarmee ontwikkelaars ideeën snel, robuust en op een prettige manier in productie kunnen brengen.