Как создать баг-репорт

В этой статье вы можете найти ответы на вопросы: «как написать баг-репорт», «почему баг-репорт настолько важен», «где следует создавать баг-репорт». Мы коснемся основных аспектов, которые вам нужно знать чтобы писать эффективные и полезные баг-репорты.

Почему важен баг-репорт

Вы тестируете проект и тест не проходит. Мои поздравления – вы обнаружили ошибку :) Теперь вы должны сообщить о ней, и создать баг-репорт.

В случае, если ваш баг-репорт будет составлен грамотно, он поможет вашим разработчикам исправить ошибку и сделать более надежный продукт.

Как грамотное оформление помогает разработчикам:

  • Рассказывает о проблемах, о которых они не знают
  • Помогает определить новые функции, о которых они, возможно, и не думали
  • Помогает понять, как их клиенты используют программное обеспечение, что бы они могли сделать его лучшим

И если вы напишете свой баг-репорт корректно – больше шансов что ошибка будет исправлена. Поэтому исправление ошибок напрямую зависит от того, как вы сообщаете об этом.

Каким должен быть баг-репорт

Любой может написать баг-репорт. Но не все могут сделать его информативным и полезным. Вы должны уметь отличать посредственное описание от хорошего.

Полезные репорты это те, которые приводят к исправлению ошибки. Хороший баг-репорт должен быть:

  • Воспроизводимый – если воспроизведение бага невозможно, то он не будет исправлен. Чем скорее и проще разработчик сможет воспроизвести ошибку, тем скорее он ее исправит. В противном случае, более вероятно, что разработчик просто перейдет к следующему баг-репорту. В описании ошибки вы должны четко описать шаги для воспроизведения, не пропуская ни одного из них.
  • Конкретный и информативный - не надо писать целое эссе о проблеме. Постарайтесь быть конкретными и максимально информативными. Стремитесь описать проблему с минимальным количеством слов. И в любом случае, не суммируйте несколько ошибок, даже если они кажутся похожими. Напишите разные отчеты для каждой ошибки.

Таким образом, цели отчета об ошибке:

  • Объяснить ошибку разработчику и показать, где она находится
  • Помочь разработчику исправить ее с минимальными затратами времени

bug report

Содержание баг-репорта

Title (Заголовок): В заголовке должно быть краткое описание проблемы. Хороший заголовок должен содержать информацию о названии продукта или сообщение об ошибке или о шагах, которые вы делали, когда что-то не удалось.
Например:

  • Нельзя делать: “Креш”, “Нашли ошибку”, “Баг
  • Нужно делать: “Ошибка 5C79 когда сервер принимал запрос

Product (Продукт): Укажите название продукта и его версию.

  • Нельзя делать: “Это приложение
  • Нужно делать: “MyApp

Classification (Классификация ошибки):

Очень важно классифицировать ошибку, незначительная ошибка, значительная ошибка, сбой в приложении. Большинство инструментов имеют набор классификаторов, но если их нет, используйте эти: “New feature” (Новая функция), “Minor Annoyance” (Незначительная надоедливость), “Crashing Bug” (Сбой), “Serious Bug” (Серьезная ошибка) или “Minor Bug” (Незначительная ошибка).

  • Нельзя делать: "Leave it blank"(Оставить пустым)
  • Нужно делать: Serious Bug” (Серьезная ошибка), “Annoyance” (Надоедливость), “Feature Request”(Запрос функции)

Platform (Платформа): Будет большим плюсом определить, что вы используете для запуска программного обеспечения, в частности имя и версия операционной системы, в случае веб-приложения, должны указывать имя и версию веб-браузера.

  • Нельзя делать: “Windows
  • Нужно делать: “Windows 7, Internet Explorer 9

Summary (Описание) : Попробуйте кратко описать, что вы пытались сделать, прежде чем найти баг и как отреагировало на это ваше приложение. Используйте простой естественный язык.

  • Нельзя делать: “Приложение не работает
  • Нужно делать: “Нажать на кнопку и выбрать файл/ Сохранить как… и нажать ОК →файл не сохранился

Steps to reproduce (Шаги по воспроизведению): Будет здорово, если вы сможете воспроизвести эту ошибку снова. Потому что воспроизводимые ошибки легче исправить. Вы должны описать, как воспроизвести эту ошибку шаг за шагом, настолько детально насколько это возможно. Но не забывайте, вы должны быть лаконичны.

  • Нельзя делать: “
    • Главная страница >Левая кнопка>нажать
    • Магазин>попробовать купить что-то>ты не можеш"
  • Нужно делать: “
    • Перейти в настройки > Мой профиль
    • Нажать на фото профиля > Удалить фото

Expected Result (Ожидаемый результат): Что должно произойти, когда вы делаете какое-нибудь действие? Что вы ожидаете?

  • Нельзя делать: “Все должно работать
  • Нужно делать: “При нажатии на кнопку "Скачать", файл должен быть скачан в Загрузки

Actual Result (Фактический результат): Результат ошибки. Что случилось на самом деле?

  • Нельзя делать: “Кпонка работает не правильно”
  • Нужно делать: “Кнопка закрывает приложение”

Priority (Приоритет): Он показывает разработчику на какой баг обратить внимание в первую очередь. Приоритет обычно устанавливается от 1 до 5. Чем ниже число, тем выше приоритет. "1" - должны быть исправлены как можно скорее. "5" - можно исправить, когда позволяет время.

