Виды тестирования: руководство для начинающих

Тестирование программного обеспечения (ПО) — это проверка продукта на соответствие требованиям и поиск ошибок до того, как с ними столкнётся пользователь. В терминологии QA (от английского quality assurance — «обеспечение качества») продукт — это сайт, мобильное приложение, игра, корпоративная система или любой другой цифровой сервис.

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

QA-инженер (quality assurance engineer — «инженер по обеспечению качества», или инженер по тестированию) опирается на эти требования и проверяет, выполняются ли они в реальности. Он влияет на качество продукта на всех этапах разработки: от анализа требований до релиза и поддержки, — поэтому классификация видов тестирования и логика процесса — его зона ответственности.

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

По данным TAdviser, в российский QA сейчас активно приходят low-code и no-code решения, ИИ применяется для генерации тест-кейсов и анализа результатов прогонов. База при этом не меняется: чтобы пользоваться продвинутыми инструментами, важно понимать классификацию тестирования и логику процесса.

Процесс тестирования в команде разбит на этапы: это помогает не пропустить важное и работать предсказуемо.

Всё начинается до того, как написана первая строчка кода. Бизнес или заказчик описывает задачу, аналитик переводит её в технические требования, дизайнер готовит макеты. QA-инженер подключается, чтобы задать неудобные вопросы: что должно произойти, если поле оставят пустым, как система поведёт себя при ошибке сети, какие лимиты на количество символов.

Вовлечение QA на этом шаге называется shift-left — сдвиг тестирования влево, ближе к началу разработки. Чем раньше найдена ошибка в требованиях, тем дешевле её исправить. Согласно QaRocks, shift-left уже стал нормой в зрелых командах.

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

В небольших проектах эти документы могут быть короткими, на одну страницу. В крупных — объёмными, с описанием инфраструктуры, тестовых сред и ролей в команде.

Дальше QA-инженер пишет тест-кейсы и чек-листы — конкретные сценарии проверок с шагами и ожидаемым результатом:

Эти документы помогают не упустить важные проверки и передавать знания между членами команды.

Когда готова сборка продукта, начинается сама проверка. QA-инженер проходит по тест-кейсам, заводит баг-репорты на найденные дефекты, разработчик их исправляет, инженер по тестированию перепроверяет. Цикл повторяется, пока продукт не достигнет нужного качества.

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

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

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

Дальше разберём основные оси классификации. Это та база, которую обычно спрашивают на собеседовании на позицию джуна и которую полезно держать в голове при работе с тест-планом.

Самая распространённая ось. Делит проверки по тому, что именно мы тестируем: саму логику работы продукта или его свойства — скорость, устойчивость, безопасность.

Функциональное тестирование проверяет базовую работоспособность продукта. Кнопка «Купить» добавляет товар в корзину, форма авторизации пускает пользователя по верному паролю, фильтр в каталоге убирает лишние товары. Это самая объёмная часть работы QA-инженера — большинство тест-кейсов в команде относятся именно к функциональным.

Функциональные тесты структурно делятся на четыре уровня: от самых маленьких блоков кода до проверки готового продукта целиком.

Юнит-тесты (unit testing) проверяют отдельные функции и классы в коде — мельчайшие модули, из которых собран продукт. Пишут их обычно сами разработчики. Цель — убедиться, что каждый блок кода работает корректно изолированно от остальной системы.

Например, есть функция, которая считает скидку: подаём ей на вход цену и процент скидки, проверяем, что результат корректный. Если изменилась логика расчёта — тест сразу подсветит проблему.

Юнит-тесты быстрые, дешёвые и обычно автоматизированные.

Когда модули собраны, важно проверить, что они корректно взаимодействуют. Интеграционное тестирование смотрит на стыки: правильно ли модуль «А» передаёт данные в модуль «Б», корректно ли работают вызовы внешних API, не теряются ли данные при передаче через очередь сообщений.

Простой пример: модуль регистрации создаёт пользователя, а модуль писем отправляет ему приветственное сообщение. Интеграционный тест проверит, что после регистрации пользователь действительно получит письмо. Юнит-тесты этого не покажут — каждый модуль изолированно работает корректно, но связь между ними может оказаться сломанной.

