Особенности тестирования веб-приложений (обновлено в 2026)

Обновлено: 27.05.2026

Доводилось ли вам тестировать веб-приложения? Практически любой специалист по тестированию программного обеспечения с опытом более года даст утвердительный ответ на этот вопрос, ведь существуют вполне объективные причины такого положения дел:

• по данным на 2025 год, в сети Интернет действует более 1,1 миллиарда сайтов, а пользуются ими порядка 5,5 миллиарда человек по всему миру;
• в России интернет-аудитория превысила 130 миллионов человек, а объем рынка интернет-торговли по итогам 2024 года достиг отметки в 8,6 трлн. рублей и продолжает уверенно расти двузначными темпами.

При взгляде на эти баснословные цифры становится понятным, почему в мире разрабатывается так много новых веб-приложений. Этот процесс приводит к необходимости привлечения большого количества специалистов. То, что веб (в широком смысле) будет продолжать наращивать темпы своего развития, подтверждается и набирающим силу «мейнстримом»: всё «переезжает» в облака. Облачные технологии давно стали новой реальностью современного Интернета: некогда привычные нам десктопные Word и Excel сегодня представлены в виде веб-альтернатив от Microsoft, а на смену тяжелым клиентам всё чаще приходят SPA, PWA и приложения на базе WebAssembly. Исходя из сказанного, можно утверждать, что потребность в хороших инженерах по обеспечению качества, специализирующихся на веб-продуктах, будет только расти.

Мы готовы начать работу прямо сейчас.

Представленная вниманию читателей статья посвящена вопросам особенностей тестирования веб-приложений. Будет правильным начать повествование с основ и определиться, что именно мы подразумеваем под понятием «веб-приложение» и какие нюансы в реализации этих приложений добавляют работу тестировщикам.

Клиент, сервер и база данных

Веб-приложение – это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером – веб-сервер (в широком смысле). Основная часть приложения, как правило, находится на стороне веб-сервера, который обрабатывает полученные запросы в соответствии с бизнес-логикой продукта и формирует ответ, отправляемый пользователю. На этом этапе в работу включается браузер, именно он преобразовывает полученный ответ от сервера в графический интерфейс, понятный рядовому пользователю.

Итак, первой и одной из ключевых особенностей веб-приложений является их архитектура. Давайте более детально рассмотрим этот вопрос, так как он представляет особую ценность для тестирования.

Веб-приложение представлено следующими составляющими («сторонами»):
1. Клиент.
Как правило, клиент – это браузер, но встречаются и исключения (в тех случаях, когда один веб-сервер (ВС1) выполняет запрос к другому (ВС2), роль клиента играет веб-сервер ВС1). В классической ситуации (когда роль клиента выполняет браузер) для того, чтобы пользователь увидел графический интерфейс приложения в окне браузера, последний должен обработать полученный ответ веб-сервера, в котором будет содержаться информация, реализованная с применением HTML, CSS, JS (самые используемые технологии). Современные приложения всё чаще строятся как SPA (Single Page Application) на React, Vue или Angular — в этом случае браузер получает «оболочку» приложения, а данные подгружает в фоне через API. Именно эти технологии «дают понять» браузеру, как именно необходимо «отрисовать» все, что он получил в ответе.

2. Сервер.
Веб-сервер – это сервер, принимающий HTTP-запросы от клиентов и выдающий им HTTP-ответы. Дабы избежать возможной путаницы, отметим, что веб-сервером называют как программное обеспечение, выполняющее функции веб-сервера, так и непосредственно компьютер, на котором это программное обеспечение работает. Наиболее распространенными видами ПО веб-серверов являются NGINX, Apache, IIS, а также набирающие популярность Caddy и LiteSpeed. На веб-сервере функционирует тестируемое приложение, которое может быть реализовано с применением самых разнообразных языков программирования: PHP, Python, Ruby, Java, JavaScript (Node.js), Go, C#, Rust и пр.

3. База данных.
В классической теории речь идет о двух «сторонах» веб-приложения, однако, если внимательно посмотреть на весь процесс работы приложений, мы можем отметить, что в алгоритме работы веб-а незримо, но довольно активно принимает участие еще одна «сторона» – база данных. Фактически, она не является частью веб-сервера, но большинство приложений просто не могут выполнять все возложенные на них функции без нее, так как именно в базе данных хранится вся динамическая информация приложения (учетные, пользовательские данные и пр).

База данных – довольно широкое понятие, которое используется не только в сфере информационных технологий. В контексте моей статьи это – информационная модель, позволяющая упорядоченно хранить данные об объекте или группе объектов, обладающих набором свойств, которые можно категоризировать. Базы данных функционируют под управлением так называемых систем управления базами данных (далее – СУБД). Самыми популярными реляционными СУБД являются PostgreSQL, MySQL, MS SQL Server, Oracle. Помимо них, в современных проектах активно используются NoSQL-решения: MongoDB (документная БД), Redis (key-value хранилище и кэш), Elasticsearch (поисковая БД), ClickHouse (аналитическая колоночная БД). Тестировщику веб-приложений сегодня важно понимать, что данные могут лежать одновременно в нескольких хранилищах, и это нужно учитывать при проверках.

