Jak podnieśliśmy poziom testowania dostępności
Na początku naszej drogi do ułatwień dostępu zasadniczo podzieliliśmy testowanie ułatwień dostępu na dwie kategorie: zautomatyzowane i manualne. Pierwsze z nich służyło do szybkiego wykrywania łatwych do wykrycia algorytmicznie problemów, a drugie do wszystkich innych, których znalezienie wymagało więcej czasu i uwagi. Testy automatyczne dobrze pasowały do szybkich procesów, takich jak ciągła integracja (CI), podczas gdy testy ręczne wymagały starannej koordynacji z wykwalifikowanymi testerami, aby objąć wszystko, czego nie mogły zrobić narzędzia automatyczne.
Po drodze odkryliśmy, że w rzeczywistości istnieje optymalne połączenie tych dwóch podejść. We współpracy z Assistiv Labs połączyliśmy lepsze procesy z kompleksowym testowaniem usług, tworząc przepływ pracy, który na nowo definiuje testowanie automatyczne i manualne. Jest to coś pomiędzy, podejście hybrydowe, które znacznie zwiększa zasięg automatyzacji i zmniejsza koszty związane z ręczną koordynacją.
Teraz wykrywamy oczywiste, łatwe do naprawienia problemy w ciągu kilku godzin, a nie tygodni. Nasze nowe procesy automatycznie rozpoznają, co jest pilne, i przekazują problemy odpowiednim zespołom, które zazwyczaj rozwiązują je w ciągu kilku dni.
Wyniki są zarówno techniczne, jak i kulturowe. O wiele szybciej przekazujemy informacje zwrotne dotyczące dostępności, zespoły szybciej rozwiązują błędy, a inżynierowie w całej Asanie zaczęli inaczej myśleć o problemach związanych z dostępnością.
Tworzenie procesów do priorytetyzacji błędów związanych z dostępnością
Biorąc pod uwagę skalę Asany, niezbędna jest solidna struktura priorytetyzacji wspierana przez procesy i zasady zarządzania. Zespoły muszą wiedzieć, co należy zaplanować w ich backlogach i na kiedy, a także co wymaga uwagi w danej chwili.
Jednak łatwo jest nie docenić tego, jak trudno jest nadać priorytet błędom związanym z ułatwieniami dostępu. Priorytet opiera się na zawrotnej macierzy unikalnych czynników, w tym technologii wspomagających, przeglądarek, grup użytkowników, których dotyczy problem, informacji zwrotnych od użytkowników, obszaru produktu, trudności naprawy, obejść, zgodności z WCAG i kontekstu historycznego. Niektóre błędy mogły istnieć od dłuższego czasu, ale zostały wykryte dopiero niedawno. Inne pojawiają się wraz z nowymi funkcjami. A niektóre to regresje – funkcje, które kiedyś były dostępne, a teraz już nie.
Aby stworzyć strukturę, formalnie zdefiniowaliśmy różne typy błędów związanych z dostępnością, co pozwoliło nam zaprojektować usprawnione przepływy pracy dla każdego z nich. Istotnym krokiem było określenie, co stanowi regresję, a co nie.
regresja (rzecz.)
Udokumentowany (czy istnieje jakikolwiek zapis tego, że to działało, np. poprzednie błędy, wątki komentarzy, zrzuty ekranu lub nagrania z ekranu?), powtarzalny (czy współpracownik jest w stanie odtworzyć problem, wykonując opisane kroki?) problem, który wcześniej działał, a teraz już nie.
Regresje mogą oczywiście mieć wysoki priorytet – ostatnią rzeczą, jakiej ktokolwiek chce, jest pogorszenie dostępności. W wielu przypadkach może to znacznie uprościć ustalanie priorytetów.
Jest jednak pewien haczyk. Regresje są definiowane na podstawie migawki „przed” i „po”. Na przykład, migawką „przed” może być film przedstawiający działającą funkcjonalność, a migawką „po” może być film przedstawiający nowy problematyczny wynik. Błędy oczywiście mają migawki „po”. Jednak znalezienie migawki „przed” zazwyczaj wymaga głębokiego przeszukiwania.
Bez wiarygodnego źródła migawki „przed” często nie warto było poświęcać czasu na sprawdzenie, czy błąd można uznać za regresję. Właśnie w tym przypadku nowy rodzaj automatyzacji okazał się niezwykle pomocny.
Kompleksowa automatyzacja dostępności
W pełni zautomatyzowane testy nie są niczym nowym ani w testowaniu dostępności, ani w Asanie. W przeszłości axe DevTools i jsx-a11y dla Reacta zapewniały nam szeroki, poziomy zasięg. Są one jednak płytkie. Uznaliśmy, że szacunkowy token 30% dla testów automatycznych w całej branży był dość zbliżony do kryteriów WCAG, które osiągaliśmy. Ograniczony zakres oznaczał, że testy ręczne nadal wykrywały błędy, które umknęły zautomatyzowanym narzędziom.
Potrzebowaliśmy narzędzi, które mogłyby działać bardziej dogłębnie. Narzędzi, które byłyby bardziej zgodne z naszymi zasadami badań użytkowników i zarządzania. I właśnie takie narzędzia znaleźliśmy w Assistiv. Testy kompleksowej usługi Assistiv są pisane od podstaw przez inżynierów Assistiv w oparciu o przepływy użytkowników i parametry testowe, które dostarczamy. Pakiety obejmują skróty klawiaturowe, prawdziwe czytniki ekranowe, przeglądarki i widzenie maszynowe obsługiwane przez chmurę Assistiv Labs. Rezultat jest czymś więcej niż symulacją, ponieważ zdarzenia są przesyłane do maszyny w taki sam sposób, w jaki zrobiłby to człowiek, co maksymalizuje zakres zgodności z WCAG i rozwiązuje szersze problemy związane z dostępnością.
Kompleksowa automatyzacja dostępności radykalnie różni się od tradycyjnej automatyzacji, ponieważ współdziała z Asaną, aby wykonywać zadania w ten sam sposób, w jaki robiłby to tester ręczny. W zależności od scenariusza testowego można objąć do 75% kryteriów WCAG. A cały proces jest nadal nadzorowany przez rzeczywistych ekspertów, którzy myślą krytycznie. Pracownicy zarówno Asany, jak i Assistiv są zaangażowani w projektowanie reprezentatywnych działań użytkowników i przeglądanie wyników, co radykalnie podnosi poziom testów automatycznych pod względem zakresu, częstotliwości i dokładności.
Łączenie sił
Dzięki solidnej strukturze priorytetyzacji i nowej automatyzacji, która pozwoliła przejść od wyszukiwania niewielkiej liczby błędów do wyszukiwania większości, wdrożyliśmy potężny przepływ pracy priorytetyzacji.
Po pierwsze, automatyczne testy są synchronizowane z istniejącym procesem inżynieryjnym Asany. Nowe problemy są wykrywane niemal w czasie rzeczywistym i korelowane ze zmianami w kodzie, które prawdopodobnie je spowodowały.
Następnie inżynier Assistiv dokonuje przeglądu, aby odfiltrować fałszywe wyniki pozytywne, i tworzy zgłoszenie w backlogu Asany, podając kontekstowy wpływ na użytkownika i wskazówki dotyczące działań naprawczych. Ponieważ testy automatyczne są uruchamiane w sposób ciągły, migawka stanu „przed” jest łatwo dostępna, a regresje można łatwo sklasyfikować. Utrzymujemy zautomatyzowane przepływy pracy w Asanie, które kierują problem do właściwego zespołu.
W praktyce oznacza to, że regresje są zazwyczaj sygnalizowane w ciągu 24 godzin od wdrożenia i dokumentowane w sposób, który jest łatwy do zrozumienia dla inżynierów bez doświadczenia w zakresie ułatwień dostępu. Dzięki temu nasz zespół ds. ułatwień dostępu może ustalić umowę SLA dotyczącą rozwiązywania regresji i pozostawić to zespołom produktowym. Nikt nie musi uzasadniać, która regresja jest pierwsza, druga czy ostatnia. To po prostu błędy, które wymagają uwagi.
Ta decentralizacja bezpośrednio przekłada się na bardziej zrównoważony program i bardziej inkluzywne doświadczenia użytkowników końcowych. Mamy o wiele większą swobodę działania i wpływ, dużo miejsca na kreatywność, ponieważ nie musimy ciągle gasić pożarów. A to z kolei oznacza, że jesteśmy bardziej zadowoleni i efektywni.
Zwrot z inwestycji w szybsze pętle informacji zwrotnej
Naprawa błędu, który pozostaje niewykryty przez tygodnie lub miesiące, jest kosztowna. Ktoś musi go kategoryzować i przesłać do odpowiedniego zespołu, a także zadbać o to, aby został potraktowany priorytetowo. Inżynier, do którego jest przypisany, prawdopodobnie nie jest tym samym inżynierem, który go spowodował. Nawet jeśli tak jest, trudno jest odnaleźć zapomniany kontekst, zmienić bieg lub skoordynować działania z innymi zespołami, aby rozwiązać problem długu technicznego, który pojawił się w ciągu ostatnich tygodni i miesięcy.
Przekładając ten problem na liczby, często cytowane badanie IBM wykazało, że wykrywanie błędów w produkcji kosztuje 30 razy więcej niż wykrywanie ich na etapie projektowania. To brzmi prawdziwie.
Gdy inżynierowie wdrażają aktualizację rano, wszelkie oznaki regresji zazwyczaj zaczynają pojawiać się przed końcem dnia roboczego. Pętla informacji zwrotnej jest tak krótka, że nasze testy kompleksowe wielokrotnie jako pierwsze ostrzegały nas o ogólnych błędach interfejsu użytkownika, nieograniczających się do czytników ekranowych czy nawigacji za pomocą klawiatury.
Gdy inżynierowie zaczęli otrzymywać szybsze informacje zwrotne z testów kompleksowych, zauważyliśmy zmniejszenie kosztów poznawczych związanych z ustalaniem priorytetów. Niejednoznaczność zniknęła. Inżynierowie myśleli: „Jestem za to odpowiedzialny, ponieważ wysłałem to dziś rano. Wczoraj działało, a dziś nie działa, więc muszę to teraz naprawić”. Naprawianie błędów związanych z ułatwieniami dostępu staje się czymś w rodzaju pamięci mięśniowej.
W Asanie błędy związane z dostępnością to po prostu błędy. I są naprawiane.
Lepszy sposób na automatyzację ułatwień dostępu
Przed wprowadzeniem kompleksowego testowania ułatwień dostępu nasz zespół ds. ułatwień dostępu poczynił znaczne postępy. Po stronie operacyjnej zespoły projektowe i inżynieryjne miały udokumentowane procesy przeglądu, definicje regresji i umowy SLA. Jeśli chodzi o testowanie, istniały zautomatyzowane rozwiązania do tworzenia szybkich, ale powierzchownych raportów oraz ręczne zapewnianie jakości do przeprowadzania dokładnych, ale czasochłonnych audytów.
Dzięki kompleksowemu rozwiązaniu mamy rozwiązanie techniczne, które uzupełnia istniejące działania i działa na ich bazie. Regresje są dokumentowane wcześniej, bardziej szczegółowo i z większą ilością dowodów. Praktycznie nikt nie traci czasu na zgłoszenia błędów, które nie są wykonalne lub odtwarzalne.
Teraz mamy jasny obraz tego, które błędy są nowe, a które stare, na które przepływy użytkowników mają wpływ i kto jest odpowiedzialny za ich naprawę. Możemy wyprzedzić konkurencję i skupić się na naszej wizji dostępności Asany w przyszłości.
O autorach: Cameron Cundiff (kierownik techniczny) i Jiaxin Zheng (techniczny menedżer programu) są członkami grupy Development Lifecycle, której celem jest dostarczanie narzędzi umożliwiających deweloperom szybkie, solidne i przyjemne wprowadzanie pomysłów do produkcji.
