Веб-приложение - это не просто "сайт с кнопками". Для QA это отдельная среда со своими законами: браузер, DOM, сеть, кэш, cookie, storage, JavaScript, вкладки, permissions, адаптивность, различия между движками и устройствами. Именно поэтому web testing почти никогда не сводится к одной проверке "страница открылась и форма отправилась".
Главная особенность веб-приложения в том, что оно живёт сразу в двух мирах. С одной стороны есть backend, API, база и бизнес-логика. С другой - браузер как платформа, которая сама влияет на поведение продукта. Даже если backend работает идеально, пользователь всё равно может увидеть баг из-за рендера, кэша, состояния вкладки, особенностей браузера, расширений, размеров экрана или клиентского кода.
Что делает web-приложение особенным
У веба есть несколько базовых свойств, которые QA должен держать в голове почти постоянно.
- →приложение работает внутри браузера, а не в полностью контролируемой среде
- →UI собирается из HTML, CSS и JavaScript, и баг может жить в любом из этих слоёв
- →данные часто приходят асинхронно, поэтому страница редко бывает "целиком готова" сразу
- →состояние может храниться не только на сервере, но и в cookie, localStorage, sessionStorage, URL, памяти вкладки
- →поведение зависит от браузера, устройства, сети, разрешений, локали и viewport
- →пользовательский сценарий часто состоит не из одной страницы, а из цепочки переходов, модалок, фоновых запросов и client-side state
Для QA это означает простую вещь: web-приложение нельзя тестировать только глазами. Нужно понимать, что происходит под интерфейсом.
Какие слои обычно участвуют в веб-сценарии
Даже простой сценарий вроде "пользователь вошёл в систему и отредактировал профиль" обычно включает несколько слоёв:
- →HTML - структура страницы
- →CSS - отображение, layout, адаптивность, состояния элементов
- →JavaScript - логика интерфейса, события, запросы, клиентская валидация
- →браузерные API - cookie, storage, history, permissions, fetch, cache
- →network layer - запросы, ответы, статусы, редиректы, таймауты
- →backend - бизнес-логика, авторизация, данные
Поэтому один баг "не сохраняется профиль" может означать совсем разные вещи:
- →кнопка disabled из-за фронтовой логики
- →запрос не отправился
- →запрос ушёл, но backend вернул ошибку
- →ответ успешный, но UI не обновился
- →кэш или state показывают старые данные
- →CSS скрывает сообщение об успехе или ошибке
Именно это делает web QA сильнее backend-only или UI-only подхода. Нужно видеть систему целиком.
Что особенно важно QA в вебе
Есть несколько тем, которые в web testing всплывают постоянно.
Первая - состояние интерфейса. Элемент может быть видимым, скрытым, disabled, перекрытым другим слоем, доступным только после async-загрузки или находиться вне viewport. Визуально "кнопка есть", но технически пользователь может не иметь возможности ею воспользоваться.
Вторая - сеть и асинхронность. Страница редко работает как статичный HTML-документ. Часть данных приходит позже, часть действий уходит фоном, часть интерфейса обновляется без reload. Это значит, что баги часто сидят в race condition, delayed render, stale state и неправильной обработке ошибок.
Третья - браузерное окружение. Cookie, localStorage, sessionStorage, кэш, service worker, timezone, locale, permissions и расширения браузера могут сильно влиять на сценарий.
Четвёртая - различия устройств и браузеров. Даже если продукт "в целом работает", это не значит, что он одинаково стабилен в Chrome, Safari, Firefox и mobile browser.
Почему веб часто кажется "нестабильным"
Новички нередко говорят: "на вебе всё какое-то случайное". Обычно причина не в магии, а в том, что в одном месте пересекаются сразу несколько источников состояния.
- →старый response живёт в кэше
- →новый запрос ещё не завершился
- →UI уже перешёл в новое состояние
- →cookie обновилась не так, как ожидалось
- →вкладка сохранила старый client state
- →backend уже изменил данные, а frontend ещё показывает предыдущую версию
Снаружи это выглядит как "то работает, то нет". Для QA это сигнал, что нужно смотреть глубже: в DevTools, network, storage, консоль и последовательность событий.
На что смотреть при обычном web testing
Полезный baseline для QA здесь такой:
- →как страница загружается на чистой сессии
- →что происходит при медленной сети
- →как ведёт себя UI до и после ответа API
- →корректно ли работают ошибки и пустые состояния
- →не ломается ли layout на других размерах экрана
- →не пропадает ли функциональность при обновлении страницы, переходе назад, открытии в новой вкладке
- →правильно ли живут cookie, storage и пользовательская сессия
- →одинаково ли ведёт себя сценарий в ключевых браузерах
Это не значит, что каждый раз нужно прогонять всё. Но именно из этих зон чаще всего и вылезают настоящие web-баги.
Практический пример
Представь форму логина.
Пользователь вводит email и пароль, нажимает кнопку и ждёт входа в систему. На вид сценарий очень простой. Но в реальности QA полезно проверить намного больше:
- →работает ли submit и по Enter, и по кнопке
- →есть ли клиентская валидация и не конфликтует ли она с серверной
- →что происходит при медленной сети
- →сохраняется ли сессия после reload страницы
- →что происходит в новой вкладке
- →не остаётся ли пользователь "залогинен визуально", если токен уже невалиден
- →как ведёт себя сценарий в Safari или mobile browser
- →нет ли странностей из-за cookie policy, CORS, redirect или storage
То есть даже логин в web-приложении - это не один клик, а набор взаимосвязанных слоёв.
Что должен вынести QA из этой темы
- →Веб-приложение - это не только backend плюс экран, а ещё и браузер как полноценная платформа.
- →Один пользовательский баг в вебе может рождаться в HTML, CSS, JavaScript, сети, storage или backend.
- →Асинхронность, кэш и клиентское состояние делают web testing особенно чувствительным к деталям.
- →Хороший web QA почти всегда работает не только глазами, но и через DevTools, network и понимание браузерного поведения.
- →Чем лучше тестировщик понимает устройство веба, тем меньше для него "случайных" багов.
Что ещё почитать
- →Внутри базы: HTML, CSS, JavaScript для QA
- →Внутри базы: HTTP и HTTPS
- →Внешний материал: MDN: Web technology for developers
- →Внешний материал: web.dev: Learn PWA