Техника написания хороших кратких Summary баг-репортов

Summary

Одной из самых больших проблем на тренингах для начинающих тестировщиков является написание хороших Summary баг-репортов. Многократные ответы на сотни вопросов о том, «что не так» и «а как надо» побудили меня написать эту статью.

Итак, «по классике» поле Summary баг-репорта должно:

  • содержать предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о баге;
  • отвечать на «три вечных вопроса»: «что?», «где?», «при каких условиях?» (или, хотя бы, на те 1-2 вопроса, которые применимы к конкретной ситуации);
  • быть достаточно коротким, чтобы полностью помещаться на экране (в тех баг-трекинговых системах, где «хвост» Summary обрезается или приводит к появлению скроллинга);
  • (возможно) содержать информацию об окружении, под которым был обнаружен баг (тут уж всё зависит от проектных традиций);
  • быть законченным предложением русского или английского (или иного) языка, построенным по соответствующим правилам грамматики.

Всё просто? Точно? Реальные примеры (не пытайтесь повторить это на работе):

  • «Wrong date format».
  • «Wrong age».
  • «Add more than 5 children».
  • «Fill empty fields».
  • «Error message during execution».
  • «Start application».
  • «В каталоге husband при заполнении middle name ошибка выскакивает».
  • «Data are lose».

Продолжать такие примеры можно до бесконечности. Я отказываюсь верить, что их авторы неспособны понять приведённые выше пять требований-пожеланий к Summary. Значит, проблема в чём-то другом.

Чтобы не заниматься гаданием на кофейной гуще, пойдём позитивным путём и рассмотрим несколько рекомендаций (а потом ещё и наглядных примеров их использования) по написанию хороших Summary.

  1. «Понять! Суть! Проблемы!» (Именно так, с восклицанием после каждого слова.) До тех пор, пока у тестировщика нет чёткого, кристально чистого понимания того, «что сломалось», писать баг-репорт можно лишь на свой страх и риск нельзя.
  2. Сформулировать длинное подробное описание (к слову, его можно будет потом дооформить и вставить в соседнее поле баг-репорта – Description).
  3. Убрать из Description всю «воду», уточнить важные детали.
  4. Выделить в Description слова (словосочетания, фрагменты фраз(ы)), отвечающие на вопросы, «что?», «где?», «при каких условиях?»
  5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.
  6. Если предложение получилось слишком длинным, переформулировать его, сократив длину (за счёт подбора синонимов, использования общепринятых аббревиатур и сокращений). К слову, в английском языке предложение почти всегда будет короче русского аналога.

Итак, примеры применения алгоритма.

Пример 1

  1. Ситуация: веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что ограничения нет (вводится хоть миллион символов).
  2. Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «Описание» данных.
  3. Исходный вариант Description: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «Описание» на странице (URL).
  4. Конечный вариант Description:
    Act: в описании товара (поле «Описание», URL) отсутствуют проверка и ограничение длины вводимого текста (MAX=250 символов).
    Exp: в случае попытки ввода 251+ символов выводится сообщение об ошибке.
  5. Определение «что?», «где?», «при каких условиях?» Что: отсутствуют проверка и ограничение длины вводимого текста. Где: описание товара, поле «Описание», URL. При каких условиях: — (всегда).
  6. Формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «Описание» описания товара.
  7. Сокращение (итоговое Summary): нет ограничения максимальной длины поля «Описание».
  8. Английский вариант: no check for «Описание» max length.

