Выбери корректный баг репорт здравствуйте нашел ошибку

Перейти к содержанию

Автор: Алена Балакина, тренер Первого Онлайн Института Тестировщиков, http://pointschool.ru/

Здравствуйте, дорогие друзья!

Бесспорно, постановка задач — одна из крупнейших составляющих работы практически любого тестировщика.

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

А как описать дефект качественно и составить грамотный баг-репорт?

Читайте дальше — в этой статье мы поделимся некоторыми полезностями по составлению самых важных частей баг-репорта!

Заголовок баг-репорта

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

Почему заголовок это так важно?

1)Заголовки в первую очередь видит руководитель проектов.

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

2)  Заголовки могут пригодиться вам самим.

Представьте, что вы отработали какое то время на проекте, завели кучу дефектов, эти дефекты передали на исправление разработчикам, а вы временно ушли заниматься другими проектами.

Спустя какое то время вы возвращаетесь на проект и получаете задачу — в ускоренном темпе проверить исправленные баги (которые вы сами завели ранее).

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

Принцип “Где? Что? Когда?”

Есть один полезный прием, который подходит для заголовков почти любых багов — это структура “Где? Что? Когда?”

• Где?: В каком месте находится проблема (предложение начинается с существительного, не с предлога)
• Что?: Что происходит или не происходит (согласно ТЗ или представлению о нормальной работе)
• Когда?: При каких условиях проявляется

Единообразное оформление заголовков по данной структуре поможет не только радоваться эстетике списка ваших багов, но и избегать заведения дубликатов.

Шаги воспроизведения проблемы

О важности шагов даже не стоит много писать — они несомненно самая важная часть баг-репорта.

Цель шагов в том, чтобы пройдя по ним, достигнуть фактического результата (именно такого, о котором вы докладываете в репорте и именно одного, а не нескольких).

Маршрут

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

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

Шаги  можно представить как точки маршрута.

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

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

Наклонение шагов

Шаги лучше всего описывать в одном наклонении, а именно в повелительном.

Это побуждает к конкретному действию и четче выглядит:

Ориентиры

В качестве ориентиров можно и нужно использовать скриншоты.

Если проблема на сайте, то можно сделать скриншот с открытой консолью, а также захватить адресную строку.

Не забудьте акцентировать внимание на проблемном месте:

Видно куда смотреть, открыта консоль с ошибкой, виден URL (разработчик часто первым делом видит скрин и по URL сразу понимает на какой странице проблема)

Ссылки и дополнительные данные в шагах

Тестовые данные для входа (если проблема актуальна, например, только для авторизованных) помогут быстрее воспроизвести ошибку.

По поводу ссылок в шагах есть разные мнения (ведь URL могут измениться и ссылка станет бесполезной), но бесспорно одно — актуальная ссылка под рукой упрощает жизнь и очень не хотелось бы совсем от нее отказываться.

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

Например: кликнуть по ссылке “Акция” (https://mysite.ru/offer) слева в верхнем углу страницы.

Ссылка на ТЗ

Кто помнит ТЗ наизусть? Наверное никто:)

Именно по этой причине указывая ожидаемый результат, который согласуется с техническим заданием, мы должны обосновать, на основании чего мы такой результат ожидаем.

Здесь же можно добавить и замечание про ложный след.

Если вы не уверены в причине проблемы, а уточнить ее совсем не у кого, то не нужно эту причину придумывать.

Например, мы знаем, что в разделе с 30% скидкой отображаются товары без скидки.

Но непонятно:

• в раздел попали не те товары (а это задача для того, кто наполняет базу контентом, например отдел контент маркетинга).
• или же товары там нужные, но причина в ошибке скрипта, который не рассчитывает скидку? (а это уже задача к разработчику).

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

Еще рекомендуем ссылаться на ТЗ в шагах.

Например, мы пишем:

“заполнить поле валидными данными”.

Мы сейчас подсмотрели в ТЗ и знаем, что такое валидные данные, а разработчик вряд ли об этом вспомнит и обязательно придет к вам (не очень довольный) за уточнениями.

Поэтому лучше написать: “Заполнить поле числом от 50 000 до 100 000 включительно (согласно ТЗ), например 52 000”

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

