Sentry для тестировщика: как читать ошибки и стектрейсы

Sentry — это сервис для отслеживания внутренних ошибок приложения: он показывает не то, как запрос путешествовал между микросервисами, а то, что именно сломалось внутри конкретного сервиса — на какой строке кода произошла ошибка, какая функция её вызвала и какой SQL-запрос выполнялся в этот момент. Если Kibana отвечает на вопрос «где в цепочке запрос сломался», то Sentry отвечает на вопрос «что конкретно пошло не так внутри кода» — и для тестировщика это второй обязательный инструмент диагностики после логов запросов. О первом инструменте — в статье «Kibana для тестировщика: как искать баги в логах».

Kibana хорошо показывает взаимодействие между сервисами: какие запросы и ответы летали между общей шиной, микросервисами и внешними провайдерами. Но если проблема не в сетевом взаимодействии, а внутри самого сервиса — например, разработчик допустил опечатку в коде или функция упала на конкретной строке — Kibana этого не покажет. Она видит только HTTP-запросы, а не то, что происходит внутри процесса обработки.
Для таких случаев существуют отдельные сервисы логирования внутренних ошибок — Sentry и его аналоги вроде BugsNag. Разница простая: Kibana работает на уровне сетевого взаимодействия, а Sentry — на уровне кода и функций внутри одного сервиса.

Основной рабочий экран в Sentry — вкладка Issues, куда стекаются все внутренние ошибки и краши приложения. По каждой такой ошибке видно количество событий за выбранный период — например, сколько раз она произошла за последние сутки или за две недели, что сразу подсказывает, насколько проблема массовая.
Внутри конкретной ошибки доступны детали: язык программирования (Runtime), HTTP-статус ответа — который, что важно, может быть и 200, хотя внутри всё равно случилась проблема, URL запроса, SQL-запросы, которые сервис делал в базу данных в этот момент, время выполнения функции, и самое ценное — stack trace, то есть цепочка вызовов функций с указанием конкретного участка кода, где произошла ошибка.
Sentry особенно часто используется в мобильных приложениях, потому что там много крашей: перегрев устройства, нехватка памяти, неожиданные падения приложения. Сервис позволяет анализировать такую нестабильность в динамике — сколько ошибок было за две недели, есть ли рост, какие проблемы критичны, а какие можно отложить.
В Sentry также доступны фильтры по времени, проекту, конкретному пользователю, серверу, статусу ошибки (решена / открыта / игнорируется), браузеру, версии релиза и тексту сообщения об ошибке. Запоминать все фильтры наизусть не нужно — интерфейс интуитивно понятен, важно знать, что такая возможность в принципе есть. Уровни логов, которые встречаются в записях, разобраны в статье «Логирование и уровни логов: FATAL, ERROR, WARN, INFO, DEBUG».

Хороший пример того, что можно узнать через Sentry — реальная история с ошибкой unauthorized host. Один из хостов обращался к API проекта, но его не было в списке разрешённых адресов. По деталям в Sentry было видно, кто именно стучится в систему — в данном случае это оказалась сторонняя организация, судя по всему занимающаяся автоматическим сбором данных с сайтов. Система просто отказала в доступе неизвестному источнику.
Этот кейс показывает, что Sentry полезен не только для поиска багов в собственном коде, но и как источник информации о том, кто и как взаимодействует с системой — включая нежелательный трафик, о котором иначе можно было бы даже не узнать.

Флоу простой и не требует глубокого понимания кода. Когда в системе возникла ошибка, тестировщик заходит в Sentry, во вкладку Issues, фильтрует записи — чаще всего по времени, например за последние 24 часа, — и находит свою ошибку среди списка. Дальше нужно скопировать ссылку на конкретную ошибку и приложить её в баг-репорт. Разработчик открывает эту ссылку и сразу видит участок кода, на котором всё сломалось, — что экономит время на переписке и уточняющих вопросах.
Детальный разбор самого кода и логики ошибки — это уже задача разработчика, а не тестировщика. Роль QA здесь — найти проблему, зафиксировать и передать с максимально точной информацией, а не разбираться, почему именно код упал на этой строке. Со временем, по мере погружения в проект, тестировщик может начать читать stack trace глубже, но базовая обязанность — найти, скопировать ссылку и приложить в баг-репорт.

На разных проектах для этой цели используют разные сервисы: где-то это Sentry, где-то — BugsNag, но принцип работы одинаковый. Оба показывают конкретную строку кода, на которой возникла ошибка, полный стек вызовов, данные о запросах и пользователях, а иногда и «хлебные крошки» — последовательность действий, которые пользователь совершил до момента падения. На практике на многих проектах ошибки из такого сервиса автоматически прилетают прямиком в рабочий чат команды — тестировщик видит свою ошибку почти сразу после того, как столкнулся с ней в интерфейсе, повторно её воспроизводит, находит соответствующую запись и уже с ней идёт заводить баг-репорт. Для тестировщика не так важно, какой именно сервис используется на конкретном проекте — важно понимать общую логику: внутренние ошибки сервиса логируются отдельно от сетевого взаимодействия, и у этого лога есть свой понятный интерфейс с фильтрами и деталями по каждой ошибке.

Вопрос про локализацию 500-й ошибки — один из самых частых у интервьюеров, и грамотный ответ звучит как связка из двух инструментов. Если проблема в том, что сломалось взаимодействие между сервисами — ищем Trace ID и восстанавливаем цепочку в Kibana. Если проблема оказалась внутри конкретного сервиса — открываем Sentry, находим ошибку по времени, смотрим stack trace и конкретный участок кода. Кандидат, который может внятно описать оба сценария и объяснить разницу между ними, сразу выделяется на фоне тех, кто знает только общее слово «логи» без понимания, какой инструмент за что отвечает.
Умение уверенно работать с Sentry наравне с Kibana закрывает практически весь набор вопросов про локализацию 500-й ошибки на собеседовании. В Quality Academy на курсе «Инженер по ручному тестированию» оба инструмента разбираются в связке на реальных примерах, чтобы на выходе получился рабочий навык диагностики багов.