Defect

Баг репорт – это технический документ и в связи с этим, язык описания проблемы должен быть техническим. Должна использоваться правильная терминология при использовании названий элементов пользовательского интерфейса (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray и т.д.), действий пользователя (click link, press the button, select menu item и т.д.) и полученных результатах (window is opened, error message is displayed, system crashed и т.д.).

Зачем хорошо описывать дефект?

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

Анализ, найденного дефекта:

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

Хороший отчет о дефекте должен удовлетворять следующим требованиям:

Простота

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

Объективность

Не указывать на виновника.
Работа тестировщика – предоставить объективные данные для принятия верных решений.

Нейтральность

Не вкладывайте эмоции в описание дефекта.
Не пользуйтесь формулировками юмористического или саркастического характера.
Излагайте суть дефекта ясным и деловым языком.

Однозначность (Использование нечётких или неоднозначных формулировок)

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

Составляющие описание дефекта

При описании дефекта важно указать следующие данные:

Краткое описание дефекта (Summary, Title)
Серьезность дефекта (Severity)
Подробное описание (Description)

Краткое (в одну строку) описание проблемы (Summary) – очень важная часть описания дефекта.

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

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

Приложение зависает, при попытке сохранения текстового файла размером больше 50Мб.
Данные на форме “Профайл” не сохраняются после нажатия кнопки “Сохранить”.

Оно должно включать :

Краткое, но достаточно точное описание, позволяющее понять суть дефекта.
Краткое указание на область и условия проявления дефекта (насколько проявление дефекта зависит от условий выполнения программы).
Указание на серьезность дефекта (помогающее представить последствия его наличия в продукте).

Удобнее всего Title формировать исходя из принципа: Где-Что-Когда

Где?: В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема. Причем, начинайте предложение с существительного, а не предлога.
Что?: Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.
Когда?: В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

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

Description – Детальное описание проблемы

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

Состоит из:

Шаги воспроизведения (Steps to Reproduce)
Результат (Actual Result)
Ожидаемый результат (Expected Result)
Окружения (Environment)

Шаги к воспроизведению

Очень важно четко описать все шаги, с упоминаем всех вводимых данных (имени пользователя, данных для заполнения формы) и промежуточных результатов.
Если ошибка трудновоспроизводима (требует специальных условий – специфических входных данных, предварительных действий, напрямую не связанных с этой ошибкой т.п.), то четко опишите эти условия.
Сложносочинённые и сложноподчинённые предложения, причастные и деепричастные обороты осложняют восприятие текста. Чем проще будет построено предложение, тем лучше.
Сократить очевидное:
- Плохо – «Найти ярлык приложения на рабочем столе, кликнуть по нему 2 раза левой кнопкой мыши».
- Хорошо – «Открыть приложение по ярлыку».

Воспроизводимость дефекта

После первого нахождения дефекта, надо еще раз повторить те же действия, что привели к появлению ошибки.
Если ошибка воспроизводится – можно указывать в баг репорте:
Воспроизведение – 100% (но необязательно).
Если же ошибка воспроизводится не всегда – надо указать либо количество попыток и количество воспроизведений (например 3 из 5), либо процентное соотношение воспроизведений “на глаз”, например воспроизмедение – 80%. Так же, в этом случае, лучше указать время воспроизведения ошибки.

Окружения (Environment)

Веб приложение:

линк, на котором воспроизводилась ошибка (например – test.qax.com.ua)
только главная версия Операционной Системы (например W10) или чаще, не указывается совсем
полная версия браузера
если известна версия приложения/билда
если необходимо – разрешение экрана

Десктопное приложение:

полная версия Операционной Системы
версия приложения/билда
если необходимо – разрешение экрана

Мобильное приложение (Нативное):

модель устройства
полная версия Операционной Системы
если необходимо – разрешение экрана
если необходимо – ориентация экрана (портретная / ландшафтная)
если необходимо – физический размер экрана
если необходимо – соотношение сторон экрана

Мобильное приложение (Веб):

модель устройства
полная версия Операционной Системы
полная версия браузера
если необходимо – разрешение экрана
если необходимо – ориентация экрана (портретная / ландшафтная)
если необходимо – физический размер экрана
если необходимо – соотношение сторон экрана

Пример:

Шаги к воспроизведению
1. Войдите в системы: Пользователь “Тестер1”, пароль “xxxXXX”
— Вход в систему осуществлен
2. Кликните линк “Профайл”
— Страница Профайл открылась
3. Введите Новое имя пользователя: “Тестер2”
4. Нажмите кнопку “Сохранить”

Результат
– На экране появилась ошибка.
– Новое имя пользователя не было сохранено

Ожидаемый результат
– Страница профайл перегрузилась.
– Новое значение имени пользователя сохранено.

Т.е. если необходимо описать сложный сценарий можем отделять “действия” от “состояний” (“действия” имеют порядковый номер, “состояния” – нет)

пример 2:

Desktop/W10/Google Chrome 89.0.4389.128 (64 bit)
Desktop/W10/Firefox 87.0 (64 bit)

Серьезность (Severity)

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

Определяется QA специалистом, Lead QA или Team Lead после анализа требований, программного продукта и специфики конкретной проблемы:

Blocker — дефект относится к критичной (с точки зрения работоспособности) функциональности или критичным данным. У пользователя нет возможности выполнить целевое действие другими способами.

Примеры:
— Нет возможности залогиниться, зарегистрироваться;
— Нет возможности получить доступ как целевым данным, целевым разделам приложения;
— Происходит краш приложения на конкретном окружении.

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

Примеры:
— Падения (crash) приложения;
— Исключения (exeptions) в процессе работы с приложением;
— Не работоспособность функционала на одном из доступных пользователю окружениях;
— Несанкционированный доступ к данным/функциональности.

Major — дефект относится к не приоритетной (с точки зрения работоспособности) функциональности или не приоритетным данным. Есть очевидный и простой обходной путь выполнения целевой функциональности.

Примеры:
— Дефекты имеющие вероятностный характер возникновения;
— Исключения (exceptions) не влияющие на результат выполнения целевого действия;
— Проблемы, влияющие на скорость использования приложения и продуктивность целевых действий пользователя;
— Визуальные несоответствия;
— Ошибки важного (например, продающего) контента и/или графической информации.

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

Пример:
— Небольшие расхождения верстки с макетами;
— Орфографические ошибки в не приоритетном контенте;
— Несущественые улучшения UI, UX.

В данной методике рассматривается 4-уровневая модель Severity. В зависимости от специфики вашего проекта или процессов, могут быть использованы альтернативные модели. Например, данную модель Severity можно расширить такими уровнями градации, как average (normal) и minor.

Приоритет (Priority)

Определяется менеджером (PM/PO) проекта на основании влияния проблемы на бизнес задачи/цели программного продукта:

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

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

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

Порядок заполнения баг репорта

Баг репорт имеет смысл заполнять в следующем порядке:

Description
Title
Severity

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

С какого места начинать описывать ошибку?

Начните описание с известного места (например, с запуска программы или открытия входного документа). Т.е. с того места, которое известно и понятно всем.

Защита дефекта

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

Скриншоты

ShareX

Цвет выделения

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

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

Если хотим акцентировать внимание, можно использовать стрелки

Используем коллажи

Удобно использовать разные цвета для ожидаемого и актуального поведения (например зеленый и красный)

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

Если проблема с линкой (удобно делать скрин, на котором она указана):

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

Если вы тестируете веб приложение, удобно захватывать и URL, в этом случае не будет вопросов, с подтверждением, где находился баг:

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