Search
  • 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)

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



автор

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

293 views

2015 - 2018  © All Rights Reserved

  • Black Facebook Icon
  • Black LinkedIn Icon