Automatyzacja testów i inżynieria danych
Zmierzyłem 1554 witryny. Potem sprawdziłem, czy tym pomiarom można ufać.
Zbudowałem system, który automatycznie bada strony internetowe, i pięć niezależnych testów, które weryfikują jego wyniki. Testy wykryły trzy klasy błędnych danych — w tym takie, które system raportował jako poprawne pomiary.
Przeczytaj badanie (po angielsku)Czego szukam
Szukam kontraktu B2B, zdalnie — przy automatyzacji testów albo przy budowie i utrzymaniu potoków danych.
Ten projekt nie pokazuje znajomości dostępności. Dostępność jest tu wyłącznie dziedziną, na której pracowałem. Pokazuje co innego:
- sterowanie przeglądarką przez Chrome DevTools Protocol w skali 1950 domen,
- pomiar na drzewie dostępności zamiast na surowym HTML — tych samych danych, które otrzymuje czytnik ekranu,
- integrację z niestabilnym API zewnętrznym: ponawianie, przełączanie na serwery zapasowe, dzielenie zbyt ciężkich zapytań,
- stabilność długiego przebiegu: restart przeglądarki co N stron, próg wolnej pamięci, zapis częściowy, wznawianie po przerwaniu,
- warstwę weryfikacji, która traktuje wynik własnego systemu jako podejrzany, dopóki nie potwierdzi go inne narzędzie.
Jak weryfikowałem wyniki
Zmierzenie 1554 witryn to łatwiejsza połowa pracy. Trudniejsza to ustalenie, które z otrzymanych liczb są prawdziwe. Napisałem do tego pięć niezależnych testów. Żaden z nich nie korzysta z kodu skanera — sprawdzanie własnej pracy tą samą logiką powiela błąd, zamiast go wykryć.
| Test | Co znalazł |
|---|---|
| Weryfikacja krzyżowa silnikiem axe-core | Na 1554 witrynach zmierzonych obydwoma silnikami werdykty zgodziły się w 80,8% przypadków: 109 witryn wykrył wyłącznie axe-core, 23 wyłącznie mój własny detektor. Tam, gdzie się różniły, opublikowałem liczbę axe, nie swoją. |
| Test rzetelności | Napisany od nowa, bez użycia kodu skanera. Bada zarówno fałszywe alarmy, jak i fałszywe przeoczenia — liczba zaniżona jest tak samo nierzetelna jak zawyżona. |
| Tożsamość źródła danych | 6 domen na 1133 wygasło i zostało przejętych przez osoby trzecie. Każda trafiłaby do zestawienia jako restauracja z naruszeniami, prowadząc w rzeczywistości zupełnie gdzie indziej. |
| Wartości skrajne | Strony z najwyższymi wynikami przeliczone osobnym kodem, ponieważ dominacja jednej kategorii w skrajnościach zwykle oznacza wadę detektora, a nie stan rzeczywisty. |
| Treść wstrzyknięta | Witryny z ukrytym spamem wykluczone z badania, zamiast liczyć je jako naruszenia dostępności. Wymagane dwa niezależne sygnały, żeby nikomu nie zgłosić włamania, którego nie było. |
| Żaden silnik nic nie zgłosił | 797 · 51,3% | |
|---|---|---|
| Oba silniki zgodne | 625 · 40,2% | |
| Tylko axe-core | 109 · 7,0% | |
| Tylko mój detektor | 23 · 1,5% |
| Przekierowanie na inną domenę | 132 · 37,6% | |
|---|---|---|
| Strona praktycznie pusta | 99 · 28,2% | |
| Błąd nawigacji | 94 · 26,8% | |
| Strona błędu przeglądarki | 12 · 3,4% | |
| Domena zaparkowana | 9 · 2,6% | |
| Błąd HTTP 403 / 500 | 5 · 1,4% |
Najważniejsze, co z tego wyszło. Dwanaście witryn oddało stronę blokady zamiast witryny — tytuł „Access Denied”, od 52 do 265 znaków treści — a system mierzył to jako treść restauracji i raportował udany pomiar. Jedenaście z dwunastu oddało przy tym kod HTTP 200. Sprawdzanie samego kodu odpowiedzi nie wykryłoby żadnej z nich: liczby się zgadzały, a wynik był fałszywy.
Od tego czasu żaden rekord nie trafia do statystyk bez kodu odpowiedzi HTTP, adresu końcowego i jawnego werdyktu. Z 1950 zebranych domen do pomiaru zakwalifikowałem 1599, czyli 82%. Pozostałe odrzuciłem z podaniem przyczyny, zamiast usuwać po cichu.
Czego ten projekt nie dowodzi
Testy automatyczne obejmują może jedną trzecią wytycznych WCAG 2.1 AA. Pułapki klawiaturowe, kolejność fokusa, to czy tekst alternatywny rzeczywiście cokolwiek mówi — tego maszyna nie oceni i axe też nie. Każda opublikowana przeze mnie liczba jest więc dolną granicą, a nie górną.
Nie jestem audytorem dostępności i nie mam certyfikatu w tej dziedzinie. Jeżeli ktoś potrzebuje pełnego audytu, powinien zatrudnić kogoś, kto takie audyty wykonuje.
Kod — trzy repozytoria
- skaner-dostepnosci — sam skaner oraz pięć niezależnych testów weryfikujących.
- skaner-playwright — ten sam pomiar przepisany na Pythona i Playwright, z zestawieniem obu wyników. Zgodność werdyktu 100%.
- analiza-dostepnosci-sql — analiza w SQL, uzgodnienie opublikowanych liczb co do rekordu.
Skaner napisany jest w PowerShellu, wersja druga w Pythonie z Playwrightem, analiza w SQL.
Kontakt
Najszybciej i najchętniej — mailem. Jeżeli chcesz porozmawiać o metodzie, o kodzie albo o współpracy, napisz, a odpowiem.
Preferowany kontakt: e-mail
contact@provenaccess.com
Praca zdalna, kontrakt B2B. Pracuję z Polski.