Генерализация

В кратце, генерализация дефекта — это процесс проверки различных условий, при которых проблема воспроизводится.

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

Пояснить можно на очень простом примере, представим, что мы поймали баг:

при вводе в поле промокод текста, содержащего пробелы, возникает ошибка 500.

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

Но разработчик то не знает, что еще мы проверили и хорошо, если спросит.

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

Еще, чтобы исполнитель понимал, что проблема шире и повторяется не только с указанными значениями, можно использовать в шагах конструкцию “Любыми.., например”.

Сравните:

«Ввести в поле «Сумма» 500″ (как будто проблема только с числом 500)

«Ввести в поле «Сумма» любые положительные числа, например 500″ (сразу понятно, что проблема с любыми числами)

Перечитать

Перед тем как сохранить баг-репорт перечитайте его, а потом

.. еще раз внимательно перечитайте.

Проверьте ошибки, проанализируйте понятность.

Во многих проектах прав на редактирование поставленных дефектов не выдают, поэтому нужно очень внимательно отнестись к их постановке.

Эксперимент

Вместо заключения, предлагаем провести эксперимент

1. Сохраните описание одного из своих багов в блокнот, этот файл положите подальше (чтобы не маячил на глазах);
2. Загляните туда через недельки две.

Если сможете сразу понять о чем речь и воспроизвести дефект, то поздравляем — баг заведен хорошо

(и сомневаемся, что доставит много радости искать ссылку, ТЗ, проверять какие данные валидны, а какие нет и еще кучу всего вспоминать).

Надеемся, данные советы помогут вам в работе!

До встречи в блоге «Лаборатории качества».

Тренер Первого Онлайн Института тестировщиков (ПОИНТ), Алена Балакина.

Узнать больше о программе и записаться на тренинг можно по ссылке http://pointschool.ru/

Обсудить в форуме

При тестировании возникает необходимость документирования найденных дефектов. Это позволяет исправить их в кратчайшие сроки.

Если кратко, то хороший баг-репорт позволяет:

• воспроизвести проблему;
• понять, в чем проблема, и какова ее важность.

Что такое баг, типы багов

По версии международной комиссии по сертификации тестирования программного обеспечения (ISTQB), баг(дефект) — изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Например, неверный оператор или определение данных может привести к отказам компонента или системы.

Критичность и приоритет бага. Атрибуты баг-репорта

Необходимо рассказать о приоритете и критичности бага. Важно понимать разницу между ними. Примеры приведу из личного опыта. Объектом тестирования в моей работе является ПО приёмников цифрового телевидения. Главной задачей ПО приёмника является расшифровка контента, передаваемого в зашифрованном виде. Для успешной расшифровки абонент должен приобрести у оператора подписку на соответствующий пакет телеканалов.

Критичность бага – это  атрибут, который характеризует влияние бага на общую функциональность разрабатываемого ПО.

По критичности баги делят на:

S1. Блокирующий (Blocker). Всё тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.

S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функционал, не связанный с расшифровыванием каналов.

S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.

S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести неточный перевод с русского на английский в меню приёмника.

S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.

Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:

P1. Высокий приоритет (High). Нужно исправить немедленно, потому что баг является крайне важным для всего релиза. Например, старое сообщение об отсутствии подписки на пакет, хотя обновление текстов являлось целью этого релиза.

P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.

P3. Низкий приоритет (Low). Нужно будет исправить, но баг не очень важный и не требует немедленного решения. Например, это могут быть баги в функционале, который уже не используется оператором, но ещё не был удалён из кода.

Что такое баг репорт, его типичная структура

Глоссарий ISTQB говорит, что баг репорт — это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.

Но можно сказать и проще: баг репорт (bug report) – это технический документ, который содержит в себе полное описание бага, включающее информацию как о самом баге (краткое описание, критичность, приоритет и т.д.), так и об условиях возникновения данного бага.

Состав баг репорта приведен в таблице:

Как правильно оформить баг-репорт

