Как использовать Template Bug Report на тестатоне

Перед началом Тестатона каждой из команд будет отправлена ссылка на Google Sheets документ и открыт доступ для его редактирования.

Именно в этой таблице участникам Test UA Startups предстоит описывать найденные баги и предлагать возможные улучшения тестируемого приложения. Рекомендуемым языком является английский.

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

Структура

Таблица содержит такие колонки:

• Issue type

• Severity

• Summary

• Environment

• Description

• Functional Area / Component

• Reporter

• Screenshot (link)

• Crash report (link)

• Other files (link)

Ниже рассмотрим каждое из полей детальнее.

Issue type

Доступны два значения: 

• Bug (a problem/defect which impairs or prevents the functions of the product)

• Improvement (an enhancement to an existing feature)

Уверены, всем участникам хорошо знакомы значения этих двух слов :)

Severity

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

Доступные значения поля:

• Blocker (blocks development and/or testing process)

• Critical (crashes, loss of data, severe memory leak etc.)

• Major (major loss of function)

• Minor (minor loss of function, or other problem where easy workaround is present)

• Trivial (cosmetic problem like misspelled words or misaligned text)

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

Summary

В этом поле предполагается краткое описание найденного бага или сути предлагаемого улучшения существующего функционала. 

     Часто можно встретить рекомендацию использовать формулу “What+When+Where” при написании Summary, но каждый участник может исходить из своего опыта и использовать другой стиль. 

     Основная цель - Summary должно быть лаконичным и понятным, передавать суть.

Например:

Error 500 after clicking “Sign in with Google” button on “Authorization” page

Environment

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

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

• название мобильного устройства

• операционная система

• браузер и его версия

• версия/билд мобильного приложения

Description

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

Это основная часть бага или improvement-а. Должна содержать подробное описание и раскрывать все детали.

Ожидаемая структура при описании бага:

• Preconditions (если это требуется)

• Steps (с достаточной для знакомого с приложением человека детализацией)

• Actual result

• Expected result

Например (баг):

При описании improvement может быть использована любая структура и стиль описания. Основная цель остается прежней - должна быть понятна суть.

Functional Area / Component

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

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

Reporter

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

Screenshot (link)

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

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

Crashreport (link)

Поле актуально в основном для мобильных платформ. Сюда могут быть приложены ссылки на файлы с логами приложения в момент крэша.

Other files (link)

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

автор

Олександр Іщенко