Отчет об ошибках тестирование пример

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

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

Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
1. Заголовок ошибки
2. Описание ошибки
3. Начальные условия
4. Шаги воспроизведения
5. Ожидаемый результат
6. Фактический результат
7. Вложения

В зависимости от ситуации или компании, в которой вы работаете, шаблон может изменяться и отклоняться в разные стороны. Например, в некоторых случаях «Начальные условия» не пишут. Если дефект связан с графикой, то рекомендуется добавить скриншот. Также вводятся дополнительные атрибуты для указания Платформы или Барузера и т.д.

Теперь рассмотрим структуру шаблона подробно на конкретном примере. Допустим, мы тестируем сайт. На сайт есть раздел Контакты. В этом разделе находится Форма обратной связи.

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

Данный баг мы и будем описывать по шаблону.

Заголовок ошибки (Title)

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

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

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

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

Пример плохого заголовка: Ошибка, когда нажимаю «Отправить сообщение».
Пример хорошего заголовка: При нажатии на кнопку «Отправить сообщение» в форме обратной связи сообщение не отправляется.

Описание ошибки (Summary)

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

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

Пример плохого описания: Жму «Отправить сообщение», а в ответ тишина.
Пример хорошего описания: При нажатии на кнопку «Отправить сообщение» в заполненной форме обратной связи ничего не происходит. Аналогичное поведение, если форма не заполнена.

Начальные условия (Precondition)

В случае, если есть специфичные действия или шаги воспроизведения достаточно объемные, то указываются начальные условия. Например:
1. Быть авторизованным в системе.
2. Находиться на главной странице.

Пример плохих начальных условий: Находиться на сайте.
Пример хороших начальных условий:
1. Страница «Контакты»,
2. Платформа и устройство не имеют значения.

Шаги воспроизведения (Steps To Reproduce)

Шаги, при которых повторяется найденная ошибка. Например:
1. Нажать на кнопку “Войти”
2. Ввести “Имя пользователя” и “Пароль”
3. Нажать на кнопку “Ок”

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

Пример плохих шагов: 1. Зайти на сайт, 2. Зайти на страницу обратной связи, 3. Поставить курсор в поле Имя, 4. Ввести имя, 5. Поставить курсор в поле e-mail, 6. Ввести действующий e-mail, 7. Навести курсор на Отправить сообщение, 8. Щелкнуть по Отправить сообщение.
Пример хороших шагов:
1. Заполнить поля формы обратной связи,
2. Нажать на копку «Отправить сообщение»

Ожидаемый результат (Expected Result)

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

Пример плохого ожидаемого результата: Что-то должно произойти.
Пример хорошего ожидаемого результата: Сообщение отправляется либо система сообщает о невозможности его отправки.

Фактический результат (Actual Result)

Указывается результат, который получил тестировщик при выполнении описанных шагов. Также может отвечать на три вопроса “Что? Где? Когда?”.

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

Вложения (Attachments)

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

________________________________
При соблюдении правил оформления баг-репортов, ваша работа станет более эффективной.
________________________________

В следующей статье мы разберем такие атрибуты баг-репорта, как Приоритет и Серьезность дефекта.

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

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

Каналы поступления багов

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

• В процессе тестирования — функционального и нефункционального.
• Обращение клиента (заказчика) с информацией о возникшей проблеме.
• Баги, выявленные пользователями. Соответствующая информация может быть передана как разработчикам, так и заказчику.
• Ошибки полученные при помощи систем мониторинга, например Sentry, Errbit, Crashlytics.

Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.

Направления работы отдела QA

С каналами поступления информации о багах мы определились. Теперь перейдем к направлениям работы QA инженеров. Их несколько:

• Веб-приложения;
• Мобильные приложения (iOS и Android);
• API (как часть мобильного или веб-приложения или или же в качестве самостоятельного проекта);

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

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

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

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

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

Чего делать нельзя? Нельзя информировать сразу о нескольких проблемах в пределах одного баг репорта. Закон джунглей: один bug report = одна проблема. Не ленитесь.