Системное или сквозное (end-to-end, E2E) тестирование проверяет продукт целиком — так, как с ним будет работать пользователь. QA-инженер проходит сквозные сценарии: зайти на сайт, зарегистрироваться, добавить товар в корзину, оплатить, получить чек на почту. Все модули работают вместе, как в продакшене.

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

Приёмочное тестирование (user acceptance testing, UAT) — финальная проверка перед сдачей продукта или релизом. Здесь проверяют, что продукт соответствует исходным требованиям бизнеса и готов к выпуску. Часто его проводят представители бизнеса или реальные пользователи на специально подготовленной среде.

Если приёмочные тесты пройдены, продукт считается готовым к релизу. Если нет — возвращается на доработку. Этот же вид тестирования встречается в классификации по времени проведения, и об этом ниже.

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

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

Стресс-тест — это нагрузочный тест с ещё более жёсткими условиями. Цель — найти точку, в которой продукт ломается, и понять, как именно он ломается. Корректно ли отдаёт ошибку, восстанавливается ли после спада нагрузки, не теряются ли данные.

В отличие от нагрузочного, стресс-тестирование сознательно превышает проектные мощности. Это полезно для понимания запаса прочности и поведения системы в нештатных ситуациях — таких как DDoS-атака или распродажа в чёрную пятницу.

Тестирование на отказоустойчивость (failover testing) проверяет, как продукт ведёт себя, когда что-то ломается. Здесь команда специально создаёт сбои в инфраструктуре — выключает сервер, обрывает сеть, заполняет диск. Так проверяется, продолжит ли система работать в деградированном режиме и как быстро восстановится после восстановления окружения. Эти проверки особенно важны для финтеха и банков, где простой системы стоит реальных денег.

Один и тот же сайт может корректно открываться в одном браузере и ломаться в другом. Тестирование совместимости (compatibility testing) проверяет, как продукт ведёт себя на разных платформах: операционных системах, браузерах, версиях мобильных устройств и экранах с разной диагональю. Это особенно важно для веб-сервисов и мобильных приложений.

Тестирование безопасности проверяет, защищён ли продукт от атак и утечек данных. Подвид — penetration testing, или пентест: специалисты симулируют действия злоумышленника, чтобы найти уязвимости до того, как их найдут хакеры.

Сюда же относится проверка по списку OWASP Top 10 — стандартному перечню распространённых уязвимостей веб-приложений: SQL-инъекции, XSS, неправильная аутентификация. Этим занимаются отдельные инженеры по безопасности, но базовое понимание полезно любому QA-специалисту.

UI-тестирование, или тестирование интерфейса, проверяет визуальную часть продукта: вёрстку, шрифты, отступы, поведение элементов на разных разрешениях экрана. Сюда же относится юзабилити-тестирование — проверка удобства использования, обычно с участием реальных пользователей.

Тестирование на восстановление (recovery testing) проверяет, как продукт ведёт себя после нештатных ситуаций: внезапное отключение питания, обрыв сети, аварийное закрытие. Хороший продукт должен корректно восстановить состояние и не потерять данные пользователя. Это важно для систем с длинными транзакциями: банковские операции, электронные документы, длительные расчёты.

Один из самых востребованных вопросов на собеседовании джуна — разница между ручным и автоматизированным тестированием.

Ручное тестирование (manual testing) — это когда QA-инженер руками проходит сценарии в продукте: кликает по кнопкам, вводит данные, проверяет результат. Так чаще всего проверяют новые функции, которые ещё не стабилизировались, поисковые тесты на исследование продукта (exploratory testing), пользовательские сценарии в мобильных приложениях.

Большинство джунов начинают карьеру именно с ручного тестирования. Это тот самый низкий порог входа, который делает профессию доступной для смены карьеры. По статистике hh.ru, джуниор QA в среднем получает 80−153 тыс. ₽, мидл — 165−230 тыс. ₽, сеньор — 208−330 тыс. ₽ в месяц.

