Test QA oparty na AI przeprowadzony w przeglądarkowym narzędziu projektowym zgłosił „Wszystkie funkcje działają, sukces”, mimo że canvas nie wyświetlał niczego. Ten fałszywy sukces nie był błędem w rozumowaniu modelu; był efektem ubocznym sposobu, w jaki przeglądarka obsługuje ukryte karty oraz tego, jak skrypt testowy mierzył „stan kodu” zamiast wizualnego wyniku.

Dlaczego agenci AI QA mogą przeoczyć pusty canvas

Wykonują JavaScript, wykonują zrzuty ekranu i pozwalają modelowi wywnioskować, czy funkcja zadziałała poprawnie. W praktyce dwa techniczne „ślepe plamy” wielokrotnie generują wyniki pozytywne, mimo że interfejs użytkownika (UI) jest w rzeczywistości pusty.

Wyjaśnienie throttlingu w ukrytych kartach

Chrome MCP często uruchamia testy w kartach w tle, aby zwolnić główne okno do innych zadań. Gdy stan document.visibilityState karty jest ustawiony na hidden, przeglądarka ogranicza potok renderowania (rendering pipeline):

  • JavaScript nadal działa, więc nie pojawiają się błędy czasu wykonania (runtime errors).
  • Callbacki requestAnimationFrame przestają być wywoływane, co sprawia, że licznik klatek animacji wynosi zero.
  • Timery wyzwalane są znacznie rzadziej; test, który oczekiwał interwałów 33 ms, odnotował tylko cztery.

Agent AI widzi czyste wyniki JS oraz zrzut ekranu i zakłada, że animacja zadziałała. Ponieważ pętla renderowania nigdy nie wygenerowała pikseli, błąd wizualny pozostaje niewidoczny.

Rozwiązania problemów z ukrytymi kartami

  • Utrzymuj kartę testową jako widoczną dla każdego canvasa, animacji lub weryfikacji grafiki.
  • Wyzwalaj interakcje dopiero po przejściu karty na pierwszy plan.
  • Wstaw krótkie oczekiwanie (kilka sekund) przed wykonaniem zrzutu ekranu, aby upewnić się, że bufor klatek został wypełniony.
  • Jeśli należy użyć ukrytej karty, poprzedź raport zastrzeżeniem, np. „renderowanie nie zostało zaobserwowane wizualnie”.

Stan kodu (code health) a zachowanie funkcji

Większość skryptów AI QA ocenia „stan kodu”: potwierdzają, że obsługa kliknięć jest podpięta, że nie rzucono wyjątków JavaScript i że wymagane biblioteki zostały załadowane. Te sygnały dowodzą, że kod został uruchomiony, a nie że UI zmienił się zgodnie z przeznaczeniem. Element canvas może zostać utworzony, procedura rysowania wywołana, a mimo to nie wyświetlić niczego, jeśli polecenia rysowania celują w bufor o zerowym rozmiarze lub pusty zasób.

To rozróżnienie jest istotne, ponieważ poprawna ścieżka kodu może maskować brakujący artefakt wizualny.

Dodawanie kontroli zachowania

  1. Identyfikuj elementy dynamiczne – Przeszukaj źródło pod kątem tagów canvas, pól file-input, przycisków pobierania i pętli animacji.
  2. Zdefiniuj obserwowalne wyniki – Dla canvasa wymagaj sprawdzenia na poziomie pikseli, czy bitmapa nie jest pusta. Dla pola wejściowego pliku zweryfikuj, czy pojawia się obraz podglądu. Dla pobierania potwierdź, że plik został utworzony w systemie plików. Dla animacji sprawdź, czy śledzona właściwość zmienia się w czasie.
  3. Raportuj pokrycie – Dołącz do wyniku QA tabelę wymieniającą każdą funkcję, status stanu kodu oraz wynik weryfikacji zachowania. Wszystko, co nie posiada kontroli zachowania, powinno być oznaczone jako „unverified” zamiast „pass”.

Zastosowanie tej zasady drastycznie zmniejszyło liczbę wyników fałszywie dodatnich w zestawie testowym autora, a także ujawniło niezgodności CSS, gdzie arkusz stylów deklarował jeden kolor, ale wyrenderowany piksel był inny.

Praktyczne kroki dla niezawodnych testów wizualnych

  • Uruchamiaj testy w widocznej karcie zawsze, gdy funkcja obejmuje renderowanie.
  • Czekaj, aż UI się ustabilizuje; stałe opóźnienie kilku sekund często wystarcza, ale bardziej solidnym podejściem jest odpytywanie (polling) o niepusty canvas za pomocą getImageData.
  • Oddziel twierdzenia o stanie kodu od twierdzeń wizualnych w skrypcie testowym; pozwól modelowi AI oceniać je niezależnie.
  • Loguj stan widoczności i liczniki klatek (wywołania requestAnimationFrame) jako część diagnostycznego wyjściu.
  • Dokumentuj wszelkie nieuniknione uruchomienia w ukrytych kartach za pomocą wyraźnych ostrzeżeń, aby recenzenci mogli zrozumieć to ograniczenie.

Na co zwrócić uwagę w przyszłości

W miarę rozprzestrzeniania się narzędzi QA wspomaganych przez AI, programiści muszą traktować je jako asystentów, a nie arbitrów. Metryki stanu kodu zawsze będą niepełnym przybliżeniem zachowania widocznego dla użytkownika. Wniosek jest prosty: model AI może raportować tylko to, co widzi. Jeśli przeglądarka nigdy nie maluje obrazu, ponieważ karta jest ukryta, lub jeśli skrypt testowy nigdy nie zapyta „czy coś pojawiło się na ekranie?”, model z radością ogłosi sukces. Dodanie wymogu widoczności i kroku weryfikacji zachowania zamienia powierzchowny sukces w wiarygodny wynik.