🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 17.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Большую часть дня мы, тестировщики, ищем ошибки. Но на этом работа не заканчивается… Для нас главное – четко объяснить ошибки разработчику, чтобы он сразу понял суть проблемы. И для этого заполняется баг-репорт.
Хороший баг-репорт экономит часы работы, а плохой обычно ведет к нескончаемой переписке в Slack. И начинается она с классического вопроса: «Можете прислать более подробную информацию?»
Давайте поговорим о том, как составлять понятные, полезные и вежливые баг-репорты. Разберем все на примере простых ситуаций, которые возникают в любом мобильном приложении, на сайте, в банковской системе или в онлайн-магазине.
Правильное название задает нужный тон
Называть тикет абстрактно – это как начинать книгу с середины фразы: никто не поймет, о чем речь.
Примеры плохих названий:
«Не работает логин»
«Проблема с кнопкой»
«Ошибка на странице оплаты»
А вот несколько хороших названий:
«Страница входа: если указать неверный адрес почты, то не работает кнопка «Продолжить» (Chrome)».
«Корзина: при удалении товара из корзины общая стоимость не меняется»
При попытке изменить номер телефона на странице «Профиль», высвечивается ошибка 400
«Профиль -> Сохранить изменения» – выдает ошибку 400, когда пытаюсь изменить свой номер
Легко выполнимые шаги для воспроизведения
Описывайте шаги так, чтобы человек, который только вчера пришел к вам на работу, мог без труда все повторить. И не дергал вас лишними вопросами.
Пример:
- .Запустите приложение на телефоне
- Перейдите на страницу профиля
- Нажмите «Изменить адрес»
- Введите реальную почту
- Нажмите «Сохранить»
- Результат: на 3-4 секунды экран зависает, а адрес все равно не меняется.
Кратно, ясно и по существу. Лаконично и без лишних подробностей.
Пишите честно и по делу: чего вы ожидали и что получили
Многие тестировщики непроизвольно превращаются в поэтов. Так делать не стоит. Разработчикам нужны факты, а не драматичный сюжет.
Ожидаемый результат:
При нажатии на кнопку с сортировкой «Цена: по возрастанию» товары должны быть правильно упорядочены.
Фактический результат:
Меняются только первые несколько позиций; остальные элементы остаются в том же порядке.
Добавляйте подтверждения: логи, запросы и ошибки
С визуальным подтверждением бага ваш отчет переходит из категории «возможно, этот баг и был» в «этот баг однозначно был».
Вот несколько примеров хороших подтверждений:
- Короткое видео с проблемой
- Скриншот проблемы
- Ошибки в консоли
- API-ответ с некорректными данными
- Запрос, который не работает во вкладке Network
- Изображение с сообщением об ошибке
- Временная метка, ID запроса или любая техническая и полезная информация
Реалистичный и бытовой пример: Если в банковском приложении нажать «Перевести сумму», то операция выглядит успешной. Пользовательский интерфейс отображает нужную информацию, но на деле API-запрос возвращает ошибку 403 Forbidden. Если отправить разработчику только скриншот пользовательского интерфейса, то он не увидит истинной причины ошибки.
Подробности о среде (важные мелочи)
Разные устройства и браузеры ведут себя по-разному. Иногда – слишком по-разному.
Всегда указывайте:
- Браузер и версия (при необходимости)
- ОС (Windows/macOS/Android/iOS)
- Тип устройства
- Среда тестирования (dev, staging, prod)
- Авторизованный пользователь или гость
Вежливость важна, но не переборщите
Сообщая об ошибке, вы никого не «беспокоите». Это ваша работа.
Воздержитесь от сообщений по типу:
«Извините, что беспокою…»
«Возможно, я ошибаюсь, но…»
«Вероятно, вы уже знаете, что…»
Лучше выражайте свою мысль четко и вежливо:
«В браузере Firefox было замечено следующее […]. Пожалуйста, проверьте при первой возможности.
Не слишком резко и не слишком заискивающе.
Не забывайте о фоновой информации
Все-таки вы пишете не сценарий для фильма. И для некоторых багов нужен контекст, потому что они:
• Возникают только на определенных устройствах
• Проявляются только для определенных ролей пользователей
• Связаны с кэшированием, ограничением количества запросов или проблемами синхронизации
• Зависят от бизнес-правил или особых условий
Сюда же можно добавлять информацию о среде (если это уместно). Тогда ваш отчет станет еще более информативным.
Например:
• Размер экрана, масштаб страницы, расширения для браузеров или отзывчивые брейкпоинты – все это задачи, связанные с проектированием
• Информация об устройстве и среде (версия ОС, версия браузера, любые расширения, которые могут повлиять на рендеринг или скрипты). Например, .«Если в десктопной версии Chrome увеличить масштаб страницы до 125%, то кнопки логина и пароля не выравниваются по вертикали».
Но не делайте свои отчеты слишком длинными.
Обойдитесь без непрошенных советов о том, как все исправить
Вы не разработчик, а тестировщик.
Если вы не подкованы в технических вопросах, то не нужно строить домыслы о решении.
Вот плохие варианты:
«Мне кажется, что бэкенде что-то не то»
«Фронтенд сломался»
«Можете переписать эту функцию?»
Лучше просто расскажите о том, что увидели:
«Этот запрос возвращает код состояния 500. Возможно, поможет в исправлении».
Такое сообщение показывает: вы понимаете то, что делаете, и не гадаете на кофейной гуще.
В заключение стоит добавить, что хороший баг-репорт ускоряет всю команду.
Качественно составленный баг-репорт позволяет достичь следующих результатов:
- Ускоряется отладка
- Меньше лишних переписок и перекидывания задач
- Исправления легче понять
- Меньше недопониманий
- Счастливый разработчик
- Счастливый QA (ведь ему легче тестировать доработки)
Быть хорошим тестировщиком – это не просто уметь находить ошибки. Хороший тестировщик ценит время и силы каждого, поэтому умеет правильно сообщать об ошибках.
Хороший баг-репорт помогает разработчикам быстрее работать, избегать лишних переписок и перекидывания задач, а также позволяет команде сосредоточиться на обеспечении качества своего продукта.
Тестирование – это командная работа, а главное связующее звено внутри команды – хорошая коммуникация.
Перевод статьи «The Art Of Writing a Bug Report».