Также существуют встраиваемые и файл-серверные СУБД. Для общего развития отмечу лишь одну популярную встраиваемую СУБД – SQLite, которая используется в браузерах, Android API и многих десктопных приложениях. Взаимодействие с реляционными СУБД основано на специальном языке структурированных запросов – SQL; для NoSQL-баз используются свои подходы (от JSON-подобных запросов в MongoDB до простых команд SET/GET в Redis).

Теперь, собрав в голове определенный архитектурный пазл, предлагаю рассмотреть его с точки зрения тестирования ПО. Несколько позже мы рассмотрим и то, как все составляющие «общаются» между собой.

Особенности архитектуры: «под прицелом» клиент

Мы упомянули клиента как первую составляющую архитектуры. В классической ситуации клиент представлен браузером, а потому вопрос тестирования кроссбраузерности (ввиду многообразия браузеров) весьма актуален. Мы также рассмотрим тестирование заполняемых форм и текста как основного источника информации, получаемой через клиента.

Кроссбраузерность: разнообразие клиентов
Что мы понимаем под тестированием на кроссбраузерность? Это проверка на правильность (соответствие требованиям и стандартам) отображения и функционирования веб-приложения в разных браузерах и на разных операционных системах. В современном мире стандартизация принимает глобальные масштабы, а потому большинство популярных браузеров одинаково обрабатывают код. При этом необходимость в кроссбраузерном тестировании не исчезает, так как далеко не все проблемы решаются стандартизацией.

Перед началом работ я рекомендую выяснять у ответственных лиц необходимый для тестируемого ПО набор браузеров. Можно самим собрать статистику по целевой аудитории вашего продукта и ограничить кроссбраузерное тестирование набором наиболее популярных в этой аудитории браузеров. А можно нанять профессионалов.

В условиях регрессионного тестирования, когда ограничены временные и человеческие ресурсы, также можно применять практику распределения браузеров: закрепляя за каждым тестировщиком определенный браузер, вы сможете «покрыть» большой процент кроссбраузерных дефектов. Этот метод имеет и свои минусы: он наиболее результативен в большой команде тестирования, но становится практически неприменимым при наличии одного тестировщика.

Что необходимо проверять при кроссбраузерном тестировании:

• функциональные возможности продукта, реализуемые на стороне клиента;
• правильность отображения элементов графики;
• шрифты и размеры текстовых символов;
• доступность и функциональность разнообразных форм, включая их интерактивность.

В тестировании нуждаются все основные (среди пользовательской аудитории) браузеры. Если в 2017 году главной головной болью был Internet Explorer, то с июня 2022 года Microsoft официально прекратила его поддержку, и эта эпоха ушла в прошлое. Сегодня главные «болевые точки» сместились: основная экосистема построена на Chromium (Chrome, Edge, Opera, Яндекс.Браузер), но особое внимание стоит уделять Safari, особенно его мобильной версии на iOS — у него собственный движок WebKit, и многие современные веб-фичи там работают с задержкой или с нюансами. Также не стоит забывать про Firefox с его движком Gecko и проверку приложений в современных российских браузерах. Для запуска всего этого «зоопарка» в одном месте удобно использовать облачные платформы вроде BrowserStack, LambdaTest или Sauce Labs — они дают доступ к реальным конфигурациям без необходимости держать парк устройств.

Отдельно рекомендую не забывать о всякого рода валидаторах верстки, например https://validator.w3.org/. Даже если у вас недостаточно знаний, чтобы оценить соответствие верстки стандартам, можно использовать для этого автоматические средства и, проанализировав результат, указать разработчикам на самые серьезные «оплошности». Не стоит забывать, что иногда валидаторы обращают внимание на самые «мелочные мелочи», которые никто и никогда исправлять не будет. Если вы и заводите баг-репорты на подобного рода замечания, то удобнее будет собрать их в единый документ и прикрепить к репорту. К такого рода «мелочам» можно отнести всевозможные рекомендации, которые не имеют своего влияния на отображение и функционирование контента.

Веб-формы на стороне клиента
Одной из важных составляющих интернет-приложений являются формы для заполнения, взаимодействие с которыми пользователь осуществляет с помощью все того же пристально рассмотренного нами клиента. Однако, данные формы очень часто служат источником дефектов, которые, обосновавшись в «продакшене», могут принести большие финансовые и репутационные убытки компании.