Чем плох баг репорт с несколькими проблемами в пределах одной задачи? Это значительно замедляет процесс их устранения. Следите за руками: после починки дефекта разработчик переназначает задачу на QA специалиста для проверки. Если мы имеем несколько проблем в одной задаче – разработчик не сможет отдать их на проверку, пока не устранит каждую из них. Чувствуете как утекает время? Когда же все баги упакованы в отдельную задачу, QA специалист может приступить к проверке исправлений значительно раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и программное обеспечение быстрее продвигается к релизу.

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

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

К слову, баг репорт состоит не только из описания. Любое сообщение о дефекте включает в себя два элемента:

• заголовок;
• описание.

Рассмотрим каждый из них в отдельности.

Заголовок

При составлении заголовка мы используем золотое правило: “Что? Где? При каких условиях?”. Заголовок — это первое, что увидят разработчики, менеджер проекта или ваши коллеги — QA специалисты. Сделав его максимально простым, точным и понятным, вы сразу же зададите верное направление. Итак, заголовок отчета об ошибке должен:

• Содержать предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о баге;
• Ответить на три вопроса: Что? Где? И при каких условиях? (или хотя бы на те 1-2 вопроса, которые применимы к конкретной ситуации);
• Быть достаточно коротким, чтобы полностью помещаться на экране (имеются в виду баг-трекинговые системы, где заголовок обрезается или приводит к необходимости скроллинга);
• Содержать информацию об окружении, под которым был обнаружен баг (в зависимости от типа проекта);
• Быть законченным предложением русского или английского языка, построенным в соответствии с правилами грамматики.

Давайте рассмотрим работу с заголовком на простом примере:

1. Ситуация: поле описания товара в веб-приложении должно допускать ввод максимум 250 символов. В процессе тестирования выяснилось, что необходимое ограничение отсутствует (вводится хоть миллион символов).
2. Суть проблемы: исследование показало, что ни на клиентской, ни на серверной стороне нет никаких механизмов, проверяющих и/или ограничивающих количество символов, вводимых в поле описания товара.
3. Используем золотое правило. Что: отсутствует проверка и ограничение длины вводимого текста. Где: поле описания товара. При каких условиях: при любых, то есть — всегда.
4. Формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле описания товара.
5. Сокращение (итоговое summary): Нет ограничения максимальной длины поля «Описание».
6. Англоязычный вариант: No check for max length of Description field.

Небольшой комментарий к информации об окружении и проектных традициях. Приведем простой пример. Мы имеем дело с проектом, в пределах которого разрабатывается мобильное приложение под две платформы: iOS и Android. В зависимости от того, к какой платформе привязан баг, в заголовке указываем: iOS или Android. Например, “iOS. Application accepts dates of birth from the future.”.

Дополнительный вариант — использование так называемых ярлыков (labels). Некоторые системы отслеживания ошибок предоставляют соответствующий функционал.

Описание

Переходим ко второму компоненту bug report. Описание должно содержать следующую информацию:

1. Подготовительные операции, то есть действия, обеспечивающие возможность воспроизведения проблемы.
2. Шаги воспроизведения. Сразу заметим: везде нужна золотая середина. Категорически запрещается пропускать важные шаги. Но в то же время не следует разжевывать очевидные вещи. Например, вставлять скриншоты в каждый отчет об ошибке совершенно не обязательно. Не плодите лишние сущности. Если они ничем не помогут в воспроизведении проблемы — не тратьте время на их изготовление.
3. Актуальный результат.
4. Ожидаемый результат.
5. Дополнительная информация: различного рода уточнения, логины, пароли и прочее. Все, что может понадобиться в процессе воспроизведения проблемы.
6. Уровень проблемы. Чаще всего используются следующие уровни (это не панацея, в зависимости от традиций компании или типа используемой системы отслеживания багов, названия уровней могут меняться):

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

При работе с Pivotal Tracker мы привыкли маркировать уровни проблемы цифровым значением от 1 до 4, это значение указывается в качестве label. По уровням градация следующая: 1 — это Blocker и Critical, 2 — это Major, 3 — это Minor и 4 — это Trivial. Такая градация уровня проблемы используется на всех проектах, которые ведутся в Pivotal Tracker.

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

