Когда начинающий QA или разработчик сталкивается с понятием "юнит-тесты", часто возникает ложное чувство безопасности: мол, если в коде всё покрыто юнитами — багов быть не может. Программа идеально работает. Можно не тестировать вообще или, по крайней мере, не подключать ручного тестировщика.
Но в реальности юнит-тесты — это всего лишь один из слоёв обороны. В этой статье подробно разберём, почему юнит-тесты не заменяют ручного тестирования, какие у них ограничения, в чём сила живого тестировщика и как всё это работает вместе.
Что такое юнит-тесты?
Юнит-тесты (от англ. "unit" — единица) — это автоматические проверки небольших частей кода, как правило, отдельных функций или методов. Их пишут разработчики, чтобы убедиться, что каждый фрагмент системы ведёт себя правильно при определённых входных данных.
Пример юнит-теста:
def test_sum():
assert sum([1, 2, 3]) == 6
Всё очень просто: мы проверяем, что функция sum() работает так, как задумано.
Плюсы юнит-тестов:
- Выполняются быстро (в пределах секунд)
- Полностью автоматизированы: их можно запускать в любое время, без участия человека, прямо при каждом коммите в код. Работают как тревожная кнопка — сразу покажут, если что-то сломалось.
- Помогают поддерживать стабильность при рефакторинге: если ты меняешь логику функции, а старые юнит-тесты начинают падать — это прямой сигнал, что ты что-то поломал (или тесты устарели).
- Ловят баги на уровне логики отдельных функций: например, если функция должна делить одно число на другое, а ты забыл обработать деление на ноль — юнит-тест тебе это сразу покажет. Но только если ты заранее догадался написать этот тест.
Но есть и минусы:
- Они проверяют только то, что явно заложено в тестах: если ты не предусмотрел, что пользователь введёт в поле имя 200 символов с эмодзи, — никакой юнит об этом не узнает. Он даже не моргнёт. Он робот. Делает то, что ты ему прописал. И не на йоту больше.
- Не охватывают взаимодействие компонентов: когда два идеально работающих модуля при встрече начинают вести себя как токсичная парочка. Один ждёт строку, второй шлёт null — и пошло-поехало. А юнит-тесты тут бессильны, потому что каждый тестируется отдельно, в своей песочнице.
- Не тестируют интерфейс, пользовательские сценарии, визуальные баги: юнит-тест не заметит, что кнопка съехала за пределы экрана, шрифт выглядит так, будто его растянули на китайской свадьбе, или что при нажатии на кнопку ничего не происходит, потому что клик попадает мимо. Всё это для него — тёмный лес. Он видит только то, что происходит в логике кода, и полностью слеп к тому, что видит пользователь глазами.
А что делает ручной тестировщик?
Тестировщик — это не тот, кто просто кликает мышкой. Это человек, который мыслит, ищет нестандартные ситуации, проверяет реальные пользовательские сценарии, придумывает негативные кейсы, работает в условиях неопределённости и ловит баги, которых код не ожидает.
Примеры задач ручного тестирования:
- Проверка корректности формы (ввод, валидация, граничные значения)
- Проверка пользовательского пути (логин → оформление заказа → оплата)
- Проверка адаптивности интерфейса
- Проверка поведения при плохом интернете, сбоях, нестандартных действиях
- Проверка кроссбраузерности и устройств
Тестировщик работает с тем, как пользователь на самом деле взаимодействует с системой.
Где юнит-тесты бессильны?
- UI и UX. Юнит-тест не увидит, что кнопка "Оформить заказ" уехала за пределы экрана на iPhone.
- Баги на стыках компонентов. Функция A работает. Функция B работает. А вместе они — не работают.
- Непредусмотренные сценарии. Пользователь ввёл в поле email 3 смайлика и пробел. Что будет? Код не знает. А тестировщик проверит.
- Системные баги. Отказ БД, баг при обновлении, сбой при загрузке файлов — юниты не покрывают это.
- Регрессия при интеграции. Новая фича может сломать старую — особенно, если команды работают параллельно.
Почему юнит-тесты =/= "тестировщик не нужен"
Это как сказать, что охранник на входе заменяет камеры, сигнализацию и систему безопасности. Один юнит-тест не заметит, что клиент не может оплатить заказ, потому что кнопка скрыта. А тестировщик это увидит за 5 минут.
Юнит-тест — это проверка "механики". Тестировщик — это проверка "жизни".
Пример из жизни
Сценарий: интернет-магазин, форма оформления заказа.
Форма состоит из:
- Поле email
- Выбор способа доставки
- Оплата
Юнит-тесты покрывают:
- Email проходит валидацию
- Цена правильно рассчитывается
- Метод checkout() возвращает статус 200
А что проверяет тестировщик:
- Поле email не принимает пробел в начале (а вот и баг)
- В Firefox кнопка "Оплатить" перекрыта попапом (второй баг)
- При медленном интернете форма зависает после клика (третий баг)
- После перехода назад в браузере поля не сохраняются (четвёртый баг)
Юнит-тесты пройдут ✅
Юзер пойдёт писать злой отзыв ❌
Как работать вместе: разработка + QA
Юнит-тесты и ручное тестирование не конкуренты. Они — команда.
Хорошая практика:
- Разработчик пишет юнит-тесты → покрывает базовую логику (типа: «если пользователь нажал кнопку — в переменной X должно быть true». Всё чётко, строго, без сюрпризов. Но сюрпризы начнутся, когда кнопку нажмёт реальный пользователь, у которого браузер 2012 года, и палец соскользнул на полсекунды раньше...)
- Тестировщик применяет тест-дизайн → покрывает сценарии и границы (и не просто «вот тут сценарий, вот тут граница», а проверяет, как пользователь будет ломать систему из любопытства, лени или чистого хаоса. Он не доверяет интерфейсу на слово и знает, что пользователь обязательно нажмёт туда, куда не надо. И именно туда QA направляет свои атаки — с тест-кейсами, партициями, эквивалентами и всей армией техники тест-дизайна).
- Совместно формируют регрессионный набор — QA предлагает сценарии на основе пользовательского поведения и прошлых багов, разработчик добавляет туда автотесты, которые будут проверять, что при каждом новом релизе старые функции остаются живыми и не разваливаются.
- Подключают CI/CD для непрерывной интеграции, запускают автотесты при каждом пуше и релизе, а также дополняют всё это ручными сценариями — особенно там, где нужна гибкость мышления, креатив и человеческий взгляд на поведение системы
Идеальная связка: тест-кейсы от QA → автоматизация наиболее стабильных → ручное покрытие нестандартных и креативных кейсов.
Что должен знать джун QA о юнит-тестах?
- Ты не пишешь юниты — но должен понимать, что они есть
- Не доверяй им вслепую — всегда перепроверяй пользовательский путь
- Научись читать покрытие кода — это даст представление, что уже проверено
- Общайся с разработчиком — уточни, какие юниты есть, какие граничные случаи он покрыл
- Не бойся искать баги там, где "всё работает" — потому что «всё работает» — не значит, что всё проверено
Итоги: кратко и по делу
- Юнит-тесты нужны — это база для стабильности кода
- Ручное тестирование нужно — это база для стабильности продукта
- Вместе — они создают уверенность, что софт работает не только на экране разработчика
- Уверенность QA — это не "всё ок", а "я знаю, что и где проверено"
И да: если тебе говорят, что юнит-тесты — это всё, что нужно, — просто пошли им эту статью 😉