Тестирование сайтов — это проверка того, что веб-приложение работает по требованиям, корректно отвечает на действия пользователей и сохраняет данные. QA расшифровывается как Quality Assurance, или обеспечение качества: оно охватывает процессы, которые помогают предотвращать дефекты и снижать риски. Тестирование веб-приложений выполняют вручную и с помощью автоматизации, а тестировщик документирует результаты и помогает команде принимать решения о релизе.
Зачем проверять сайт до публикации
Дефект — это недостаток в продукте или документации, который может привести к сбою при выполнении. Ошибка — человеческое действие, которое приводит к неправильному результату, сбой — наблюдаемое неправильное поведение системы. Эти понятия связаны, но обозначают разные этапы причины и проявления проблемы.
Иногда используют эвристическую модель 1–10–100, чтобы показать возможный рост затрат на исправление проблемы по мере её продвижения к пользователям. Условная единица на этапе требований, десять — во время разработки, сто — после выхода в продакшен. Это наглядная модель затрат. В проде к исправлению добавляются диагностика, срочный выпуск, поддержка клиентов и возможные потери выручки.
Например, если корзина интернет-магазина не сохраняет товар, при обсуждении требований это можно выявить вопросом о правилах хранения корзины. На этапе разработки проблему найдёт проверка API или интерфейса. После релиза покупатели могут не завершить заказ, а команда будет разбирать логи, восстанавливать сценарий и выпускать исправление в условиях работающего сервиса.
Какие виды тестирования нужны сайту
Проверки выбирают по рискам продукта. Для магазина важны оформление заказа и расчёт цены, для сервиса с личными данными — контроль доступа и конфиденциальность, для медиа-платформы — стабильная загрузка контента.
- Функциональное тестирование (functional testing) проверяет функции по требованиям: регистрацию, поиск, оплату, восстановление пароля.
- Регрессионное тестирование (regression testing) проверяет, что изменения не нарушили уже работавшие функции.
- Smoke-тестирование (smoke testing) — короткий набор проверок, который помогает понять, пригодна ли сборка для дальнейшего тестирования.
- UI/UX-тестирование оценивает отображение и удобство взаимодействия: читаемость, понятность ошибок, доступность основных элементов.
- Кроссбраузерное тестирование (cross-browser testing) сравнивает поведение сайта в разных браузерах. Мобильное тестирование проверяет адаптивную верстку, сенсорное управление и сценарии на телефонах.
- Нагрузочное тестирование (load testing) оценивает производительность при заданном числе пользователей и запросов.
Один сценарий можно проверять разными способами. Например, оформление заказа вручную подтверждает понятность шагов, API-проверка валидирует ответ сервера, а нагрузочная проверка показывает, выдерживает ли оформление ожидаемый поток запросов.
Как устроены окружения Dev, Stage и Prod
Окружение (environment) — это отдельная конфигурация приложения и зависимостей, на которой выполняются разработка, проверка или эксплуатация. Обычно команда использует Dev для разработки, Stage (Pre-prod) для проверки сборки перед выпуском и Prod (production) для реальных пользователей. Stage должен по возможности повторять настройки и интеграции продакшена, при этом тестовые данные и доступы следует отделять от настоящих.
На локальной машине разработчика могут отличаться версии браузера, базы данных, переменные окружения, сетевые правила и содержимое кэша. Поэтому фраза «у меня всё работает» подтверждает поведение только в конкретной конфигурации. Проверка на Stage помогает выявить несовпадения до публикации, хотя сама по себе не гарантирует полного совпадения со всеми условиями прода.
Как подготовить тесты и описать дефект
Чек-лист — это список условий или действий для проверки без подробного сценария выполнения. Он удобен, когда специалист знает продукт и может пройти проверки гибко. Тест-кейс (test case) описывает предусловия, шаги, данные и ожидаемый результат, поэтому его проще повторить другому человеку или автоматизировать.
Баг-репорт (bug report) должен помогать воспроизвести и диагностировать дефект. Вместо заголовка «Не работает кнопка» укажите: «После нажатия “Оплатить” запрос POST /orders завершается ответом 500, заказ не создаётся». Если запрос не отправляется: «После нажатия “Оплатить” запрос POST /orders не появляется во вкладке Network; заказ не создаётся».
| Поле | Что указать | Чего избегать |
| Summary | «Корзина очищается после обновления страницы в Safari на iPhone» | «Сайт сломан» |
| Steps to reproduce | Точные шаги: добавить товар, открыть корзину, обновить страницу | «Зайти и проверить» |
| Actual result | Что произошло: корзина отображается пустой | Предположений о причине |
| Expected result | Что должно произойти согласно требованиям | Неясного «должно работать» |
| Environment | Сборка, браузер и версия, ОС, устройство | «Мой телефон» |
| Logs/Screenshots | Скриншот, сетевой запрос или сообщение ошибки | Изображения без пояснения |
Плохой пример: «Не работает оплата». Непонятно, где возникает сбой, какие данные использовались и повторяется ли проблема.
Хороший пример: «Оплата картой не создаёт заказ на Stage, Chrome 130, Windows 11. Войти тестовым покупателем, добавить товар за 1 200 ₽, перейти в корзину и нажать “Оплатить”. Фактически заказ не появляется, в Network запрос POST /orders завершается с 500. Ожидается создание заказа и экран подтверждения. Скриншот и время запроса приложены».
Жизненный цикл бага
Статусы зависят от настроек трекера задач, например Jira, но типичный путь дефекта выглядит так:
- New — дефект зарегистрирован и ожидает оценки.
- In Progress — разработчик взял задачу в работу.
- Fixed — исправление готово и доступно в сборке для проверки.
- Verified — тестировщик подтвердил исправление на нужном окружении.
- Closed — работа завершена, дефект закрыт.
- Reopened — проблема воспроизводится после исправления; задача возвращается в работу.
Закрывать дефект стоит после проверки на сборке с исправлением и повторного выполнения затронутого сценария. Если проверка прошла только на локальной машине, а релиз собирается иначе, результат не подтверждает поведение целевой сборки.
Курс «Тестировщик ПО (QA-инженер)» в Академии IT DMS
Сертификат или удостоверение о повышении квалификации.
AFFTIMES−5 % на первую покупку. Скидка суммируется с любыми акциями школы. Если оплачиваете через менеджера в чате, назовите ему промокод.
Ручные проверки и автоматизация
Ручное тестирование подходит для исследовательских проверок, нового интерфейса и сценариев, где важно оценить понятность. Автоматизация тестирования полезна для повторяющихся проверок: например, для критичного сценария входа или оформления заказа, который запускают при каждом изменении. Автотест нужно поддерживать, иначе он может давать ложные сбои и отнимать время команды.
| Критерий | Ручное тестирование | Автоматизированное тестирование |
| Лучше подходит для | Исследования, нового интерфейса, разовых проверок | Частых повторов, регрессии, больших наборов данных |
| Сильная сторона | Специалист замечает неожиданные детали и оценивает удобство | Быстро повторяет заданные проверки и фиксирует результат |
| Ограничение | Повторение занимает время, возможны пропуски | Требует разработки, обслуживания и стабильных тестовых данных |
| Пример | Проверить понятность формы регистрации | Проверять создание заказа при каждом выпуске |
Пирамида тестирования — модель, в которой основу составляют многочисленные быстрые проверки нижних уровней, а более медленных интеграционных и сквозных проверок меньше. Сквозные тесты могут выполняться как через UI, так и через API. Практический смысл в том, чтобы находить ошибки на подходящем уровне: неверный расчёт скидки проще диагностировать тестом функции, чем длинным сценарием в браузере.
Playwright, Cypress и Selenium применяют для браузерной автоматизации; выбор зависит от стека команды, браузеров и доступных возможностей. Playwright поддерживает Chromium, Firefox и WebKit. Для системного подхода команде нужны общие правила, обучение и время на поддержку тестов.
Профильные курсы для QA могут быть частью развития компетенций.
Почему проверки API дополняют UI-тесты
Интерфейс показывает только часть поведения приложения. Проверки через API помогают отдельно проверить валидацию данных, права доступа, обработку ошибок и формат ответа.
HTTP-статус-коды описывают результат запроса, но сами по себе не подтверждают правильность бизнес-логики:
- 200 OK — запрос успешно обработан.
- 201 Created — запрос привёл к созданию ресурса.
- 400 Bad Request — сервер не обрабатывает запрос, поскольку считает его некорректным, например из-за ошибочного синтаксиса или неверного формата.
- 401 Unauthorized — запрос не выполнен из-за отсутствующих или недействительных данных аутентификации.
- 404 Not Found — сервер не нашёл целевой ресурс либо не сообщает о его существовании.
- 500 Internal Server Error — сервер столкнулся с неожиданной ситуацией, из-за которой не смог выполнить запрос.
Если интерфейс показывает подтверждение оплаты, а API возвращает ошибку или не создаёт заказ, успешный вид страницы недостаточен. Сверяйте код ответа, тело запроса, ответ сервера и фактическое состояние заказа.
Как проверять браузеры, телефоны и страницу сайта
DevTools браузера помогают быстро локализовать проблему. Network показывает запросы, ответы, время загрузки и переданные данные. Console выводит сообщения JavaScript и ошибки. Elements позволяет исследовать DOM и стили элемента, например выяснить, почему кнопка перекрыта другим блоком.
Эмуляция мобильного устройства в DevTools полезна для быстрой проверки ширины экрана и адаптивной верстки, но не полностью воспроизводит поведение реального телефона. На устройстве могут отличаться жесты, клавиатура, производительность и браузерный движок. Для расширения набора конфигураций применяют устройства и сервисы вроде BrowserStack.
Сайт может корректно отображаться в Chrome на компьютере, но ломать меню или ввод в iOS Safari. Причина часто проявляется только при реальном сенсорном управлении или особенностях мобильного браузера. Поэтому сочетайте эмуляцию с проверкой на реальных устройствах.
Базовые проверки безопасности сайта
Проверяйте, что пользователь видит только свои данные и не может получить доступ к чужим заказам, изменив идентификатор в запросе. Для форм проверьте обработку недоверенного ввода: XSS может внедрить сценарий, который выполнится в браузере, а SQL-инъекция — повлиять на запросы к базе данных. Клиентская валидация помогает сразу показать ошибку, но её можно обойти, поэтому сервер обязан самостоятельно проверять входные данные и права доступа.
В базовую проверку также входят сценарии входа и выхода, сброса пароля, истечения сессии и ограничения доступа к закрытым страницам. Ошибки не должны раскрывать пароли, токены, персональные данные или подробности внутренней реализации. Для системной оценки рисков команда может использовать категории OWASP Top 10 и согласовать с разработчиками дополнительные проверки для конкретного приложения.
QA в Agile и Scrum
Shift-left тестирование означает раннее включение проверок в процесс разработки. QA-инженер участвует в груминге задач, уточняет критерии приёмки, задаёт вопросы о граничных случаях и помогает выявить неоднозначности до начала реализации. Это снижает вероятность того, что команда обнаружит пропущенное требование после релиза.
Команде полезно определить минимальный набор проверок перед выпуском: например, smoke-набор, критичные API-сценарии, регрессию ключевых пользовательских путей и ручную проверку изменений интерфейса. Тестовое покрытие показывает, какие части системы проверены, но высокий процент покрытия сам по себе не подтверждает качество сценариев. Проверки должны соответствовать рискам, а результаты быть понятными команде.
FAQ
Да, разработчик проверяет свою реализацию модульными и интеграционными тестами, а также вручную. Независимая проверка полезна для новых сценариев и другого взгляда на требования: автор кода может не заметить собственное предположение о поведении системы.
Нет универсальной цели, подходящей каждому проекту. Покрытие кода измеряет, какие участки выполнялись во время тестов, но не показывает, насколько правильно проверены требования и важные пользовательские риски.
Проверьте изменённую функцию, связанные сценарии, критичный smoke-набор и ошибки в логах. Объём регрессии выбирают по влиянию изменения и связям компонентов.
Решение зависит от влияния на пользователей, наличия обходного пути и бизнес-риска. Команда должна зафиксировать последствия и ответственных за решение, особенно если дефект затрагивает оплату, доступ или данные.
Когда сценарий регулярно повторяют, его результат важен, а поведение достаточно стабильно для автоматизации. Редкую разовую проверку часто быстрее выполнить вручную.
Набор конфигураций выбирают по аудитории, аналитике и риску изменений. Обычно начинают с браузеров и устройств, которыми чаще пользуются клиенты, затем проверяют дополнительные сочетания для критичных функций.