Как же не пропустить дефекты в формах на продакшен? Рассмотрим несколько простых шагов:
1. Тщательно проверяем обязательность заполнения полей и наличие соответствующей маркировки у них.
2. Заполнив и отправив форму, убеждаемся в том, что с данными происходит именно то, что запланировано. Если данные должны быть внесены в базу данных, проверяем, корректно ли завершился процесс (в конце концов, об этом можно попросить разработчика, если не хватает своих знаний SQL или прав доступа к БД).
3. Используем чит-листы для тестирования форм и веб-контролов — их легко найти в современных подборках сообщества QA (Ministry of Testing, Habr, тематические Telegram-каналы).
4. Проверяем, выводятся ли понятные пользователю информационные сообщения о необходимости заполнения пустых полей после попытки отправить форму.
5. Обращаем пристальное внимание на реализацию экранирования символов в полях форм, являющихся потенциальным источником уязвимостей для приложения и пользователей. Экранирование должно осуществляться на уровне не только клиента, но и сервера. Клиентскую валидацию очень легко обойти — достаточно открыть DevTools (F12 в любом современном браузере), отредактировать атрибуты поля (убрать required, поменять type, увеличить maxlength) и отправить форму с любыми данными. Если на сервере валидации нет — это критическая уязвимость.
6. Убеждаемся, что после заполнения формы пользователю приходит подтверждающее письмо с указанием соответствующего отправителя, а само тело письма соответствует требованиям (в том числе и на работоспособность ссылок).
7. Используем встроенные DevTools браузера для модификации форм на лету, а также инструменты-перехватчики трафика (Postman, Insomnia, Bruno) для отправки заведомо «кривых» данных напрямую на сервер.

Текст, как основной источник информации при работе через клиент
Как не крути, но особая ценность сети Интернет заключается в том, что она является практически безграничным источником информации. Часть этой информации представлена в виде текстов, с которыми, опять же, пользователь взаимодействует посредством клиента. Большинство веб-ресурсов в том или ином объеме требуют проверки текстов на предмет отсутствия грамматических ошибок и опечаток.

Конечно, значимость этого тестирования не так велика по сравнению с функциональным направлением, но пренебрегать им не стоит. На практике мне довелось встретиться с очень серьезной опечаткой: на продакшене одного из крупнейших интернет-гипермаркетов России была допущена ошибка, изменившая гордое название величественного города Ярославль на прискорбное оскорбительное слово. Название служило частью суб-меню, а потому было заметно всем жителям города с полумиллионным населением.

Да, мы не всегда имеем достаточно времени для вычитывания всех текстов, но в таких ситуациях на помощь приходят «SpellCheker-ы» (программы для проверки орфографии, онлайн-сервисы и плагины для браузеров). Современный арсенал заметно расширился — помимо классических спелл-чекеров, в работу можно подключить и инструменты на базе ИИ, которые ловят не только орфографические, но и стилистические нестыковки.

Доступность (a11y): больше не «бонус», а обязательная проверка

В 2017 году тестирование доступности (accessibility, или сокращенно a11y) считалось чем-то экзотическим: его делали либо энтузиасты, либо команды крупных международных продуктов. К 2026 году ситуация изменилась радикально. С июня 2025 года в Европейском союзе вступил в силу European Accessibility Act, который обязывает большинство коммерческих веб-сервисов соответствовать стандартам доступности. В США аналогичные требования вытекают из закона ADA, по которому регулярно происходят судебные иски против сайтов, недоступных людям с ограниченными возможностями. В России законодательство тоже постепенно движется в эту сторону, особенно в отношении государственных и социально значимых сервисов.

Основным стандартом сегодня является WCAG 2.2 (опубликован в октябре 2023 года), а на горизонте — WCAG 3.0. Что должен проверить тестировщик в рамках базового a11y-аудита:

• навигацию по сайту с помощью одной только клавиатуры (Tab, Shift+Tab, Enter, стрелки) — все интерактивные элементы должны быть достижимы и иметь видимый фокус;
• корректность работы со скрин-ридерами: NVDA и JAWS на Windows, VoiceOver на macOS/iOS, TalkBack на Android;
• наличие осмысленных alt-текстов у изображений и ARIA-атрибутов у динамических элементов;
• достаточный цветовой контраст текста и фона (минимум 4.5:1 для обычного текста по WCAG AA);
• работоспособность интерфейса при увеличении масштаба страницы до 200%;
• отсутствие «ловушек фокуса», когда пользователь не может выйти из модального окна без мыши.

Для автоматизированной проверки удобно использовать axe DevTools, WAVE, Lighthouse (вкладка Accessibility) — они не заменяют ручное тестирование, но быстро отлавливают типовые ошибки разметки. Полноценный аудит без живого пользователя с ассистивными технологиями всё равно сделать нельзя, но базу автоматика покрывает.

Веб-сервер: «долой клиент, тестим без него»

Тестирование части веб-приложения, размещенной на веб-сервере, можно провести и минуя графический (клиентский) интерфейс, однако это требует от специалиста определенного уровня знаний и навыков технического характера, а также применения дополнительных инструментов. Рассмотрим веб-сервер с точки зрения нагрузочного и инсталляционного тестирования.

Инсталляция на веб-сервер
Итак, прежде чем приступить к тестированию, мы должны установить (инсталлировать) веб-приложение на веб-сервер. Собственно, в этом есть сходство с проверкой десктоп-приложений, но существует и различие в нюансах, которые необходимо учесть и протестировать, особенно если это касается ПО, распространяемого для локальной инсталляции на веб-серверы пользователей.

В чем же заключаются эти нюансы?