1. Для начала нужно убедиться, что найденный баг ещё не был оформлен. Следует провести поиск его в соответствующем проекте по всем подходящим ключевым словам иили полям. Если баг уже есть, следует обновить его описание.
2. Если баг не найден – нажимаем на кнопку создания бага. Не стоит забывать важное правило: один дефект — один баг в трекере.
3. Далее нужно постараться кратко описать, что не работает — это и будет заголовок баг-репорта.
4. После этого перейти к подробному описанию бага: указать шаги к воспроизведению.
5. Указать ожидаемый результат. Можно добавить ссылку на спецификацию.
6. Указать полученный результат.
7. Указать версию ПО, также указать версию окружения.
8. Если необходимо, приложить соответствующие артефакты: логи, скриншоты, дампы и т.д.

Ошибки при создании баг-репорта

Здесь перечислим проблемы, которые чаще всего встречаются при написании баг репорта.

Заголовок не понятен. Есть риск, что ни разработчик, ни коллеги не обратят внимания на довольно критичную проблему.

Отсутствуют шаги для воспроизведения. Есть риск, что разработчик, не поняв как повторить проблему, вернёт баг со статусом «Не воспроизводится».

Неправильно назначен баг. Возможно, баг по ошибке был назначен не на того разработчика или вообще остался в статусе “не назначен”. Есть риск, что багу долгое время не будет уделено внимание.

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

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

Жизненный цикл бага

Итак, баг найден, репорт составлен, что дальше? Дальше ведётся работа над багом в соответствии с жизненным циклом, который может быть настроен в системе багтрекинга. На практике это зависит от процессов в компании.

Если кратко, то после создания баг-репорта статус бага может выглядеть следующим образом:

• Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.
• Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
• Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
• Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
• Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
• Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
• Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
• Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
• Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен – он все так же потребует исправления, поэтому вновь открывается.
• Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Более наглядно жизненный цикл бага можно посмотреть на диаграмме:

При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать “save and create bug” и мы получаем почти готовый баг репорт в JIRA.

Нужно только добавить несколько полей связанных с текущим проектом.

В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

Вместо заключения

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

Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она не воспроизводится.

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

Профессия тестировщика ПО очень многогранна, ведь она требует внимания к деталям, креативности, коммуникативных навыков и усидчивости. Последнее качество особенно пригодится для такой части работы QA-инженера, как составление тестовой документации.

Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.

Баг-репорт содержит ответы на следующие вопросы:

• что идёт не так;
• где проявляется дефект;
• когда ошибка воспроизводится.

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

Разберёмся, как добиться этого сочетания.

Как выявляют баги?

Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:

1. во время проведения тестирования ПО;
2. при обращении заказчика с описанием ошибки;
3. из сообщений пользователей, которые столкнулись с проблемами во время использования программного продукта.

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

Какой инструмент используют для документирования дефектов?

Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.

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

Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.

Каких правил придерживаться при написании баг-репорта?

Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.

Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.

Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.

Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.

Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.

Если всё в порядке, можно переходить к описанию.

Из каких элементов состоит баг-репорт?

Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:

Summary (заголовок)

Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.

Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:

«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».

При тестировании мобильных приложений важно внести и название платформы, iOS или Android.

Заголовок готов. Можем двигаться дальше.

Description (описание)

Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:

1. переход на сайт menyaemsya.com;
2. вход или регистрация;
3. нажатие кнопки «Добавить объявление»;
4. ввод символов в поле «Описание».

Если же предстоит выполнить слишком большую последовательность действий, то вы можете начать с описания условий.

«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».

Actual/expected result (фактический/ожидаемый результат)

Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.

Пример заполнения данного раздела:

«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».

Attachments (вложения)

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

Priority (приоритет)

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

Системы определения важности могут отличаться, но скорее всего вы встретитесь с подобной градацией:

• P1 High (высокий приоритет);
• P2 Medium (средний приоритет);
• P3 Low (низкий приоритет);

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

Severity (серьёзность)

Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.

• Blocker — это статус для проблем, которые прерывают работу приложения.
• Critical — такой баг значительно влияет на работоспособность, но не приводит к блокировке.
• Major — ошибка, которая не способствует фундаментальным изменениям, но может привести к незначительным искажениям отображения информации или выполнения некоторых функций.
• Minor — не влияет на работу системы. К этой категории можно отнести ошибки в текстовых блоках или визуальных решениях.

