- Marinka Shevchenko
Как использовать 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)
Не обязательное для заполнения поле. Здесь можно указывать ссылки на файлы требуемые для воспроизведения бага или лучшего понимания проблемы. Например, если в приложение можно загружать изображения, и есть конкретный файл вызывающий неправильное поведение - можно указать ссылку на него здесь.
автор
Олександр Іщенко