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

Тестирование — это процесс поиска несоответствий между ожидаемым и фактическим поведением продукта. Ожидаемое поведение продукта всегда берем из требований и здравого смысла. Задача тестировщика — задать вопрос: «А точно ли система делает то, что должна?». Например:

• На сайте отображается кнопка “Скачать”, но при нажатии ничего не происходит.
• Пользователь вводит email без “@” и происходит ошибка валидации.
• Мобильное приложение крашится при повороте экрана.

Во всех этих случаях тестировщик фиксирует проблему, описывает, как её воспроизвести, и передаёт дальше.

⚠️ Важно: тестировщик не обязан знать, почему так происходит. Его задача — найти проблему, доказать её наличие и дать разработчику всё, чтобы тот не тратил час на воспроизведение.

Дебаггинг (от debug — устранение ошибок) — это поиск причины уже обнаруженной ошибки. Его цель — ответить на вопрос: «Почему это произошло?» и «Где в коде это сломалось?». Например:

• Страница падает при клике на кнопку → дебаг показывает, что в event handler’е вызывается метод у undefined.
• API отдает 500 → лог показывает, что невалидный параметр уходит в базу, а та не справляется с форматом.
• Анимация не запускается → разработчик обнаруживает, что условие isActive всегда false из-за опечатки в логике.

Дебаггинг — это внутренняя кухня разработки. Он требует знания кода, логики системы и инструментов вроде логов, отладчиков, трейсинга, иногда просто интуиции. Хороший продукт создаётся, когда между тестированием и дебаггингом нет “перетягивания каната”, а есть сотрудничество. Каждый делает своё — и делает это хорошо.

Тестировщик ищет баг:

• читает требования,
• проверяет, как работает,
• замечает несоответствие,
• воспроизводит,
• описывает.

Разработчик читает баг:

• смотрит описание,
• воспроизводит сам,
• запускает дебаг,
• находит причину,
• чинит.

Иногда они помогают друг другу:

• Тестировщик подсказывает, в каком билде это появилось. Тестировщик может помочь: в запросах посмотреть, какой ответ приходит невалидным, что может мешать работе приложению. Человеческими словами и логикой – без описания функции на Kotlin.
• Разработчик делится workaround’ом, чтобы тест дальше продолжался.

У каждого должна быть своя зона ответственности. Но стоит начать подменять роли — и всё рушится. Тестировщик лезет в код и делает ошибочные выводы. Разработчик игнорирует баг, потому что “не смог воспроизвести”.

1. Чтобы не тратить время и нервы.
   Когда тестировщик пытается сам “поковыряться” в коде, не зная всех нюансов, он может пойти по ложному следу. А разработчик потом будет чинить не то.
2. Чтобы не терять баги.
   Иногда баг нестабилен. И если его не зафиксировали на этапе тестирования (пусть даже без понимания причины), то он уходит в прод.
3. Чтобы понимать, где зона роста.
   Джуны часто путают дебаггинг и исследовательское тестирование. Думают, что, раз нашли ошибку, надо сразу копать в код, а не научиться оформлять кейс. А иногда наоборот — думают, что тестирование это “потыкать кнопки”, и не задумываются, откуда берётся баг.

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

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

Тестирование и дебаггинг — это не конкурирующие процессы. Они как разведка и спецназ: одни находят цель, другие — устраняют.

Если ты тестировщик — научись быть “глазами” проекта: замечать детали, фиксировать отклонения, передавать баги чётко и по делу.
Если ты разработчик — умей доверять баг-репортам, даже если “у тебя не воспроизводится”.

А в идеале — чтобы и те, и другие уважали труд друг друга и работали на общий результат.