Status (статус)

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

• New – новый баг;
• Feedback – требуется обратная связь;
• Acknowledged – с содержанием документа ознакомились;
• Accepted – ошибка воспроизвелась и была подтверждена;
• Assigned – исправление ошибки назначено;
• Resolved – изменения были внесены;
• Closed – дефект больше не воспроизводится.

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

• Environment/platform – среда, платформа или операционная система;
• Fix version – этап разработки ПО на момент выявления бага;
• Assignee – пользователь, которому предстоит утвердить или исправить дефект;
• Lable – категория ошибки (текст, визуальные элементы и прочее).

Резюмируем

Написание баг-репорта ― важный элемент QA-процесса, который позволяет ускорить устранение дефекта и подготовить качественное ПО к выходу на рынок. До начала написания документа важно:

• убедиться в воспроизводимости ошибки;
• оценить поведение системы на разных платформах (при необходимости);
• проверить дефект на уникальность в баг-трекинговой системе.

Хороший отчёт об ошибке написан простым и понятным языком, содержит максимум полезной информации. Ключевыми атрибутами баг-репорта являются заголовок, описание, приоритет и статус ошибки. Стоит придерживаться порядка написания отчёта и заполнять все поля в зависимости от особенностей трекинговой платформы и требований проекта.

Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!

Перед вами сейчас скриншот с багами. Что нужно сделать:
1. Найти баги,
2. Написать заголовок к баг-репорту, который необходимо оформить при нахождении бага.

Не нужно писать весь баг-репорт. Сейчас мы с вами оттачиваем только навык составления заголовков.

Напомню, что заголовок — это краткое описание найденной ошибки. Он должен в понятной и простой форме передать смысл найденной ошибки. Наиболее эффективным будет заголовок, который отвечает на три вопроса:
— Что произошло?
— Где появилась ошибка?
— Когда или при каких условиях найден дефект?

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

Итак, вы написали свои варианты. Теперь давайте посмотрим, какие же заголовки можно считать «хорошими», а какие «плохими». А смотреть мы будем на тех вариантах, которые нам присылали ученики под один из постов с практикой ВКонтакте (ссылка на нашу группу https://vk.com/zapiskisedogotestera).

«Хорошие» заголовки.

— «Верхняя панель: Значение младшего разряда счетчика монет смещено вниз относительно остальных.»

— «Срезан левый край иконки «Книга» на игровой панели слева»

— «Боковая панель: Срезан левый край иконки с книгой.»

— «Статуэтка «Викинг» расположена на воде.»

— «В режиме активной игры в поле «количество монет» третья (последняя?) цифра смещена вниз.»

— «в) окна кристаллов и энергии расположены поверх другого окна (предположительно окна щита и меча).»

Как я уже говорил, для нас не важно и количество багов, и правильность их определения. На эти моменты я не смотрел. Примеры заголовков выше написаны достаточно развернуты и понятно. Заголовки в большинстве случаев соответствуют принципу «Что? Где? Когда?».

Также понравилось, что у некоторых есть разделение на группы, это поможет структурировать ваш отчет.

«Плохие» заголовки.

Буду писать сам заголовок из ваших комментариев и чем он плох/что в нем стоит улучшить.

— «Неверное место положения персонажа».

В этом случае не совсем понятно о каком персонаже речь и где именно это неверное местоположение.

— «### -В верхнем меню
1. цифры пляшут
2. один блок заехал на задний план»

Здесь очень мало информации. По описанию непонятно в чем именно заключается «пляска» цифр и какие именно блоки заехали.

— «Кристаллы и викинг в правой части поля, возможно, не должны быть в воде.»

Тут основная проблема в том, что мы в один баг-репорт пытаемся занести сразу 2 бага: один про викинга, другой про кристаллы.

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

Вот еще немного примеров «плохих» заголовков:
— Съехала цифра в окне с золотом
— Слились вместе окна в правом верхнем углу экрана
— Отсутствует значение в окне с заданием
— Не ровное расположение цифр рамках сверху
— Одна из рамок сверху оказалась на заднем плане (кажется она вообще лишняя).
— В рамке со снежком не хватает числа.
— Обрезана рамка на значке с книгой.

