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