1. Большая часть веб-приложений требует для инсталляции специфических знаний в администрировании ОС. Попробуйте установить приложение на нескольких веб-серверах. В оптимальном случае это будут самые популярные технологии среди ваших пользователей, для установления списка которых потребуется предварительное исследование. Сегодня к классической инсталляции добавился контейнерный подход: значительная часть современных приложений поставляется в виде Docker-образов и разворачивается в Kubernetes-кластерах, что добавляет тестировщику новый слой проверок — корректность Helm-чартов, переменных окружения, секретов и сетевых политик.
2. Инсталлируя веб-приложение, обращайте внимание на то, действительно ли приложение устанавливается в указанную вами директорию, базу данных, использует выбранный вами префикс и соблюдает прочие конфигурационные моменты.
3. Убедитесь, что приложение можно установить как из localhost, так и удаленно.
4. Если процесс инсталляции является интерактивным, и каждый выбор пользователя на определенном шаге влияет на последующие действия, то необходимо будет пройти все ветви, так как именно инсталляция является первым шагом пользователя в работе с вашим приложением.
5. Не забывайте о негативных тестах: проверки в условиях недостаточности ресурсов (места на диске, оперативной памяти) или привилегий, прерывание процесса установки во время активной его фазы (например, отправляя сервер в перезагрузку).

Нагрузочное тестирование
Нагрузочное тестирование имитирует работу с приложением определенного количества пользователей. Этот вид тестирования осуществляется при помощи специальных инструментов: классическим инструментом остается Apache JMeter, но за последние годы серьезную долю рынка отвоевали более современные альтернативы — k6 (нагрузка через JavaScript-скрипты, удобная интеграция с CI/CD), Gatling (DSL на Scala), Locust (на Python). Главная цель остается прежней: определить профили нагрузки и искусственно создать для них нагрузку, выявляющую граничные возможности приложения (или сервера) в условиях работы с ним того или иного количества пользователей.

Полученная информация подвергается тщательному анализу с последующим выявлением «узких горлышек» и граничных программных и аппаратных возможностей, которые в дальнейшем используются для обеспечения стабильности веб-сервера и самого приложения, работающего на нем.

Приведем пример из практики функционирования большого коммерческого продукта, который долгое время работал с разнообразными типами договоров. Однажды в релиз выпустили очередной особо ожидаемый тип договора, и на следующий день система полностью перестала работать, а служба поддержки была завалена огромным количеством обращений. Всему виной стал просчет в тестировании: команда проверяла одновременную работу с десятками тысяч договоров, но никто не смог предугадать, что на практике речь пойдет о сотнях тысяч, а иногда и о миллионах договоров. Нагрузочное тестирование позволяет обнаружить потенциальные проблемы такого характера еще на этапе тестирования.

Производительность фронтенда и Core Web Vitals

Если нагрузочное тестирование измеряет, выдержит ли сервер шквал запросов, то производительность фронтенда — это то, насколько быстро и плавно приложение ощущается конкретным пользователем. В последние годы Google сделал эту метрику не просто желательной, а напрямую влияющей на позицию сайта в поисковой выдаче. Тестировщику веб-приложений сегодня важно понимать три ключевых метрики, которые Google объединяет под названием Core Web Vitals:

• LCP (Largest Contentful Paint) — время, за которое отрисовывается крупнейший видимый элемент страницы. Хороший показатель — до 2,5 секунды;
• INP (Interaction to Next Paint) — отзывчивость интерфейса на действия пользователя. Метрика заменила старую FID в марте 2024 года. Хороший показатель — до 200 мс;
• CLS (Cumulative Layout Shift) — насколько «прыгает» верстка при загрузке. Хороший показатель — менее 0,1.

Замерить их можно встроенным в Chrome инструментом Lighthouse (в DevTools), сервисом PageSpeed Insights от Google или более глубоким WebPageTest. Сюда же относятся проверки на «лишние» килобайты JS-бандла, отсутствие lazy loading у тяжелых картинок, корректность работы code splitting в SPA. Тестировщику не обязательно становиться фронтенд-разработчиком, но уметь снять отчет Lighthouse, прочитать его и завести осмысленный баг-репорт «у нас LCP 4,8 секунды на главной» — это сегодня базовый навык.

База данных: «хранить нельзя удалить»