• Подготовительные операции. Самый простой пример: авторизация перед совершением каких-либо действий в панели управления.
• Шаги воспроизведения проблемы. Последовательность действий, приводящих к возникновению (проявлению) дефекта. Шаги могут сопровождаться скриншотами или видео. Однако наличия набора медиафайлов недостаточно. Текстовое описание шагов должно присутствовать всегда и в обязательном порядке.
• Актуальный результат — ошибка или поведение ПО, не соответствующее описанию в спецификации проекта.
• Ожидаемый результат — описание типового поведения ПО, без ошибки и соответствующего описанию в спецификации проекта.
• Информация об окружении, если она необходима для воспроизведения бага (версия приложения и/или браузера, операционная система, разрешение экрана, логин и пароль, примеры файлов, локализация)
• Уровень проблемы (minor, major, critical или blocker).

Примеры

Пример #1

Один из баг репортов для мобильного приложения. Проект ведется в Pivotal Tracker. Уровню проблемы присваивается значение в диапазоне от 1 до 4, где наиболее важные моменты — это “1” и далее по убыванию. Приложение разрабатывалось сразу под две платформы — Android и iOS. Поэтому мы решили прописывать платформу в заголовок задачи.

Переходим к составляющим баг репорта:

Заголовок — Android. About Track screen. Nothing happens after tap on the Label. Как было сказано выше, мы указываем платформу, тем самым  отвечая на вопрос “где?”. То есть: на платформе Android, на экране About Track. Далее мы отвечаем на вопросы “что?” и “когда?” — Nothing happens after tap on the Label.

Так как отдельных полей о тестовом окружении в Pivotal Tracker не предусмотрено, мы добавляем информацию о билде (Build v2.0.6) и версии Android, на которой был воспроизведен баг (Android 6.0), в поле Description.

В этом же поле прописываем шаги воспроизведения бага:

1. Open a track with related Label (as the example EDX — My Friend Extended Mix)
2. Tap on the Info icon (top right corner)
3. Tap on the Label name, nothing happens

И ожидаемый результат: Expected behaviour: Label screen should be opened.

Кроме того, к задаче были прикреплены скриншоты экрана About Track с явным указанием проблемной надписи. При нажатии на нее ожидался переход на другой экран.

Пример #2

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

Кликните на изображение для увеличения

Проект также велся в Pivotal Tracker, поэтому уровень проблемы был указан с помощью label. Использовалась аналогичная шкала (от 1 до 4). Мы присвоили проблеме уровень “2”, так как отсутствие данной в ответе метода не позволяло выполнить некоторые операции в профиле пользователя.

Итак, заголовок — The method «View User Profile» should return information about user’s location. Мы совершенно отчетливо указываем на метод и проблему. Далее в поле Description мы даем понять, что речь идет о стейджинге.

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

     Email:
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript

     Password: qwerty

     Token: xVjowqgm-FHjNwB9tAbG

Описываем проблему и добавляем техническую информацию: пример вызова метода при помощи curl и текущий ответ.

Наконец, указываем что мы ожидали увидеть в ответе недостающие атрибуты.

Expected attributes:

• Location name (location_name)
• location ID (location_id)
• location type (location_type).

Выводы

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

Что еще важно отметить? На сегодняшний день существует масса систем для автоматического сбора информации об ошибках. Например, Errbit для веб или Crashlitics для мобильных приложений. Они могут быть интегрированы с вашей системой отслеживания ошибок и передавать все технические подробности проблемы. Однако автоматически созданные задачи должны тщательно исследоваться тестировщиком для определения и добавления шагов воспроизведения проблемы. Лишь после этого задача передается разработчикам.

Использование общих шаблонов и практик дизайна отчетов об ошибках в пределах компании позволяет существенно сократить время коммуникации между разработчиками и QA специалистами. Дело в том, что согласование задач (то есть случаи, когда разработчики возвращают тестировщикам задачи со статусами rejected, can’t reproduce, more info) зачастую существенно затягивается. Соблюдение же правил написания bug reports позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.

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

