Эффективные описания дефектов могут:

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

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

Полное описание дефекта

Контрольный список

Ниже приведен контрольный список для самопроверки вашего описания дефекта:

• Краткость изложения
• Корректность
• Нейтральность
• Точность
• Изолированность
• Обобщенность
• Воспроизводимость
• Последствия
• Отладочные данные
• Доказательства

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

Краткость изложения

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

Корректность

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

• чем-то, связанным с установкой – например, правильные ли версии приложений и библиотек установлены, в правильном порядке; под каким пользователем вы работали, достаточно ли прав?
• неполной деинсталляцией предыдущей версии, сбоями в выполнении предыдущих тестов?
• проблемами с сетью, операционной системой, или другими проблемами среды?
• недостаточным пониманием того, как оно должно работать на самом деле?

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

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

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

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

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

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

Точность

Человек, читающий описание дефекта, должен разобраться в нем без способностей детектива. Изложите суть дефекта внятно и точно. Например, некоторые описания содержат набор действий и их результатов – «я нажал Enter, произошло событие A; потом я нажал клавишу «Назад», и произошло B; потом я ввел команду «qwerty», и произошло C». Однако из такого описания для читателя может быть неочевидно, что неправильно в результатах – все ошибочные, один из них (какой?) ошибочный, все правильные.

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

Изолированность

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

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

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

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

Обобщенность

Часто разработчики исправляют в точности то, что описано в дефекте, не осознавая, что это только частный случай большей проблемы. Например, дефект может указывать, что функция сохранения в тестируемом текстовом процессоре не работает для некоторого файла «мой документ 1». Дополнительное исследование могло бы показать, что дефект возникает при сохранении любого файла нулевого размера. Проблемы могут возникать, например, при сохранении на подключенный диск, в папку с запретом на запись, и т.д. Наличие этой информации в описании дефекта сэкономит разработчику время и позволит исправить проблему более общим способом.

Воспроизводимость

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

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

Последствия

Каковы будут последствия дефекта, если он проявится у конечных пользователей? Для некоторых дефектов, например «При нажатии Enter происходит аварийное завершение системы», последствия очевидны; однако, не всегда последствия легко оценить. Например, вы можете обнаружить опечатку в одном из экранов – пустяк, если не обратить внимания на то, что этот экран открывается первым, в результате опечатки текст содержит грубое/нецензурное выражение. В таком случае, хотя это и всего лишь опечатка, ее обязательно необходимо исправить до выпуска продукта.

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

Отладочная информация

Что понадобится разработчику для изучения дефекта? Создавались ли какие-либо отчеты, дампы, сообщения об ошибках, или что-то еще, что может помочь в идентификации и воспроизведении проблемы? Укажите эти ресурсы и их местонахождение.

Доказательства

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

Краткое описание дефекта

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

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

Будьте максимально конкретны. Например, следующее описание справедливо, но содержит минимум информации:

×  Дефект: проблемы с сохранением и восстановлением данных.

В таком виде описание будет намного информативнее:

√  Дефект: сбой при сохранении/восстановлении данных в программе XYZ в WinNT, данные повреждаются.

Вы не сможете вместить в краткое описание все, поэтому предлагаю рассмотреть и следовать следующему списку:

• кратко и четко определить, в чем проблема – не только факт наличия проблемы

• использовать ключевые слова
• указать условия системы (операционная система, браузер, версия .NET и т.п.) и возможные последствия
• указать «кто», «когда», «где», «почему» и «зачем»
• использовать аббревиатуры
• пренебречь грамматикой в пользу плотности содержания
• не использовать значения по умолчанию