Еще одной ранее рассмотренной составляющей веб-приложений является база данных, в которой приложение хранит всю необходимую информацию. Для того, чтобы база данных служила достойным хранилищем информации для вашего приложения, при тестировании необходимо обращать внимание на следующие основные моменты:
1. Вносимая через интерфейс информация должна быть сохранена в базе данных в неизменном (первоначальном) виде.
2. Сохраненная в базе данных информация должна отображаться в любой части приложения одинаково (если иного не требует бизнес-логика приложения).
3. Названия таблиц и структура БД должны соответствовать проектной документации.
4. Нужно следить за тем, чтобы запросы не обрабатывались слишком долго, а количество соединений было достаточным. Мониторинг состояния БД – один из важных моментов тестирования.
5. Стоит учитывать, что удаление записи в БД не всегда сопровождается полным удалением сущности. Иногда используется так называемое «псевдоудаление» (soft delete), и нужно проверить, правильно ли оно выполняется.
6. Пустую БД на тестовом стенде рекомендуется либо заполнять сгенерированными случайными данными, либо снимать дамп с продакшена и после обфускации данных «заливать» их в тестируемую БД. Здесь важно помнить про требования законодательства о защите персональных данных (152-ФЗ в России, GDPR в ЕС) — реальные пользовательские данные на тестовых стендах без анонимизации использовать категорически нельзя. Иногда квалификация тестировщика (или иная причина) не позволяет выполнить этот процесс самостоятельно: в таком случае рекомендуется обратиться за помощью к специалистам инфраструктуры или разработчикам.
7. Если в проекте используется несколько хранилищ одновременно (например, PostgreSQL как основная БД, Redis как кэш, Elasticsearch для поиска) — обязательно проверьте согласованность данных между ними. Классический баг: пользователь обновил профиль, в PostgreSQL изменение записалось, а в кэше Redis осталось старое значение, и до истечения TTL все видят неактуальные данные.

Запросы: do you speak computish?
Все составляющие веб-приложения должны взаимодействовать между собой, и происходит это благодаря HTTP(s). Без HTTP наша многосторонняя система не функционировала бы в принципе, так как HTTP – это протокол передачи данных, занимающий одно из основных мест в нашей клиент-серверной архитектуре. Стоит упомянуть, что современный веб все чаще работает поверх HTTP/2 и HTTP/3 (QUIC), которые сильно отличаются от классического HTTP/1.1 по транспортному уровню, но логика запросов и ответов с точки зрения тестировщика остается прежней.

Взаимодействие осуществляется через сообщения (запросы и ответы): на отправленный запрос от клиента должен прийти ответ сервера. Классический запрос/ответ состоит из 3 составляющих:

• стартовая строка;
• заголовок;
• тело сообщения.

При работе с ответами специалист по тестированию в первую очередь должен обращать внимание на методы и коды состояния, которые присутствуют в стартовой строке.

Самыми популярными методами являются GET, POST, PUT, PATCH и DELETE — особенно если приложение построено на REST API, что сегодня стало индустриальным стандартом:

1. Метод GET. Используется для запроса содержимого, размещенного на сервере (например, GET /path/resource?param1=value1&param2=value2 HTTP/1.1).
2. Метод HEAD. По своей сути не отличается от вышеупомянутого метода, однако ответ сервера на такой запрос лишен «тела», а практическое применение ориентировано на облегченное использование с целью получения минимальной информации о сервере/продукте или его статусе.
3. Метод POST. Данный метод используется для передачи данных на сервер, однако его основа «прячется» в тело, что отличает его от GET. Во время публикации этой статьи, например весь текст будет помещен в тело POST-запроса; после обработки его сервером на сайт будет добавлена статья.
4. Метод PUT. Используется для полной замены ресурса. Тестировщику важно проверять, что PUT действительно перезаписывает запись целиком, а не дописывает поля.
5. Метод PATCH. Частичное обновление ресурса — изменяются только переданные поля, остальные остаются как были. Частый источник багов: разработчик случайно реализовал PATCH как PUT, и неуказанные поля затираются в null.
6. Метод DELETE. Удаление ресурса. Проверьте, что удаление идемпотентно (повторный DELETE возвращает корректный код), и что нет каскадных эффектов в виде «случайно удаленных» связанных сущностей.

Помимо REST, в современных приложениях все чаще встречается GraphQL — там все запросы идут через единственный endpoint методом POST, и тестирование строится вокруг проверки правильности схемы, разрешений на отдельные поля и защиты от слишком «жадных» запросов (query depth, query complexity). А для real-time коммуникации используются WebSocket и Server-Sent Events — это уже отдельная вселенная, в которой классический Postman помогает не всегда, и в дело идут специализированные инструменты.

То, что составляющие веб-приложения взаимодействуют между собой посредством HTTP, является хорошей новостью для специалиста по тестированию, так как это позволяет не просто отслеживать общение, вникая в логику работы и сверяя ее с техническими требованиями, но и влиять непосредственно на приложение, прикладывая свою руку к отправляемым запросам.

Классическими приложениями, которые можно использовать для отправки и модификации запросов, являются Postman, Insomnia и набирающий популярность open-source инструмент Bruno. Для глубокого анализа трафика и проксирования подходят Charles Proxy, mitmproxy, а также HTTP Toolkit. Большую часть базовых задач отлично закрывают встроенные DevTools в Chrome/Firefox/Edge — вкладка Network позволяет отслеживать все запросы, видеть их детали, повторять с изменениями (Replay XHR / Copy as fetch) и оценивать поведение системы.

На что обращать внимание в запросах?