Severity(Серьезность): Описывает влияние ошибки.

 Типы Серьезности:

  • Blocker: вы не можете продолжить тестирование.
  • Critical: Авария приложения, Потеря данных.
  • Major: очень важная функция не работает.
  • Minor: важная функция не работает.
  • Trivial: Некоторые усовершенствования пользовательского интерфейса.
  • Enhancement: Запрос на новую функцию или некоторое улучшение в существующих функциях.

Status (Статус): Он показывает статус отчета об ошибке в любой системе отслеживания багов. В начале статус отчета об ошибке будет "New". После этого статус может измениться на Fixed, Verified, Reopen, Won’t Fix и тд. Все вариации статуса, вы увидите ниже в жизненном цикле баг-репорта.

Attachments (Приложения): Если вы можете сделать скриншот или записать видео - сделайте это. Это будет огромный плюс для разработчиков, если они смогут увидеть, что вы видели перед ошибкой и что после. Просто прикрепите несколько скриншотов к отчету об ошибке.How to run test cases, EasyQA test management tool, QA, software, testing, login, registration, test case, test run, test case execution, saas, EasyQA

 

Вот пример системы отслеживания ошибок - EasyQA, которая имеет все необходимые поля для создания баг-репорта.

Жизненный цикл баг-репорта

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

life cycle

Жизненный цикл ошибки включает следующие этапы или статусы:

  1. New: Когда ошибка обнаруживается и публикуется в первый раз.
  2. Assigned: После того, как тестер сообщил об ошибке, руководство тестировщика подтверждает, что дефект действителен и назначает его разработчику или команде разработчиков.
  3. Open: Это означает, что разработчик начал анализировать ошибку и пытается ее исправить.
  4. Fixed: После того, как разработчик изменил код и исправил ошибку, он изменяет статус баг-репорта на «Fixed», и он может быть отправлен команде QA для повторного тестирования.
  5. Pending Retest: На этом этапе баг-репорт ожидает повторного тестирования.
  6. Retest: На этом этапе тестировщики проверяют изменения внесенные разработчиками и повторно тестируют их.
  7. Verified: Если повторная проверка не обнаружила ошибку и продукт работает правильно, тестер изменяет статус баг-репорта на "Verified".
  8. Reopen: В случае, если после повторной проверки ошибка все еще существует, состояние ошибки изменяется на «Reopen» ошибка возвращается на второй этап жизненного цикла.
  9. Closed: Как только разработчик исправил ошибки, он отправляет продукт тестировщикам для повторного тестирования. Если тестировщик решает, что ошибка исправлена, он или она изменяет статус баг-репорта на «Closed». Это означает, что дефект исправлен, проверен и одобрен.
  10. Duplicate: Если баг повторяется дважды или два бага указывают одну и ту же проблему, тогда один баг-репорт получает статус «Duplicate».
  11. Rejected: Если разработчик считает, что ошибка не является уместной, он отвергает ошибку. Тогда состояние ошибки меняется на “Rejected”.
  12. Deferred: Это означает, что ошибка будет исправлена, но в другой версии, и теперь она подождет. Обычно причиной этого является низкий приоритет ошибок и нехватка времени.
  13. Not a bug: Баг-репорт может иметь такой статус, например, если клиент попросил внести небольшие изменения в продукт: изменить цвет, шрифт и т.д.

Советы по написанию баг-репорта

  1. Шаги которые были раньше: Чтобы исправить ошибки, разработчикам необходимо воспроизвести весь рабочий процесс, который выполняет тестер и система. Поэтому не забывайте описывать шаги конкретно и информативно.
  2. Быть конкретным: Вы должны писать такие же имена полей, кнопок и других элементов, как и в приложении. Если вы хотите описать сообщение, скопируйте и вставьте весь текст сообщения в описание баг-репорта.
    • Меню: Следуйте последовательности меню, разделенных символом '/', например,“File / Save As…”
    • Окна: Посмотрите название окна и укажите его
    • Кнопки или вкладки: Скопируйте и вставьте точный текст
    • Ссылки: Скопируйте и вставьте весь URL-адрес (включая “http://”)
  3. Не переходите на личности: Когда вы сообщаете об ошибке, не забывайте, что вы сообщаете о дефекте программного обеспечения, а не о дефекте разработчика. Будьте вежливы и конкретны. Разработчики могут игнорировать сообщения об ошибках с наступательным и эмоциональном тоном.
  4. Прикрепить или скопировать и вставить: Вы должны приложить как можно больше скриншотов, видео, сообщений и т. д. Это поможет разработчикам легче и быстрее найти проблему и исправить ее
  5. Одна ошибка - один баг-репорт: Ни больше, ни меньше. Один баг в репорте может помочь избежать дублирования и путаницы. Если вы описали слишком много дефектов, некоторые из них могут быть упущены.
  6. Воспроизведите ошибку перед написанием бег репорта: Убедитесь, что ваши действия приводят к воспроизведению этой ошибки. Дефект должен быть воспроизводимым.
  7. Напишите хороший заголовок: Разработчику будет проще анализировать природу ошибок.

.gif

Желаю, чтобы у вас были только хорошие баг-репорты и в любом случае - не расстраивайтесь. Все приходит с практикой. И так...