Когда человек только заходит в тестирование, он быстро сталкивается с кучей терминов:
Модульное тестирование, Интеграционное, Системное, Приёмочное.
И сначала кажется, что это просто набор умных слов, которыми любят усложнять жизнь новичкам.
Но на самом деле всё довольно логично.
Эта классификация отвечает на один простой вопрос:
Насколько крупную часть приложения мы проверяем?
То есть мы можем тестировать маленький кусочек кода, связь между несколькими частями, всё приложение целиком или уже готовый продукт с точки зрения бизнеса и пользователя.
Давайте разберём спокойно и по порядку.
Что значит “по уровню детализации приложения”
Представьте, что приложение — это не один цельный монолит, а большой механизм.
Внутри него есть:
- отдельные функции;
- модули;
- базы данных;
- API;
- интерфейс;
- внешние сервисы;
- бизнес-правила;
- пользовательские сценарии.
Например, у нас есть сервис для записи к врачу.
Пользователь открывает приложение, выбирает специалиста, смотрит свободное время, записывается на приём и получает уведомление.
Для пользователя это выглядит как один простой сценарий:
“Я записался к врачу”.
Но внутри системы в этот момент происходит много всего:
- приложение проверяет пользователя;
- загружает список врачей;
- получает свободные слоты;
- создаёт запись;
- сохраняет её в базе;
- отправляет уведомление;
- показывает пользователю подтверждение.
И вот тестирование по уровню детализации как раз помогает понять, на каком уровне мы сейчас проверяем систему.
1. Модульное тестирование
Модульное тестирование ещё называют unit testing.
Это самый низкий уровень проверки.
Здесь тестируется не всё приложение, а маленькая отдельная часть: функция, метод, класс или модуль.
Например, в сервисе записи к врачу есть функция, которая проверяет, можно ли записаться на выбранное время.
Условно:
- если время свободно — запись разрешена;
- если слот уже занят — запись запрещена;
- если врач не принимает в этот день — запись запрещена;
- если пользователь пытается записаться на прошедшую дату — запись запрещена.
Модульный тест проверяет именно эту маленькую логику.
- Не весь сайт.
- Не весь личный кабинет.
- Не экран записи целиком.
- А конкретную функцию:
Правильно ли она принимает решение?
Кто обычно пишет модульные тесты
Чаще всего модульные тесты пишут разработчики.
Это нормально.
Junior-тестировщик не обязан уметь писать unit-тесты на старте, особенно если он идёт в manual QA. Но понимать, что это такое, всё равно полезно.
Почему?
Потому что модульные тесты помогают ловить ошибки очень рано, ещё до того, как функциональность попадёт к тестировщику на стенд.
Простой пример
Есть функция расчёта стоимости подписки в образовательном сервисе.
Пользователь может купить курс:
- на 1 месяц;
- на 3 месяца;
- на 12 месяцев;
- с промокодом;
- без промокода.
Модульные тесты могут проверить:
- правильно ли применяется скидка;
- не уходит ли цена в минус;
- правильно ли считается итоговая сумма;
- что будет, если промокод просрочен.
То есть модульное тестирование проверяет маленькие детали внутри системы.
2. Интеграционное тестирование
Интеграционное тестирование проверяет, как разные части системы работают вместе.
Если модульное тестирование спрашивает:
“Правильно ли работает отдельный кусочек?”
То интеграционное тестирование спрашивает:
“Правильно ли эти кусочки взаимодействуют друг с другом?”
Потому что в реальных приложениях баги часто появляются не внутри одного модуля, а на стыке нескольких частей.
Один модуль данные отправил.
Второй модуль их не так понял.
Третий модуль сохранил не туда.
А пользователь в итоге видит ошибку.
Пример
Возьмём приложение для корпоративного таск-трекера.
Пользователь создаёт задачу и назначает её на коллегу.
Внутри системы могут участвовать разные части:
- интерфейс создания задачи;
- backend, который принимает данные;
- база данных, где задача сохраняется;
- сервис уведомлений;
- модуль прав доступа.
Интеграционное тестирование проверяет, что всё это нормально связано.
Например:
- задача создалась через интерфейс;
- данные ушли на сервер;
- задача сохранилась в базе;
- назначенный сотрудник получил уведомление;
- пользователь без прав не может изменить чужую задачу.
На этом уровне нас интересует уже не одна функция, а связь между компонентами.
Где часто встречаются интеграционные баги
Интеграционные ошибки часто появляются, когда:
- frontend и backend по-разному понимают формат данных;
- API возвращает не то поле или не в том формате;
- один сервис обновили, а другой не адаптировали;
- данные сохраняются, но потом неправильно отображаются;
- уведомление должно отправиться, но не уходит.
Например, backend ждёт дату в формате:
- 2026-05-10
А frontend отправляет:
- 10.05.2026
Вроде бы дата одна и та же.
Но для системы это могут быть разные форматы. В итоге запись не создаётся или создаётся с ошибкой.
Вот это типичная история для интеграционного тестирования.
3. Системное тестирование
Системное тестирование — это проверка всего приложения целиком.
Здесь мы уже не смотрим на отдельную функцию или связь двух модулей. Мы проверяем систему как готовый продукт.
То есть приложение развёрнуто на тестовом стенде, основные части подключены, и QA проверяет, как всё работает вместе.
Пример
Допустим, есть сервис для онлайн-обучения.
В нём пользователь может:
- зарегистрироваться;
- выбрать курс;
- оплатить доступ;
- проходить уроки;
- выполнять задания;
- получать уведомления;
- смотреть прогресс;
- скачать сертификат после завершения.
На уровне системного тестирования мы проверяем не одну кнопку и не один API-метод, а всё приложение как единое целое.
Например:
- новый пользователь может зарегистрироваться;
- письмо подтверждения приходит;
- после оплаты открывается нужный курс;
- уроки доступны в правильном порядке;
- прогресс сохраняется;
- сертификат появляется после выполнения условий;
- пользователь без оплаты не может открыть закрытые материалы.
То есть системное тестирование отвечает на вопрос:
“Работает ли продукт целиком так, как должен?”
Чем системное тестирование отличается от интеграционного
Иногда новички путают интеграционное и системное тестирование.
Разница такая:
Интеграционное тестирование — проверяем взаимодействие между частями системы.
Системное тестирование — проверяем всю систему целиком с точки зрения требований.
Например:
Проверить, что сервис оплаты корректно передал статус платежа в личный кабинет — это ближе к интеграционному тестированию.
А проверить весь путь пользователя от регистрации до получения доступа к курсу — это уже системное тестирование.
4. Приёмочное тестирование
Приёмочное тестирование — это проверка того, готов ли продукт к использованию заказчиком или конечным пользователем.
Его ещё называют acceptance testing.
На этом уровне главный вопрос звучит так:
“Можно ли принимать эту работу?”
То есть система может быть технически рабочей, но всё равно не подходить бизнесу.
Например, кнопки нажимаются, данные сохраняются, ошибок нет. Но бизнес-правило реализовано неправильно.
Пример
Допустим, команда делает сервис записи на обучение внутри компании.
По требованиям:
- сотрудник может записаться только на один курс в одно и то же время;
- руководитель должен видеть список записавшихся сотрудников;
- HR должен иметь возможность выгрузить отчёт;
- после записи сотруднику должно приходить уведомление.
Системное тестирование может показать, что приложение в целом работает.
Но на приёмочном тестировании заказчик или представитель бизнеса проверяет:
- действительно ли это решает его задачу;
- соответствует ли продукт согласованным требованиям;
- можно ли выпускать функциональность в работу;
- удобно ли этим пользоваться в реальном процессе.
Кто проводит приёмочное тестирование
Зависит от компании.
Это могут быть:
- заказчик;
- бизнес-аналитик;
- product owner;
- QA;
- пользователи со стороны бизнеса;
- команда вместе с представителями заказчика.
Иногда QA заранее проводит внутреннюю проверку по приёмочным критериям, чтобы заказчику не ушёл сырой функционал.
Как эти уровни связаны между собой
Если расположить уровни от самого маленького к самому крупному, получится так:
- Модульное тестирование — проверяем отдельные функции и маленькие части кода.
- Интеграционное тестирование — проверяем взаимодействие между частями системы.
- Системное тестирование — проверяем всё приложение целиком.
- Приёмочное тестирование — проверяем, готов ли продукт для бизнеса и пользователей.
Можно представить это как сборку машины.
Сначала проверяют отдельные детали.
Потом проверяют, как детали соединяются друг с другом.
Потом проверяют всю машину целиком.
А потом заказчик смотрит: подходит ли эта машина под его задачу.
Почему новичку важно это понимать
На старте может казаться:
“Я же просто проверяю приложение. Зачем мне эти уровни?”
Но понимание уровней тестирования помогает мыслить шире.
Вы начинаете видеть не просто кнопку на экране, а всю систему за ней.
Например, если пользователь нажал “Записаться”, а запись не появилась, проблема может быть где угодно:
- ошибка в логике проверки времени;
- frontend отправил неправильные данные;
- backend не обработал запрос;
- база не сохранила запись;
- уведомление не ушло;
- права доступа настроены неверно.
Если QA понимает уровни тестирования, ему проще локализовать проблему и грамотнее описать баг.
Не просто:
“Кнопка не работает”.
А конкретнее:
“При создании записи запрос уходит успешно, но после ответа backend запись не появляется в списке пользователя. Возможно, проблема на уровне сохранения или получения данных.”
Такой баг-репорт уже выглядит намного профессиональнее.
Типичная ошибка новичков
Многие новички думают, что тестирование — это только открыть сайт и потыкать кнопки.
Но реальное тестирование — это не хаотичное нажатие на всё подряд.
QA должен понимать:
- какую часть системы он проверяет;
- на каком уровне может быть ошибка;
- какие данные участвуют в сценарии;
- какие модули связаны между собой;
- какой результат ожидает пользователь или бизнес.
Именно поэтому классификации в тестировании нужны не для заучивания терминов, а для мышления.
Короткая шпаргалка
Модульное тестирование
Проверяем маленькую часть кода. Обычно этим занимаются разработчики.
Интеграционное тестирование
Проверяем, как разные части системы работают вместе.
Системное тестирование
Проверяем всё приложение целиком по требованиям.
Приёмочное тестирование
Проверяем, можно ли принимать продукт и отдавать его пользователям или бизнесу.
Итог
Классификация тестирования по уровню детализации помогает понять, на каком масштабе мы смотрим на приложение.
Иногда мы проверяем маленькую функцию.
Иногда — связь между сервисами.
Иногда — весь продукт.
А иногда — готовность продукта к реальному использованию.
Для junior QA это важная база.
Не потому что на собеседовании могут спросить определения. Хотя могут.
А потому что без понимания этих уровней сложно разобраться, где именно сломалась система и как правильно описать проблему.
Хороший тестировщик не просто видит баг.
Он понимает, на каком уровне этот баг мог появиться и как его лучше проверить.