1. Правильный ли метод используется для того или иного запроса? Если вы отправляете сообщение, а на сервер уходит только GET-запрос, то что-то здесь явно не так.
2. Казалось бы, клик по одной и той же функциональной клавише генерирует один и тот же запрос. Но есть прецеденты, когда клик по кнопке приводил к ситуации, в которой JavaScript переписывал запрос рядом находящейся кнопки, таким образом меняя ее предназначение.
3. Вникайте в отправляемые запросы. В них довольно легко разобраться, особенно если это GET – они логически понятны даже рядовому пользователю. Анализ запросов – это возможность обнаружить спрятавшийся дефект гораздо быстрее, чем осуществляя его поиск в интерфейсе.
4. Мониторьте трафик на предмет запросов на другие (не ваши) сервера. Пример из жизни: фронтэнд сайта делал фриланс-разработчик, по завершению работы которого мы принялись за тестирование. Я имею привычку мониторить весь трафик тестируемого приложения: это позволило обнаружить, что вышеупомянутый разработчик без зазрения совести спрятал в «фронт» сайта запросы, которые работали на благо его личного интернет-магазина.
5. Мониторя трафик, внимательно следите за кодами состояний. Мы подробнее остановимся на этом пункте.

Коды состояния глазами адепта качества
Каждый ответ на любой запрос несет в себе массу полезной для разработчиков и специалистов по тестированию ПО информации. Одним из источников такой информации может стать код состояния: по этому коду клиент узнаёт о результатах его запроса и определяет, какие действия ему предпринять дальше. Набор кодов состояния является стандартом, он описан в соответствующих документах RFC. Каждый раз, когда вы создаете баг-репорт о неработающих ссылках, иных элементах веб-страницы или системных ошибках, обязательно указывайте ответы сервера: они сэкономят время разработчику при определении причин дефекта.

Все коды можно поделить на группы (сотые, двухсотые, трехсотые, четырехсотые и пятисотые) каждая группа-«сотня» несет свой тип информации.

По клику на картинку откроется полная версия.

Более детально с кодами состояния можно ознакомиться на Wikipedia.

На практике, используя при тестировании DevTools браузера или специализированные инструменты, вы без труда сможете отсортировать свои запросы и ответы по коду состояния и отобрать, например, все 400-е и 500-е с последующим их анализом. Таким образом очень быстро «отлавливаются» дефекты с «отвалившимися» стилями, скриптами, файлами, функциями приложения и т.п.

Мобильный веб и PWA: главная боль современного тестировщика

В 2017 году мобильный трафик уже был значимым, но настольный все еще доминировал. К 2026 году ситуация перевернулась: по разным оценкам, более 60% мирового веб-трафика приходится на мобильные устройства, а Google еще в 2019 году перевел индексацию на mobile-first — это значит, что для поисковика «эталонная» версия сайта именно мобильная. Если на мобильном сайт работает плохо, это бьет и по позициям в выдаче, и по конверсии.

Что должен покрыть тестировщик в мобильном контексте:

• отображение на реальных популярных вьюпортах (iPhone, флагманы Samsung, средние Android-устройства). Эмуляторы в DevTools хороши для первичной проверки, но реальные тач-события, поведение клавиатуры и нюансы Safari/Chrome на iOS воспроизводятся только на устройстве;
• работу safe-area (учет «челки» iPhone и «островов» Dynamic Island, чтобы важные элементы интерфейса не уходили под них);
• поведение в режиме горизонтальной и вертикальной ориентации, при сворачивании и возврате в приложение;
• работу тач-жестов: длинное нажатие, свайп, pinch-to-zoom — особенно если приложение использует кастомные обработчики жестов.

Отдельно стоит сказать про Progressive Web Apps (PWA) — это веб-приложения, которые после установки на устройство пользователя ведут себя почти как нативные: запускаются с иконки на рабочем столе, работают в офлайн-режиме, могут присылать push-уведомления. Тестирование PWA добавляет специфические проверки: корректность работы Service Workers (сценарии офлайн, обновление кэша, фоновая синхронизация), валидность Web App Manifest, поведение при установке и удалении, работа push-уведомлений на разных платформах. PWA сильно популярны в e-commerce и медиа, потому что обходят сторы и при этом дают «нативный» пользовательский опыт.

Чем еще отличается веб-приложение от десктопного: больше особенностей – больше проблем!

Многопользовательская сущность веб-приложений
Широта аудитории приложений накладывает свой отпечаток на специфику работы.
1. Одно приложение одновременно может использоваться огромным количеством людей. Мы уже рассматривали вопрос нагрузочного тестирования, но также следует обратить внимание на то, что в число пользователей могут входить представители разных культур, языков и религий. Нам необходимо помнить об этом, особенно если речь идет о тестировании международного приложения.
2. Каждый пользователь может иметь свои уровни доступа. В идеальном варианте тестировщик создает для себя матрицу уровней доступа и тестирует каждый доступ в отдельности.

По клику на картинку откроется полная версия.
3. Пользователи с одним уровнем доступа могут обращаться к одним и тем же сущностям, что приводит к конкурентному доступу. Тестируется это довольно просто. Для примера рассмотрим систему, имеющую дело с договорами, которые можно создавать, публиковать, редактировать, аннулировать. Алгоритм работы таков: под несколькими окнами в режиме инкогнито авторизуемся в приложении под пользователями с разными уровнями доступа; далее выбранную для теста сущность открываем на редактирование, а под второй учетной записью эту же сущность пробуем перевести в статус «Аннулировано» – на этом этапе должен сработать контроль на конкурентный доступ. Операция аннулирования блокируется, а пользователю выдается сообщение о том, что сущность редактируется другим пользователем (поведение и приоритет действий определяются в соответствии с требованиями и особенностями продукта, но логика не меняется).
4. Широта аудитории говорит о том, что за монитором может находиться человек, имеющий злой умысел в отношении вашего ПО.