***

Когда пишете заголовок, то всегда старайтесь смотреть на него с точки зрения другого человека. То есть достаточно ли вы хорошо описали баг, чтобы можно было быстро понять о чем речь. Но не забывайте, что заголовок должен быть кратким. Очень важен баланс.

А вот мои заголовки к тем багам, которые были запланированы:
1. Викинг с кабаном на основной карте стоит на воде.
2. Отсутствует правое значение счетчика у иконки «Снег» главного интерфейса.
3. Обрезана иконка «Книга» главного интерфейса.
4. Последняя цифра счетчика монет смещена вниз на главном интерфейсе.
5. Счетчик «Рабочие» заехал на счетчик «Армия» на главном интерфейсе.

Да, кто-то нашел баги, которые не подразумевались изначально багами. И это не удивительно, так как у нас не было ни ТЗ, ни живого доступа к функционалу. Повторю, что это никак не влияет на выполнение задания. Ведь наша цель была составить заголовки к баг-репортам. А уж баг это или нет в нашем случае роли не играет.

Баг-репорт — это отчет об ошибке. В нём указывают, что нужно исправить в программном обеспечении или на сайте. Перечисляют причины и факты, почему поведение считают ошибочным.

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

Почему важно сообщать об ошибках и кто это делает

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

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

Тестировщиком реально стать даже без опыта в IT. Для этого пройдите курс Skypro «Инженер по тестированию». Научитесь писать тестовую документацию и составлять отчеты, тестировать веб- и мобильные приложения и API, освоите нужные инструменты. Внутри — мастер-классы с реальными рабочими задачами, домашки и разборы от наставника. Создадите четыре проекта для портфолио и получите диплом гособразца.

Основные принципы

Правильные отчеты помогают программистам быстрее исправлять ошибки. Детали зависят от типа багов. Но есть несколько основных принципов — что и как включать в баг-репорт, чтобы заранее снять вопросы разработчиков.

Указывайте:

1️⃣ Только одну ошибку на отчет. Это золотое правило, потому что так гораздо проще исправлять баги. Легче отслеживать статус отдельных отчетов и выставлять приоритеты задач, распределять работу между несколькими разработчиками. Да и меньшее количество информации проще запомнить и проанализировать.

2️⃣ Место интерфейса программного обеспечения, в котором возникла ошибка. Опишите экран, на котором находитесь, состояние интерфейса. Включите URL-адрес страницы, если это веб-приложение.

3️⃣ Действия в программе. Пошагово опишите действия, которые выполняли перед тем, как столкнулись с ошибкой. Это важно: может оказаться, что некорректное поведение программы началось до того, как вы его заметили.

4️⃣ Ожидания. Поведение программы может быть некорректным с точки зрения общей логики или вашего личного опыта — указывайте не только очевидные отказы выполнения и неверные результаты вычислений. Программы создают, чтобы облегчить пользователям жизнь, а не заставлять их подстраиваться под готовый результат.

5️⃣ Скриншот или запись экрана с ошибкой. Есть риск ошибиться, когда пишешь отчет об ошибке. Это значительно усложнит работу команды разработки. Визуальные материалы — более точный способ указать на проблему, чем просто описать ее.

6️⃣ Техническую информацию. То есть вашу операционную систему, браузер, тип устройства — персональный компьютер, мобильный телефон или планшет. А еще тип устройства ввода — клавиатуру, мышь, сенсорный экран и прочее. Будут полезны и параметры монитора, чтобы исправить ошибки в отображении пользовательского интерфейса.

7️⃣ Все сообщения об ошибках и коды. Они помогут определить, что это за ошибка и как ее устранить. Показывайте и те сообщения, которые кажутся нерелевантными. Даже они могут помочь разобраться в проблеме.

8️⃣ Можете ли вы воспроизвести проблему. То есть происходит ли одно и то же каждый раз, когда вы пытаетесь выполнить задачу. Эта информация поможет разработчику найти причину ошибки.

