Принцип "Где? Что? Когда?"

В ходе работы с дефектами часто сталкиваешься с тем, что приходится обращать внимание инженеров на необходимость более четкой формулировки summary дефекта. Причем, со временем это повторяется снова и снова. Та же ситуация наблюдается на интервью с соискателями на должность инженера по тестированию. Многие компании уделяют этому недостаточно внимания, но в сколь-нибудь большом проекте это может стать проблемой требующей решения.

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

1. Summary дефектов в большинстве своем нечетки. Это приводит к тому, что при поиске дубликатов своего дефекта инженер не может распознать дефект по summary и вынужден часто читать описание каждого подобного дефекта, что серьезно увеличивает время создания каждого отдельного дефекта в базе. Поэтому, скорее всего, он не будет перечитывать описание тщательно, чтобы не снижать свою продуктивность.
2. Инженеры еще недостаточно хорошо освоили сам продукт и связанную с ним предметную область, поэтому создают дефекты с различными неполными описаниями, но имеющими один и тот же источник.
3. Неправильное планирование тестирования (например когда области тестирования 2-х независимых инженеров сильно перекрываются, а поиск дубликатов к тому же затруднен причиной № 1).

В общем случае дубликаты - достаточно серьезная проблема, приводящая к снижению продуктивности как команды тестирования, так и программистов. Поэтому каждую причину надо устранять в отдельности. Способы устранения причин № 2 и № 3 достаточно очевидны. Причина № 2 устраняется дополнительными тренингами с формальным отведением времени под них при планировании либо естественным путем - инженеры со временем разберутся в продукте на достаточном уровне сами (метод решения зависит от степени влияния причины на проблему). Причина № 3 устраняется путем более четкого планирования тестирования с явным указанием областей ответственности инженеров в точках интеграции смежных компонентов). А вот причина № 1 системная, и ее устранение состоит в систематическом усвоении норм построения summary, которые должны стать частью вашего процесса и при этом не усложнять его, а упрощать.

Во вторых, если правила построения summary сложны и нечетки - они так или иначе в рутинном потоке заданий инженерами частично или полностью забываются.

Есть разные способы построения summary на сегодня. Вот, к примеру, два из них.

Первый способ:

1. Напишите сначала описание дефекта.
2. Посмотрите на него внимательно и выделите из него ключевые моменты.
3. Попробуйте сложить эти ключевые моменты вместе.

То что у вас получится в итоге и будет составлять summary вашего дефекта.

Второй способ:

Напишите описание дефекта по следующей схеме:

1. Шаги воспроизведения
2. Ожидаемый результат
3. Полученный результат

Если Вы построили описание правильно, то "Полученный результат" и будет summary вашего дефекта в общем виде. При необходимости можно добавить в него недостающие детали.

Я предлагаю другой способ или так называемый принцип "Где? Что? Когда?". Именно в таком порядке, не путайте с названием популярной телепередачи :)

В чем этот принцип состоит?
Составьте предложение, в котором факты дефекта изложены в следующей последовательности:

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

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

Вот пример такого summary.
Допустим, у Вас есть диалог "Преобразовать данные" с кнопкой "Преобразовать".
И при нажатии этой кнопки появляется сообщение об ошибке "Ошибка №...".
Тогда summary дефекта будет состоять из следующих частей:

1. Где?: Диалог "Преобразовать данные"
2. Что?: показывается сообщение об ошибке
3. Когда?: при нажатии кнопки "Преобразовать"

Итоговое summary будет иметь следующий вид:

Диалог "Преобразовать данные" показывает сообщение об ошибке при нажатии кнопки "Преобразовать"

Все остальные детали должны быть указаны в описании дефекта.