Шаблон отчета о дефектах или Шаблон отчета об ошибках – это один из тестовых артефактов. Это проявляется, когда начинается этап выполнения теста.

Ранее я публиковал подробный пост «Жизненный цикл тестирования программного обеспечения (STLC)», если вы еще не прошли его, вы можете просмотреть “ Жизненный цикл тестирования программного обеспечения (STLC)» здесь

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

Посмотрите разницу между ошибкой, ошибкой, дефектом и сбоем здесь

Посмотрите видео ниже, чтобы увидеть «Как написать хороший отчет об ошибке с четким объяснением каждого поля»

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

Если вам понравилось это видео, подпишитесь на наш канал YouTube для получения дополнительных видеоуроков.

Шаблон отчета об ошибке — подробное объяснение

Компоненты шаблона отчета об ошибке

< p>Давайте обсудим основные поля отчета о дефекте, а в следующем посте мы узнаем, как написать хороший отчет об ошибке.

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

Заголовок/Резюме: Заголовок должен быть коротким и простым. Он должен содержать конкретные термины, относящиеся к актуальной проблеме. Будьте точны при написании заголовка.

Предположим, вы обнаружили ошибку на странице регистрации при загрузке изображения профиля, которое также относится к определенному формату файла (например, файлу JPEG). Сбой системы при загрузке файла JPEG.

Примечание. Я использую этот пример в этом посте.

Хорошо: «Загрузка файла JPEG (изображения профиля) в Страница приводит к сбою системы».

Плохо: «Системный сбой».

Имя репортера: Имя того, кто обнаружил дефект ( Обычно это имя тестировщика, но иногда это может быть разработчик, бизнес-аналитик, эксперт в предметной области (SME), клиент)

Дата сообщения о дефекте: укажите дату, когда вы обнаружили ошибку.

Кто обнаружил: укажите имя того, кто обнаружил дефект. Например. QA, разработчик, бизнес-аналитик, малый и средний бизнес, клиент

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

Название проекта: иногда мы можем работать над несколькими проектами одновременно. Итак, правильно выбирайте название проекта. Укажите название проекта (если это продукт, укажите название продукта)

Выпуск/версия сборки: в каком выпуске возникает эта проблема. Четко укажите сведения о версии сборки.

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

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

Пример: Windows 8/Chrome 48.0.2564.103

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

Категории приоритета:

• Высокий
• Средний
• Низкий

Подробнее о приоритете и серьезности ошибки.

< strong>Серьезность: Серьезность говорит о влиянии ошибки на бизнес клиента. Обычно степень серьезности ошибки устанавливается менеджерами. Иногда серьезность ошибки выбирают тестировщики, но в большинстве случаев ее выбирают менеджеры/руководители.

Категории серьезности:

• Блокировщик
• Критический
• Основной
• Незначительный
• Незначительный

Статус: укажите статус ошибки. Если вы только что нашли ошибку и собираетесь опубликовать ее, статус будет «Новая». В ходе исправления статус ошибки будет меняться.

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

Обязательно к прочтению : Жизненный цикл ошибки — подробное объяснение

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

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

Хорошо:

< р><эм>я. Открыть URL «Ваш URL»
ii. Нажмите «Страница регистрации»
iii. Загрузить файл «JPEG» в поле фотографии профиля

Плохо:

Загрузите файл на странице регистрации.

URL: укажите URL-адрес приложения (если доступно)

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

Хорошо: должно отображаться сообщение «Изображение профиля успешно загружено»

Плохо: система должна принять изображение профиля.

Ранее я публиковал подробный пост «Шаблон тестового сценария с объяснением». Если вы еще не ознакомились с ним, вы можете просмотреть «Шаблон тестового сценария с пояснением» здесь.

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

Хорошо: “Загрузка файла JPEG (изображения профиля) в Страница регистрации приводит к сбою системы».

Плохо: система не принимает изображение профиля.

Вложения

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

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

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

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

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

Тестировщиком реально стать даже без опыта в 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.