9️⃣ Пробовали ли исправить проблему. Есть причина, по которой айтишник всегда спрашивает: «Вы пробовали выключить и снова включить?» или «Пытались ли обновить веб-страницу?». Перезагрузка может быть простым способом исправить проблему. Если она не исчезает — это дает много информации. Укажите, и это сэкономит время на последующее обсуждение проблемы.

🔟 Насколько проблема влияет на работу. Обычно серьезность варьируется от очень высокой (полностью останавливает работу) до очень низкой (визуальные недочеты). Эта информация поможет командам разработчиков расставить приоритеты, определить порядок, в котором устранять ошибки.

Основные элементы

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

Обычно программисты и тестировщики договариваются, что и как указывать. Еще на это влияет система, в которой готовят отчет. Но есть общие компоненты баг-репорта:

👉 Резюме — краткое обозначение проблемы, причина и тип ошибки.

👉 Описание — подробности и любые сведения, которые помогут локализовать и исправить ошибку.

👉 Вложения — любые визуальные или другие материалы.

👉 Срок выполнения — если важно, чтобы ошибку исправили к определенной дате.

👉 Критичность — комментарий, насколько баг мешает нормальной работе приложения.

Часто выделяют следующие уровни критичности ошибок:

☝ Блокирующий (Blocker) — полностью блокирует нормальную работу программы, нужно исправить как можно быстрее.

☝ Критический (Critical) — сильно искажает логику приложения и значительно осложняет работу с ним.

☝ Значительный (Major) — затрагивает только отдельные элементы программы, существенно мешает работать.

☝ Незначительный (Minor) — либо не сильно влияет на работу программы, либо проявляется редко.

☝ Тривиальный (Trivial) — относится к визуальным недочетам в интерфейсе: опечатки, неудобные цвета и прочее.

Жизненный цикл

Порядок работы тоже зависит от соглашений в команде, системы управления. Но выделяют общие статусы отчета, которые встречаются практически везде:

💡 Новый — только создан, ждет проверки разработчиком.

💡 Принят — отчет проверили, проблему подтвердили.

💡 Отклонен — отчет проверили, но команда разработки отказалась работать по нему. Например, потому что ошибку не удалось повторить. Или то, что показалось ошибкой, — нормальное поведение программы. Или проблему уже устранили, когда работали над другим отчетом.

💡 Назначен — ошибку передали исполнителю.

💡 В работе — разработчик исправляет ошибку.

💡 Проверяется — исполнитель закончил работу, результат проверяет старший специалист.

💡 Закрыт — ошибку исправили, результат доступен пользователям.

Системы для отчетов об ошибках

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

Такие программы называют баг-трекерами. Чаще всего они — часть более сложных систем: управления проектами или исходным кодом приложения.

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

К наиболее распространенным системам управления проектами относят:

• Jira.
• YouTrack.
• Redmine.

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

К основным системам управления исходным кодом относят:

• GitHub.
• GitLab.
• Bitbucket.

Интерфейсы и функции систем довольно сильно отличаются, но для работы с отчетами все предоставляют базовый набор функций:

✔️ форма создания отчета об ошибке с полями для ввода основных элементов;

✔️ управление состоянием и параметрами;

✔️ форма обсуждения, в которой команда задает вопросы и оставляет комментарии, указывает дополнительные детали;

✔️ уведомление об изменениях через имейл или другую систему обмена сообщениями.

У части баг-трекеров есть публичное голосование. Пользователи голосуют за или против бага: так повышают или понижают его приоритет.

Главное

• Баг-репорт — специальный вид отчета о неисправности в программном обеспечении или веб-сайте. Баг-репорт готовят тестировщики или специалисты из команды по контролю качества.
• Оформление баг-репорта сильно влияет на скорость, с которой исправят ошибки, на итоговый результат. Указывайте причину и тип ошибки, подробности, срок выполнения, критичность. Прикладывайте скриншоты или запись экрана.
• Прописывайте, пробовали ли исправить проблему, насколько она влияет на работу. Указывайте операционную систему, браузер, тип устройства, параметры монитора.
• Есть системы, с которыми проще создавать баг-репорты и управлять ими. Основные: Jira, YouTrack, Redmine, GitHub, GitLab, Bitbucket.