Если ты когда-либо писал баг-репорт и в ответ получал “а у меня работает”, скорее всего, ты где-то оказался на границе между тестированием и дебаггингом. Эти два процесса часто пересекаются, особенно в голове у начинающих тестировщиков. Но по сути — это разные роли, подходы и даже менталитет. Давайте будем разбираться.
Тестирование — это процесс поиска несоответствий между ожидаемым и фактическим поведением продукта. Ожидаемое поведение продукта всегда берем из требований и здравого смысла. Задача тестировщика — задать вопрос: «А точно ли система делает то, что должна?». Например:
На сайте отображается кнопка “Скачать”, но при нажатии ничего не происходит. Пользователь вводит email без “@” и происходит ошибка валидации. Мобильное приложение крашится при повороте экрана. Во всех этих случаях тестировщик фиксирует проблему, описывает, как её воспроизвести, и передаёт дальше.
⚠️ Важно: тестировщик не обязан знать, почему так происходит. Его задача — найти проблему, доказать её наличие и дать разработчику всё, чтобы тот не тратил час на воспроизведение.
Дебаггинг (от debug — устранение ошибок) — это поиск причины уже обнаруженной ошибки. Его цель — ответить на вопрос: «Почему это произошло?» и «Где в коде это сломалось?». Например:
Страница падает при клике на кнопку → дебаг показывает, что в event handler’е вызывается метод у undefined. API отдает 500 → лог показывает, что невалидный параметр уходит в базу, а та не справляется с форматом. Анимация не запускается → разработчик обнаруживает, что условие isActive всегда false из-за опечатки в логике. Дебаггинг — это внутренняя кухня разработки. Он требует знания кода, логики системы и инструментов вроде логов, отладчиков, трейсинга, иногда просто интуиции. Хороший продукт создаётся, когда между тестированием и дебаггингом нет “перетягивания каната”, а есть сотрудничество. Каждый делает своё — и делает это хорошо.
Тестировщик ищет баг:
- читает требования,
- проверяет, как работает,
- замечает несоответствие,
- воспроизводит,
- описывает.
Разработчик читает баг:
- смотрит описание,
- воспроизводит сам,
- запускает дебаг,
- находит причину,
- чинит. Иногда они помогают друг другу:
Тестировщик подсказывает, в каком билде это появилось. Тестировщик может помочь: в запросах посмотреть, какой ответ приходит невалидным, что может мешать работе приложению. Человеческими словами и логикой – без описания функции на Kotlin. Разработчик делится workaround’ом, чтобы тест дальше продолжался. У каждого должна быть своя зона ответственности. Но стоит начать подменять роли — и всё рушится. Тестировщик лезет в код и делает ошибочные выводы. Разработчик игнорирует баг, потому что “не смог воспроизвести”.
Чтобы не тратить время и нервы. Когда тестировщик пытается сам “поковыряться” в коде, не зная всех нюансов, он может пойти по ложному следу. А разработчик потом будет чинить не то. Чтобы не терять баги. Иногда баг нестабилен. И если его не зафиксировали на этапе тестирования (пусть даже без понимания причины), то он уходит в прод. Чтобы понимать, где зона роста. Джуны часто путают дебаггинг и исследовательское тестирование. Думают, что, раз нашли ошибку, надо сразу копать в код, а не научиться оформлять кейс. А иногда наоборот — думают, что тестирование это “потыкать кнопки”, и не задумываются, откуда берётся баг. У нас на проекте была ситуация: при обновлении профиля у некоторых пользователей выкидывало 403 ошибку. Казалось бы, логично — авторизация истекла. Но баг появлялся только у новых пользователей и только при определённой последовательности действий.
Тестировщик нашёл это поведение, записал видео, приложил curl-запрос, который воспроизводил баг. Разработчик посмотрел и нашёл, что для новых пользователей не проставлялся обязательный флаг в JWT-токене — баг сидел в логике выдачи токенов. Потратили 15 минут, хотя без этих данных потратили бы сутки на воспроизведение.
Тестирование и дебаггинг — это не конкурирующие процессы. Они как разведка и спецназ: одни находят цель, другие — устраняют.