Сетевые страсти: веб-приложение в разных условиях передачи данных
Веб-приложения активно используют сеть, и это является источником возможных проблем. Таковой, например, является использование приложения в условиях низкой скорости передачи данных (в DevTools всех современных браузеров есть функция Network Throttling, которая позволяет занижать скорость передачи данных и эмулировать сценарии вроде «Slow 3G» или «Offline»), в условиях потери пакетов или при отключении сети во время активной фазы работы приложения (способ имитации: сначала делаем скорость передачи данных с помощью Throttling минимальной, а потом прерываем сетевое соединение во время обработки запроса).

В любом из описанных выше случаев приложение должно работать корректно. При «падении» запроса (time out) или иной проблеме мы должны, перезагрузив страницу, снова получить полностью работающее веб-приложение без какого-либо намека на только что пережитый «урон». Для всех ли функций приложения необходимо подобные тесты? Ни в коем случае! В будущем можете ориентироваться на свой опыт, а на первых этапах в этих вопросах лучше проконсультироваться с разработчиками.

Тестирование безопасности веб-приложения: спаси, сохрани, защити

Тестирование безопасности – отдельное направление тестирования, которое требует от специалиста фундаментальных знаний технического характера и хорошей профильной квалификации. Я отмечу ряд общих моментов, которые могут помочь любому тестировщику находить классические уязвимости, не допуская их выход на продакшен. Вопросы безопасности приложений регламентируются такими стандартами и методиками, как OWASP, NIST Cybersecurity Framework, рекомендациями ISACA и методологией OSSTMM.

Существует ряд принципов безопасности, к которым относятся конфиденциальность, целостность и доступность:
1) Конфиденциальность – ограничение доступа к той или иной информации для определенной категории пользователей (или наоборот предоставление доступа только ограниченной категории).
2) Целостность включает в себя:
а) возможность восстановить данные в полном объеме при их повреждении;
б) доступ на изменение информации только определенной категории пользователей.
3) Доступность – иерархия уровней доступа и четкое их соблюдение.

Ориентиром по самым актуальным уязвимостям сегодня служит OWASP Top 10 — список обновляется примерно раз в 3-4 года, и в текущей редакции на первое место вышел Broken Access Control. Перечислим классические уязвимости современных веб-приложений:
1. Broken Access Control — некорректная проверка прав доступа: пользователь может посмотреть или изменить чужие данные, просто подставив в URL чужой ID или вызвав «административный» эндпоинт напрямую;
2. XSS — генерация на странице продукта скриптов, представляющих опасность для пользователей продукта;
3. CSRF (ранее упоминался как XSRF) — уязвимость, при которой действия пользователя выполняются на доверенном сайте без его ведома, по ссылке с вредоносной страницы;
4. Code injection (SQL, NoSQL, OS Command) — инъекция исполняемого кода, которая делает возможным несанкционированный доступ к программному коду или базе данных и изменение их содержимого;
5. Authorization bypass — вид уязвимости, при котором можно получить несанкционированный доступ к учетной записи или документам другого пользователя;
6. SSRF (Server-Side Request Forgery) — заставляем сервер делать запросы туда, куда он не должен (например, во внутреннюю сеть);
7. Cryptographic Failures — неправильное хранение паролей (без соли, в открытом виде), использование устаревших алгоритмов шифрования, утечка чувствительных данных через логи;
8. Переполнение буфера — явление, которого можно достичь во вредоносных целях, по своей сути представляет использование места для записи данных далеко за пределами выделенного буфера памяти.

При тестировании рекомендую опираться на актуальные чит-листы безопасности от OWASP (OWASP Cheat Sheet Series), которые регулярно обновляются сообществом и закрывают большинство практических сценариев — от защиты от XSS до правильной работы с JWT-токенами.

Практические советы: еще раз о насущном

Начинаем тестировать не с тестирования: с чего начать?
Я хочу акцентировать ваше внимание на необходимости согласовать все ключевые аспекты с ответственными лицами (аналитиками, проектными менеджерами, разработчиками) еще до начала тестирования. Необходимо заранее выяснить следующие моменты:

• цель тестирования (с их точки зрения);
• виды тестирования, которые необходимо провести;
• специфику приложения и его целевую аудиторию;
• перечень устройств, на которых необходимо проводить тестирование;
• список ОС и браузеров для тестирования;
• разрешения экранов на которых необходимо проверить приложение;
• предусмотрены ли требования к разного рода формам, есть ли стайл-гайд, актуальное ЧТЗ;
• необходимость предоставления конкретной документации по результатам тестирования (отчет, чек-листы, тест-кейсы и т. д.).

