Одной из самых больших проблем на тренингах для начинающих тестировщиков является написание хороших 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.
- «Понять! Суть! Проблемы!» (Именно так, с восклицанием после каждого слова.) До тех пор, пока у тестировщика нет чёткого, кристально чистого понимания того, «что сломалось», писать баг-репорт можно лишь на свой страх и риск нельзя.
- Сформулировать длинное подробное описание (к слову, его можно будет потом дооформить и вставить в соседнее поле баг-репорта – Description).
- Убрать из Description всю «воду», уточнить важные детали.
- Выделить в Description слова (словосочетания, фрагменты фраз(ы)), отвечающие на вопросы, «что?», «где?», «при каких условиях?»
- Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.
- Если предложение получилось слишком длинным, переформулировать его, сократив длину (за счёт подбора синонимов, использования общепринятых аббревиатур и сокращений). К слову, в английском языке предложение почти всегда будет короче русского аналога.
Итак, примеры применения алгоритма.
Пример 1
- Ситуация: веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что ограничения нет (вводится хоть миллион символов).
- Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «Описание» данных.
- Исходный вариант Description: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «Описание» на странице (URL).
- Конечный вариант Description:
Act: в описании товара (поле «Описание», URL) отсутствуют проверка и ограничение длины вводимого текста (MAX=250 символов).
Exp: в случае попытки ввода 251+ символов выводится сообщение об ошибке. - Определение «что?», «где?», «при каких условиях?» Что: отсутствуют проверка и ограничение длины вводимого текста. Где: описание товара, поле «Описание», URL. При каких условиях: — (всегда).
- Формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «Описание» описания товара.
- Сокращение (итоговое Summary): нет ограничения максимальной длины поля «Описание».
- Английский вариант: no check for «Описание» max length.
Пример 2
- Ситуация: попытка открыть в приложении пустой файл приводит к краху клиентской части приложения и потере несохранённых пользовательских данных на сервере.
- Суть проблемы: приложение начинает «в слепую» читать заголовок файла, не проверяя ни размер, ни корректность формата, ничего; клиент «валится», не закрыв сессию с сервером; сервер «сбрасывает» сессию по таймауту (повторный запуск клиента стартует новую сессию, так что старой сессии однозначно конец).
- Исходный вариант Description: некорректный анализ открываемого клиентом файла приводит к краху клиента и необратимой утере текущей сессии с сервером.
- Конечный вариант Description:
Act: отсутствие проверки корректности открываемого клиентской частью файла (в т.ч. пустого) приводит к краху клиентской части и необратимой потере текущей сессии с сервером (см. BR852345). (Поскольку проблемы с сессией, это, фактически, другой баг, будет сделан другой баг-репорт.)
Exp: производится анализ структуры открываемого файла; в случае обнаружения проблем отображается сообщение о невозможности открытия файла. - Определение «что?», «где?», «при каких условиях?» Что: крах клиентской части приложение. Где: — (конкретное место в приложении определить едва ли возможно). При каких условиях: при открытии пустого или повреждённого файла.
- Формулировка: отсутствие проверки корректности открываемого файла приводит к краху клиентской части приложения.
- Сокращение (итоговое Summary): крах клиента при открытии повреждённых файлов.
- Английский вариант: client crashes on damaged/empty files opening.
Пример 3
- Ситуация: крайне редко по совершенно непонятным причинам на сайте слетает кодировка всего текста (как статических надписей, так и данных из БД, генерируемых динамически и т.д. – всё «становится вопросиками»).
- Суть проблемы: фреймворк, на котором построен сайт, подгружает специфические шрифты с удалённого сервера; если соединение обрывается, нужные шрифты не подгружаются, и используются шрифты по умолчанию, в которых нет русских символов.
- Исходный вариант Description: ошибка загрузки шрифтов с удалённого сервера приводит к использованию локальных несовместимых с требуемой кодировкой шрифтов.
- Конечный вариант Description:
Act: периодическая невозможность загрузить шрифты с удалённого сервера приводит к использованию локальных шрифтов, несовместимых с требуемой кодировкой.
Exp: необходимые шрифты подгружаются всегда (или используется локальный источник необходимых шрифтов). - Определение «что?», «где?», «при каких условиях?» Что: используются несовместимые с требуемой кодировкой шрифты. Где: — (по всему сайту). При каких условиях: в случае ошибки соединения с сервером, с которого подгружаются шрифты.
- Формулировка: периодические сбои внешнего источника шрифтов приводят к сбою кодировок.
- Сокращение (итоговое Summary): периодический сбой кодировок из-за внешних шрифтов.
- Английский вариант: 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. |
Если у вас есть интересные примеры багов, которые можно использовать «в учебных целях», присылайте :).