Как правильно завести баг
Привет! Меня зовут Влад, я QA в Купере. Как и многие тестировщики я выпускал баги в прод — нужно это принять, простить и пережить. В идеале, следующим шагом выстроить кросс-командное взаимодействие так, чтобы этого больше не повторилось. У нас в Купере есть регламент по заведению багов. Хочу поделиться ключевыми идеями оттуда — уверен, они будут многим полезны.
Первый совет: заполни необходимые поля (описание, приоритет) вдумчиво
Да, зачастую именно здесь возникают первые сложности. Важно с первого раза корректно подать информацию, поэтому не жалейте на это 10 минут своего времени — это сэкономит большое количество времени в дальнейшей работе над багом.
Далее пройдёмся по всем важным полям — им же будут посвящены и дальнейшие советы.
Совет второй: описывай проблему максимально доходчиво
1.Название бага. Этот пункт должен отражать общую проблему в 3–5 словах.
Казалось бы, зачем выделять это в отдельный пункт, но сформулировать проблему — это действительно половина успеха.
Чтобы было легче понять, о чем тут речь, я приведу пример:
Плохое описание: «В отчёте при добавлении файла комментария текстовый комментарий стирается». |
Хорошее описание: «Стирается текстовый комментарий в отчёте при добавлении файла комментария». |
Поверьте мне на слово, это сильно экономит время разработчика при воспроизведении бага.
2. Приоритет. Это отразит важность бага и его фикса для продукта.
В нашей команде баги обычно делятся на:
минорные — не несут никакой опасности для приложения;
средние — нужно править, чтобы выкатить доработку в прод;
критичные — блочат работу приложения и править их нужно сиюминутно.
Оценить критичность бага можно по следующим критериям:
Блок для работы приложения — приложение не работает, не запускается или вылетает.
Постоянность воспроизведения — проблема возникает раз в день, либо при каждом запуске, либо каждые n минут.
Важность для заказчика — затрагивает ли баг функционал, который важен для заказчика.
Видимость для пользователя — пользователь видит при запуске приложения надпись SystemError или ошибка есть, но пользователь может и не узнать об этом.
3. Окружение. Это совокупность ПО с указанием версий, в котором воспроизводится баг. Этот пункт должен кратко описывать, где нужно искать, проверять или воспроизводить баг.
Основные поля:
Версия frontend
Версия backend
Браузер (ы) + версия браузера
Стенд или ветка git
Совет третий: корректно формулируй описание шагов и ожидаемого поведения
4. Шаги воспроизведения. Это про use case — он же сценарий для воспроизведения бага.
Что нужно описать:
Шаги формируются в виде списка. Например: 1) Открыть страницу входа, 2) Ввести логин/пароль, 3) Нажать кнопку «Войти».
Шаги указываются, начиная с ключевой точки (логина/прихода на сайт и т.п.).
Шаги указываются максимально точно и подробно. Тут лучше дать больше информации, чем меньше.
Пример воспроизведения use case:
1) Находим нужный нам эндпоинт и нажимаем Try it out.
2) Вводим необходимые данные:
{ «data» : {
«client_phone_number»:»+79299765674»,
«time_zone»: «Europe/Moscow»,
«called_at»:»2024–02–07T15:22:18.219Z» }}
3) Нажимаем Execute, получаем ответ, в котором видно что сессия успешно вызвана и ранее созданная доставка для пользователя с номером +79299765674 найдена.
Тут критично важно последовательно описать шаги, хотя мы все знаем, что от перемены мест слагаемых сумма не меняется.Меняется, поверьте, еще как!
Давайте разбираться на примерах:
5. Ожидаемый результат. Здесь описываем результат, который должен наблюдаться в системе в норме. Это поможет синхронизироваться разработчику и QA в том, какой результат нам нужен при выполнении действия из предыдущего шага.
Какую информацию заносим:
Скриншот с открытой консолью браузера на вкладке network (сеть).
Скриншот с открытой консолью браузера на вкладке console.
Скриншот с указанием правильного результат теста.
6. Фактический результат. Это реальный результат работы системы после выполнения указанных шагов. Рекомендации и требования я использую те же, что и в
Совет четвертый: не допускай эти частые ошибки
Как только к вам принесли баг — проверьте его на наличие ошибок. Давайте рассмотрим основные из них:
1. Дубликат: убедитесь, что найденный баг еще не был оформлен. Поищите его в соответствующем проекте по всем подходящим ключевым словам или полям. Если баг уже есть, то вам нужно обновить его описание.
2. Неправильное назначение бага: он может затеряться, если по ошибке был назначен не на того разработчика или вообще остался в статусе «не назначен».
3. Недостаточность предоставленных данных: не всегда одна и та же проблема проявляется при всех вводимых значениях и под любым вошедшим в систему пользователем, поэтому вносите все необходимые данные в баг-репорт. Иначе баг будет отклонён разработчиком, а вам придётся потратить время на его детальное описание.
4. Отсутствие ожидаемого или полученного результата: если вы не указали, что же должно быть ожидаемым поведением системы, то вы тратите время разработчика на поиск данной информации, что влечет неизбежное замедление исправления дефекта. При описании укажите ссылку на пункт в требованиях, на написанный тест-кейс или поделитесь вашим личным мнением, если конечный результат не задокументирован.
Совет пятый: мониторьте статус багов
У каждого бага есть свой жизненный цикл, который состоит из статусов. А описание этих статусов помогает сократить время на синхронизацию с разработчиком, так как все сразу видят на каком этапе находится решение проблемы. Мы обходимся десятью статусами, мне кажется это количество оптимальным, но их число может меняться в зависимости от ваших задач.
Новый (New). Тестировщик нашел баг, дефект успешно занесен в bug-tracking систему.
Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен — он все так же потребует исправления, поэтому вновь открывается.
Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды — он объявляется закрытым.
Кажется, что на этом у меня все. Давайте выделим главные моменты, на которые следует обращать внимание любому тестировщику при заведении бага:
1. Баг должен быть правильно и понятно описан.
2. Он не должен быть дублем.
3. У бага должен быть правильный статус.
А еще не забывайте, что разработчик, за которым закреплен баг, может уйти в отпуск или на больничный. Уточняйте к кому на это время переходит задача, чтобы решение бага не затянулось на неопределенный срок. Буду рад почитать в комментариях другие советы о том, как эффективнее всего заводить баги.
Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