Автоматизированное тестирование (automated testing, AQA) — когда проверки запускает не человек, а скрипт. QA-инженер пишет код, который имитирует действия пользователя: открывает страницу, заполняет форму, нажимает кнопку и проверяет результат. Основные инструменты — Selenium и Playwright для веб-интерфейсов, REST-assured и Postman для API, Appium для мобильных.

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

Без опыта в коде логично заходить через ручное тестирование, осваивать продукт и инструменты, а через год-два переходить в автоматизацию. По данным Dream Job на 2026 год, средняя зарплата инженера по автоматизации тестирования в России составляет около 215 тыс. ₽. По статистике Хабр Карьеры, у сеньор-уровня средняя зарплата поднимается уже до 309 тыс. ₽.

Эта классификация описывает, насколько глубоко QA-инженер знаком с внутренним устройством продукта.

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

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

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

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

Серый ящик — это что-то среднее. QA-инженер частично знает внутреннее устройство: например, видит структуру базы данных или знает API, но не работает напрямую с кодом. Это позволяет писать более точные сценарии и быстрее находить причины багов. На практике большинство опытных инженеров по тестированию работают именно в режиме серого ящика.

Эта классификация смотрит на тестирование с точки зрения этапа разработки и аудитории, которая в нём участвует.

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

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

Этот формат особенно популярен в играх и мобильных приложениях. Steam Early Access и закрытые беты в App Store и Google Play — классические примеры.

Дымовое тестирование (smoke testing) — быстрая проверка ключевых сценариев на новой сборке. Цель — убедиться, что продукт в принципе запускается и базовые функции работают, прежде чем тратить время на детальное тестирование. 

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

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

Регрессию часто автоматизируют — именно потому, что её нужно прогонять снова и снова при каждом изменении.

Приёмочное тестирование во временной классификации — это финальная проверка готового продукта перед релизом. Часто его делают представители заказчика или продуктовой команды по заранее согласованным сценариям. Результат — решение «принимаем» или «возвращаем на доработку».

В QA различают позитивные и негативные проверки. Хороший инженер по тестированию умеет придумывать и те и другие.

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

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

На собеседованиях часто просят придумать негативные кейсы для какого-то простого функционала — например, для формы регистрации. Это проверка системного мышления.

Последняя ось — нужно ли запускать продукт, чтобы провести проверку.

Статическое тестирование проводится без запуска кода. Оно включает ревью технических документов и требований, работы линтеров (инструментов автоматической проверки кода на ошибки) и статических анализаторов кода (SonarQube, ESLint). Это самый дешёвый способ найти ошибку — её можно поймать ещё на этапе документа, до того как разработчик потратит время на реализацию.

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

Стандартный сценарий выглядит так. Аналитик собирает требования, QA-инженер их анализирует и пишет тест-план с тест-кейсами. Разработчики пишут код и юнит-тесты. Когда новая функция готова, она попадает в тестовую среду — отдельную копию продукта, где можно безопасно ломать всё что угодно. Там QA прогоняет функциональные проверки, проверяет интеграции, ищет ошибки на стыках с уже существующими функциями.

Найденные баги фиксирует в системе вроде Jira или YouTrack: что нашёл, как воспроизводится, какой ожидаемый и фактический результат. Перед релизом запускается регрессионное тестирование — обычно автоматизированное. Параллельно команда нагрузочного и тестирования безопасности проверяет, что продукт выдерживает нагрузку и защищён от типовых атак. Если всё чисто, продукт уходит в продакшен. 

Важная часть процесса — общение. Коммуникативные навыки в QA не менее важны, чем технические. В вакансиях всё чаще встречаются требования по коммуникабельности и инициативности — нужно не только находить дефекты, но и объяснять их влияние на бизнес-процессы.

В современных командах процесс часто организован по модели shift-left: QA-инженер подключается к задаче с первых дней, а не приходит на готовый код. Это снижает стоимость ошибок и повышает качество финального продукта. 2026 год меняет правила игры: рынок делает ставку на качество ИИ-продуктов, тестирование смещается в сторону самих моделей, а оценка их эффективности строится на реальных пользовательских сценариях — не гипотезах.

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