Получив ответы на эти вопросы, о которых часто забывают новички, вы сэкономите свое время. Дальше переходите к непосредственной подготовке окружения и формированию стратегии тестирования.

Некогда думать, нужно тестировать!

Любое тестирование требует содержательного подхода с применением техник тест-анализа и тест-дизайна. В противном случае вы рискуете навсегда остаться «monkey-тестером», ценность труда которого будет мизерна. В целом, ключевые положения тест-анализа и тест-дизайна применимы как к тестированию десктоп-приложений, так и к веб-у, но с существенной оговоркой: вы должны учитывать все упомянутые в статье нюансы. Отдельно хочу акцентировать внимание на том, что без стойкого понимания методик и способов применения тест-анализа и тест-дизайна тестировать качественно ПО практически невозможно.

Рассмотрим классический набор методик тест-дизайна, которые можно применять при тестировании веб-приложений:

• разбиение на классы эквивалентности;
• попарное тестирование;
• тестирование переходов состояний;
• анализ граничных значений;
• тестирование с помощью таблиц решений;
• методика тест-туров Виттакера и множество других.

Подай ключ «на 13»
В настоящее время существует огромное множество разнообразных инструментов, которые упрощают жизнь всем участникам разработки нового ПО. Следовательно, не стоит забывать о том, что помимо развития личных качеств, технических знаний и навыков, мы должны уметь хорошо пользоваться вспомогательными инструментами, каждый раз испытывая все новые и новые.

Отмечу лишь некоторые из них (актуальный набор на 2026 год):

• Браузерные DevTools (F12 в Chrome, Edge, Firefox, Safari) — швейцарский нож тестировщика веб-приложений: режим эмуляции устройств, профилирование производительности, перехват и модификация сетевых запросов, отладка JavaScript, аудит доступности.
• Postman, Insomnia, Bruno — инструменты для работы с API: ручные запросы, коллекции, автоматизированные сценарии, переменные окружения.
• Charles Proxy, mitmproxy, HTTP Toolkit — снифферы и прокси для глубокого анализа сетевого трафика, включая мобильный.
• BrowserStack, LambdaTest, Sauce Labs — облачные платформы для кроссбраузерного и мобильного тестирования на реальных устройствах.
• Lighthouse, PageSpeed Insights, WebPageTest — аудит производительности, SEO, доступности и Core Web Vitals.
• axe DevTools, WAVE — автоматизированные проверки доступности (a11y).
• JMeter, k6, Gatling, Locust — нагрузочное тестирование.
• Selenium, Playwright, Cypress — фреймворки для автоматизации UI-тестов. Playwright за последние годы стал де-факто стандартом для новых проектов благодаря поддержке всех браузеров «из коробки» и удобному API.
• OWASP ZAP, Burp Suite Community, Nuclei — сканеры безопасности веб-приложений.
• Screaming Frog SEO Spider — десктоп-краулер, удобен для поиска «битых» ссылок, аудита внутренней перелинковки и формирования карты сайта.

Отдельно стоит упомянуть появившийся за последние годы класс инструментов на базе ИИ: автогенерация тест-кейсов по требованиям, визуальная регрессия с машинным обучением, «самовосстанавливающиеся» локаторы в UI-автотестах. Это не серебряная пуля и не замена инженеру, но как помощник в рутине — уже вполне рабочая история, к которой стоит присмотреться.

Выводы и напутствия

Подводя итоги, я хочу еще раз акцентировать внимание читателя на том, что «веб» развивался, развивается и будет развиваться, а количество используемых технологий, как и разнообразие дефектов, – увеличиваться. За девять лет, прошедших с момента первой публикации этой статьи, мы пережили смерть Internet Explorer, рождение и взросление PWA, превращение мобильного трафика в доминирующий, появление Core Web Vitals как фактора ранжирования, бурный рост ИИ-инструментов в инженерной практике — и веб-приложения никуда не делись, наоборот, стали еще более вездесущими. Знание основ и понимание сути веб-приложений поистине бесценно. Любой тестировщик рано или поздно прикоснется к «веб-у» своей профессиональной «разрушительной» рукой, но только хороший специалист получит из этого максимально приближенный к требуемому результату.

Важно помнить, что тестирование ПО ставит перед каждым вступившим в стройные ряды сферы обеспечения качества ПО такие задачи, которые практически невозможно решать однозначно и по четкому алгоритму. Тестирование – это философия, творчество, полет мысли, основанный на четких и безоговорочных технических аспектах. Пожалуй, только тестировщикам приходится одновременно быть разработчиком, системным аналитиком, пользователем, заказчиком (для которого первоочередной интерес – финансовый или иной успех продукта), специалистом в предметной области и даже DBA.

Каждый из этих навыков QA Engineer должен развивать постоянно, и тогда он сможет избежать многих возможных проблем и остаться востребованным высококвалифицированным профессионалом. Остановка в развитии для специалиста из сферы обеспечения качества фактически приравнивается к профессиональной смерти (как минимум, «клинической» в том случае, если стремление к новым знаниям со временем возвращается).

Движение – это жизнь. Всем добра!