Пример 2

  1. Ситуация: попытка открыть в приложении пустой файл приводит к краху клиентской части приложения и потере несохранённых пользовательских данных на сервере.
  2. Суть проблемы: приложение начинает «в слепую» читать заголовок файла, не проверяя ни размер, ни корректность формата, ничего; клиент «валится», не закрыв сессию с сервером; сервер «сбрасывает» сессию по таймауту (повторный запуск клиента стартует новую сессию, так что старой сессии однозначно конец).
  3. Исходный вариант Description: некорректный анализ открываемого клиентом файла приводит к краху клиента и необратимой утере текущей сессии с сервером.
  4. Конечный вариант Description:
    Act: отсутствие проверки корректности открываемого клиентской частью файла (в т.ч. пустого) приводит к краху клиентской части и необратимой потере текущей сессии с сервером (см. BR852345). (Поскольку проблемы с сессией, это, фактически, другой баг, будет сделан другой баг-репорт.)
    Exp: производится анализ структуры открываемого файла; в случае обнаружения проблем отображается сообщение о невозможности открытия файла.
  5. Определение «что?», «где?», «при каких условиях?» Что: крах клиентской части приложение. Где: — (конкретное место в приложении определить едва ли возможно). При каких условиях: при открытии пустого или повреждённого файла.
  6. Формулировка: отсутствие проверки корректности открываемого файла приводит к краху клиентской части приложения.
  7. Сокращение (итоговое Summary): крах клиента при открытии повреждённых файлов.
  8. Английский вариант: client crashes on damaged/empty files opening.

Пример 3

  1. Ситуация: крайне редко по совершенно непонятным причинам на сайте слетает кодировка всего текста (как статических надписей, так и данных из БД, генерируемых динамически и т.д. – всё «становится вопросиками»).
  2. Суть проблемы: фреймворк, на котором построен сайт, подгружает специфические шрифты с удалённого сервера; если соединение обрывается, нужные шрифты не подгружаются, и используются шрифты по умолчанию, в которых нет русских символов.
  3. Исходный вариант Description: ошибка загрузки шрифтов с удалённого сервера приводит к использованию локальных несовместимых с требуемой кодировкой шрифтов.
  4. Конечный вариант Description:
    Act: периодическая невозможность загрузить шрифты с удалённого сервера приводит к использованию локальных шрифтов, несовместимых с требуемой кодировкой.
    Exp: необходимые шрифты подгружаются всегда (или используется локальный источник необходимых шрифтов).
  5. Определение «что?», «где?», «при каких условиях?» Что: используются несовместимые с требуемой кодировкой шрифты. Где: — (по всему сайту). При каких условиях: в случае ошибки соединения с сервером, с которого подгружаются шрифты.
  6. Формулировка: периодические сбои внешнего источника шрифтов приводят к сбою кодировок.
  7. Сокращение (итоговое Summary): периодический сбой кодировок из-за внешних шрифтов.
  8. Английский вариант: periodic encoding failure caused by external fonts usage.

А теперь – несколько примеров в «ускоренном режиме»

Ситуация Summary (RUS) Summary (ENG)
Крах клиентской части приложения приводит к необратимой потере сессии с сервером и потере всех несохранённых данных (сессия при повторном соединении не возобновляется, а начинается заново). Необратимая потеря сессии и всех несохранённых данных при крахе клиента. Irreversible session loss and all unsaved data loss on client crash.
Приложение валится с ошибкой обращения к памяти при открытии пятого файла (четыре уже открыты). Ошибка доступа к памяти при открытии пятого активного файла. Memory access failure on 5th active file opening.
Когда пользователь отправляет анкету, размер которой превышает допустимый, анкета загружается 5 секунд, а затем появляется сообщение «Извините! Письмо для HR не было отправлено! Пожалуйста, повторите попытку позже!» вместо сообщения «Размер анкеты не должен превышать 5Mb». Неверное сообщение об ошибке при отправке слишком большой анкеты. Wrong error message on sending too big application form.
В профиле пользователя можно указать дату рождения, находящуюся в будущем по отношению к текущей дате. Приложение принимает даты рождения из будущего. Application accepts dates of birth from the future.
После истечения сессии по таймауту для повторной авторизации пользователю приходится вручную чистить куки в браузере. Неверная обработка куки при завершении сессии по таймауту. Wrong cookies handling on session timeout.

Если у вас есть интересные примеры багов, которые можно использовать «в учебных целях», присылайте :).