Что такое Sentry

Что проверяют

Умеете ли вы работать с потоком настоящих ошибок с прода, а не только с тем, что воспроизвели руками. Тестировщику трекер нужен как источник дефектов и как способ подтвердить выкат, а не как отладчик разработчика.

Как отвечать

Sentry собирает исключения и падения из работающего приложения и складывает их в проблемы. В карточке есть стек, релиз, окружение, платформа и версия клиента, число событий и число затронутых пользователей, хлебные крошки с последними действиями до сбоя.

Как этим пользуется тестировщик:

• разбор после выката: фильтр по релизу отвечает, проблема новая или жила давно. Свежая проблема с растущим счётчиком это кандидат на откат;
• заведение дефекта: из события берут стек, шаги из крошек, версию и окружение и заводят задачу со ссылкой, а не с пересказом;
• приоритет по числу затронутых пользователей, а не событий: один клиент в цикле переповторов даёт тысячи событий и одного пострадавшего;
• проверка исправления: смотрят, перестала ли проблема получать события в новом релизе, и только тогда закрывают;
• на стендах отдельное окружение, иначе собственные проверки замусорят продовый проект.

Где спотыкаются

Считают отсутствие события доказательством, что всё хорошо. Событий может не быть из-за сэмплирования, исчерпанной квоты, блокировщика в браузере или из-за того, что ошибку поймали и молча проглотили в коде. Тишина в трекере это не зелёный прогон.

Заводят дефект прямо из заголовка проблемы. Заголовок это тип исключения и строка кода, он ничего не говорит о том, что видел пользователь. Дефекту нужен сценарий: что было в крошках, какой запрос упал, воспроизводится ли, что осталось на экране.

Ждут от трекера функциональных багов. Неверная сумма в отчёте или кнопка не в том состоянии исключения не бросают и сюда не попадут. Он ловит падения и необработанные ошибки, а логику по-прежнему проверяют тестами.