QA-тестування на базі ШІ у веб-інструменті дизайну повідомило: «Усі функції працюють, пройдено», проте canvas нічого не відображав. Це хибне проходження не було помилкою в міркуваннях моделі; це був побічний ефект того, як браузер обробляє приховані вкладки та як тестовий скрипт вимірював «стан коду» замість візуального виводу.

Чому AI QA-агенти можуть пропускати порожній canvas

Вони виконують JavaScript, роблять скриншоти та дозволяють моделі зробити висновок про те, чи правильно працювала функція. На практиці дві технічні «сліпі зони» постійно призводять до результатів «пройдено», коли інтерфейс (UI) насправді порожній.

Пояснення обмеження (throttling) прихованих вкладок

Chrome MCP часто запускає тести у фонових вкладках, щоб звільнити основне вікно для іншої роботи. Коли стан document.visibilityState вкладки є hidden, браузер обмежує конвеєр рендерингу:

  • JavaScript продовжує працювати, тому помилок під час виконання не виникає.
  • Коллбеки requestAnimationFrame перестають викликатися, через що лічильник кадрів анімації залишається на нулі.
  • Таймери спрацьовують набагато рідше; тест, який очікував інтервали у 33 мс, зафіксував лише чотири.

AI-агент бачить чисті результати JS та скриншот і припускає, що анімація спрацювала. Оскільки цикл рендерингу ніколи не створював пікселів, візуальний дефект залишається прихованим.

Виправлення проблем із прихованими вкладками

  • Тримайте вкладку тесту видимою для будь-якої перевірки canvas, анімації або графіки.
  • Запускайте взаємодію лише після того, як вкладка стане на передній план.
  • Додайте коротку затримку (кілька секунд) перед створенням скриншота, щоб переконатися, що буфер кадрів заповнений.
  • Якщо необхідно використовувати приховану вкладку, додайте до звіту застереження на кшталт «рендеринг візуально не спостерігався».

Стан коду проти поведінки функцій

Більшість AI QA-скриптів оцінюють «стан коду» (code health): вони підтверджують, що обробники кліків підключені, що не виникло винятків JavaScript і що необхідні бібліотеки завантажені. Ці сигнали доводять, що код виконувався, а не те, що UI змінився так, як планувалося. Елемент canvas може бути створений, процедура малювання викликана, але при цьому нічого не відобразиться, якщо команди малювання спрямовані на буфер нульового розміру або порожній ассет.

Ця різниця є важливою, оскільки справний шлях виконання коду може маскувати відсутність візуального артефакту.

Додавання перевірок поведінки

  1. Визначте динамічні елементи — проскануйте вихідний код на наявність тегів canvas, полів file-input, кнопок завантаження та циклів анімації.
  2. Визначте спостережувані результати — для canvas вимагайте перевірки на піксельному рівні, щоб бітмап не був порожнім. Для file input перевіряйте появу попереднього перегляду зображення. Для завантаження підтверджуйте створення файлу у файловій системі. Для анімацій перевіряйте, чи змінюється відстежувана властивість з часом.
  3. Звіт про покриття — додайте до результатів QA таблицю зі списком кожної функції, статусом стану коду (code-health) та результатом перевірки поведінки. Усе, що не має перевірки поведінки, має позначатися як «не перевірено» (unverified), а не «пройдено» (pass).

Застосування цього правила суттєво зменшило кількість хибнопозитивних результатів у тестовому наборі автора, а також виявило невідповідності CSS, де таблиця стилів оголошувала один колір, але відрендерений піксель відрізнявся.

Практичні кроки для надійного візуального тестування

  • Запускайте тести у видимій вкладці, якщо функція передбачає рендеринг.
  • Дочекайтеся стабілізації UI; фіксованої затримки у кілька секунд часто достатньо, але надійнішим підходом є опитування (polling) canvas на наявність даних за допомогою getImageData.
  • Розділяйте твердження про стан коду та візуальні твердження у тестовому скрипті; дозвольте моделі ШІ оцінювати кожне незалежно.
  • Логуйте стан видимості та лічильники кадрів (виклики requestAnimationFrame) як частину діагностичного виводу.
  • Документуйте будь-які неминучі запуски у прихованих вкладках чіткими попередженнями, щоб наступні рецензенти розуміли обмеження.

На що звернути увагу далі

Оскільки інструменти QA за допомогою ШІ стають дедалі поширенішими, розробники повинні ставитися до них як до помічників, а не як до арбітрів. Метрики стану коду завжди будуть неповним проксі-показником поведінки, з якою стикається користувач. Висновок простий: модель ШІ може повідомити лише те, що вона бачить. Якщо браузер нічого не малює, тому що вкладка прихована, або якщо тестовий скрипт ніколи не запитує «чи з'явилося щось на екрані?», модель з радістю оголосить успіх. Додавання вимоги видимості та кроку перевірки поведінки перетворює «глянцевий» результат проходження тесту на надійний результат.