Баг(дефект) - изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Баг репорт(отчёт о дефекте) - это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Баг-репорт состоит из нескольких частей: обязательных и опциональных.
К обязательным частям относят:
- Заголовок баг-репорта;
- ID баг-репорта (необходим для однозначной идентификации баг-репорта, проставляется баг-трекинговой системой автоматически);
- Шаги воспроизведения;
- Ожидаемый и фактический результаты;
- Серьезность (данная часть выделяется не всеми авторами как обязательная).
Итак, давайте представим, что на сайте мы нашли следующий дефект: мы можем ввести в поле почты на форме регистрации абсолютно любые символы.
Сразу скажу о правилах, которые работают для всех частей баг-репорта:
- Каждая часть баг-репорта должна быть однозначна и выполнять только свою функцию (то есть, например, в результатах не должны дублироваться шаги воспроизведения, в заголовке не дублируется окружение и так далее);
- Один баг-репорт = один дефект;
- Все части баг-репорта должны быть максимально кратки с сохранением полноты своей сути;
- Использовать технический язык (в меру своих знаний, конечно);
- Перед оформлением баг-репорта убедитесь, что такой баг-репорт уже не заведён;
- Воспроизведите дефекта два-три раза для понимания стабильности воспроизведения. При нестабильном воспроизведении укажите периодичность в части баг-репорта под названием "Стабильность".
- Прикрепляйте вложения (например, снимки экрана, логи, видео). Вложения ускоряют воспроизведение дефекта другой стороной, не пренебрегайте этим!
- В описании баг-репорта укажите ссылку на требование в документации, которое не соблюдается для продукта.
Заголовок (summary)
Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Основные правила:
1) Заголовок должен отвечать на вопросы "Что? Где? Когда?"
Обращу внимание, что части "Когда?" и "Где?" иногда мы можем опускать, в случае если и без них заголовок полностью отражает суть дефекта;
2) Заголовки должны быть написаны таким образом, чтобы не открывая баг-репорт, можно было понять суть ошибки;
3) В заголовках не используются слова "некорректные", “неверные”, “не работает”, “ошибка" и им подобные, потому что сути бага они не передают.
Давайте попробуем теперь составить заголовок для описанного выше дефекта. Попробуем с "мы можем ввести в поле почты на форме регистрации абсолютно любые символы". Данный заголовок отвечает на вопросы "Что? Где? Когда?":
"(что?) мы можем ввести (где?) в поле почты на форме регистрации абсолютно любые символы"
Однако, стоит перевести фокус внимания не на то, что "мы можем", а на факт самого дефекта: "Возможность ввода невалидных значений в поле почты на форме регистрации".
Какие же ошибки могут допустить новички при составлении данного заголовка?
1) Заголовок составлен в виде рекомендации. Например: "На форме регистрации в поле почты не должны вводиться невалидные значения". Это неверно. Заголовок - не рекомендация, а отражения сути дефекта.
2) Пропущены части заголовка. Например: "Возможность ввести невалидные символы". Вопрос возникает сразу, а где?
3) Неоднозначно указана часть "Где?". Пример: "Возможность ввода невалидных значений в поле почты". А где искать поле? На какой форме?
4) Заголовок нечитаем, либо состоит из нескольких предложений. Примеры:
"Возможность ввода невалидных значений. На форме регистрации. В поле e-mail";
"Ввод любых символов в поле почты никак не реагируется" (это реальный пример студента из практики, причём не самый плохой :) ).
5) В заголовке используется непрофессиональная лексика. Пример:
"Возможность ввода левых значений...".
6) Использование неоднозначных слов в заголовке по типу "некорректный", "не работает", "ошибка". Пример:
"Некорректное поведение формы при вводе невалидных значений в поле e-mail". И что это значит? Что за некорректное поведение?
"Возможность ввода некорректных значений...". Что значит "некорректные значения"? В таких случаях используются понятия валидных/невалидных значений.
Шаги воспроизведения (steps to reproduce)
Описывают поэтапные действия к воспроизведению дефекта.
Основные правила:
1) Глаголы в шагах воспроизведения должны быть обезличены. Примеры таких глаголов: нажать, кликнуть, ввести и так далее.
2) "Ничего не вводите в поле", "Убедиться, что", "Посмотреть на..." и подобные шаги воспроизведения не являются шагами, ибо не предполагают действий с системой. Их стоит просто опустить (если уже имеются в баг-репорте, то просто удалить).
3) Шаги воспроизведения должны быть атомарны. Один шаг воспроизведения = одно действие.
4) В шагах по типу "Ввести значение в поле" стоит указывать какие значения вводим и (!!!) пример значения.
5) Ощепринято считается, что количество шагов не должно превышать 5-7 на отчёт. В ином случае их стоит выводить в предусловия, либо ссылаться на инструкции.
Какие же шаги у нас могли бы получиться?
1. Открыть сайт <указываем URL сайта>;
2. Кликнуть на кнопку регистрации;
3. Ввести в поле e-mail невалидное значение (afsatewt@£$!);
4. Ввести в поле пароль валидное значение (fsfasfafs);
5. Нажать на кнопку "Зарегистрироваться".
А теперь какие ошибки мы могли тут допустить?
1) Не обезличенные глаголы. Примеры:
"Кликаем на кнопку", "Кликаю на кнопку" и так далее.
2) Составные шаги. Пример:
"Заполнить форму валидными значениями". Неверно. Один шаг = одно действие. Либо прикладываем ссылку на инструкцию, которая декомпозирует этот составной шаг на атомарные.
3) Не указаны примеры значения. Пример:
"Заполнить поле e-mail".
Ожидаемый и фактический результаты (expected and actual results)
Здесь мы описываем фактический результат (по сути сам дефект) и ожидаемый (согласно спецификации) результат.
Основные правила:
1) ОР и ФР отражают только результат после выполнения последнего шага воспроизведения;
2) ОР и ФР должны быть в настоящем времени;
3) ОР и ФР не должны дублировать шаги воспроизведения.
Тем самым, если брать рассматриваемый нами дефект, мы должны ответить на два вопроса:
Что происходит после выполнения последнего шага воспроизведения (Нажать на кнопку "Зарегистрироваться") и что должно происходить?
Получаем, что ФР = "Заявка на регистрацию успешно отправлена", ОР = "Ошибка валидации".
Какие же ошибки мы можем тут допустить?
1) ОР и ФР отражают результат НЕ после последнего шага воспроизведения. Пример такого ФР(ОР): значение в поле выделено красным. НО тогда возникает вопрос, а зачем нам нужен шаг "Нажать на кнопку регистрации", если мы и без него выходим на дефект?
2) ОР и ФР не в настоящем времени. Очень частая ошибка. Пример: "Должна отобразиться ошибка", "Отобразится ошибка".
3) ОР и ФР дублируют шаги воспроизведения. Пример: "После нажатия на кнопку регистрации заявка успешно отправлена". Зачем дублировать то, что указано в шагах воспроизведения?
Серьезность дефекта (severity)
Серьезность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется тестировщиком или техническим специалистом, который может оценить степень влияния дефекта на работу системы.
- S1 – Блокирующий (Blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. Если провести аналогию с закрытым помещением и дверью – то дверь закрыта, у вас нет никакой возможности её открыть и покинуть помещение. Окон нет, ключ к двери не подходит.
- S2 – Критический (Critical) – дефект блокирует часть функциональности, но есть альтернативный путь для его обхода. По аналогии с помещением и дверью: вы можете покинуть помещение через окно, хотя дверь по-прежнему закрыта и ключ к ней не подходит.
- S3 – Значительный (Major) – дефект, указывающий на некорректную работу части функциональности. Зачастую связан не с тем, что функция не работает, а с тем, что она работает неправильно. В любом случае, существует более одной точки входа для инициации нужной функциональности. Так, вы можете покинуть помещение без использования ключа (дыра в безопасности), через вентиляцию (другая точка входа) или дверь открывается не в ту сторону (как следствие, упирается в угол и открывается только частично – некорректная реализация). Наиболее часто встречаются дефекты, которые можно отнести именно к этому уровню серьезности.
- S4 – Незначительный (Minor) – дефект, не относящийся к функциональности системы. Обычно серьезность Minor проставляется для тех дефектов, которые относятся к удобству использования или интерфейсу. По аналогии с помещением и дверью – на двери написано «От себя», хотя она открывается на себя, неудобное расположение замочной скважины и т.д.
- S5 – Тривиальный (Trivial) – дефект, не затрагивающий функциональность системы, а также оказывающий минимальное влияние на общее качество системы. Часто неотличим от уровня «minor». Обычно это грамматические дефекты в сопроводительной документации к системе. Иногда дефект относится к «невидимым» проблемам с точки зрения пользователя или пользовательского интерфейса и рассматривает сторонние библиотеки или сервисы, не относящиеся к самой разработанной системе. По аналогии с помещением и дверью – замок и ключ не одного производителя, в помещении слышится шум сверху (не относится к самому помещению) и т.д.
Как думаете, какую серьезность стоит дать нашему дефекту?