Правила составления репортов

[alxxndrv]

Дубликаты

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

Пожелания

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

Перейдем к самому важному: отчетам и их полям.

Заголовок

В заголовке необходимо одним предложением передать суть найденного бага или пожелания. Краткая выжимка, по которой разработчик и каждый из команды сможет понять, в чем дело.
Хороший заголовок: «Возможность создать несколько списков, названных одинаково».
Плохой заголовок: «Баг в списках». Избегайте неопределенности. Разработчик при не информативном заголовке потратит много времени, чтобы открыть отчет, и уже по описанию понять, о чем речь.
Будьте внимательны к опечаткам в заголовке. Они затрудняют поиск и провоцируют других тестировщиков на ненужную работу. Проверяйте заголовок перед публикацией отчета.

Описание

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

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

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

Предварительные условия (preconditions)

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

Шаги воспроизведения.

Должны быть равновесными, необходимыми и достаточными для воспроизведения проблемы.

Например:

1. Запустить приложение.
2. Перейти на вкладку «Хаб» в таббаре
3. Тап по архиву

Фактический результат (то, что наблюдаем после выполнения последнего шага):
Отсутствует кнопка «Назад»
Ожидаемый результат:
Кнопка «Назад» присутствует, работает свайп назад

Согласно теории тестирования, баг - это отклонение фактического результата от ожидаемого.

Откуда берется ожидаемый результат:

1. Спецификация,
2. Гайдлайны платформы,
3. Здравый смысл,
4. Профессиональный опыт,
5. Отраслевые стандарты,
6. Статистические данные, авторитетное мнение и др.

Вложения

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

Скриншоты

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

Видео воспроизведения

Иногда скриншотов не хватает: например, для иллюстрирования багов навигации, анимаций и прочих других. Тогда следует приложить видеофайл записи с экрана. Для записи видео с экрана существует встроенная в iOS функция «Запись экрана»