Мысли о баг-репортах. Часть II.2. «Description» оно же «Описание»

Часть II.1 здесь

Шаги, это хорошо. Пронумерованные шаги — это  отлично. Но есть ещё нюансы, которые лучше описать так подробно, как только можно.

1. Описание тестового стенда.
2. Указание типа бизнес-пользователя, на которого влияет описываемый дефект.
3. Степень влияния дефекта на данного бизнес пользователя.
4. Возможные пути для окончательного выполнения бизнес-операции (workaround).
5. Ожидаемый результат.
6. Фактический результат.

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

Описание тестового окружения
Описание окружения, где был найден дефект.

  • Операционная система (например: Windows XP, SP2, 32bit).
  • Платформа и версия: JVM1.4.2 , .NetFramework 2.5

Если Web-приложение

  • Браузер и его версия (например: FF 4.0.1)
  • Плагины, add-ons, toolbars сторонних производителей, которые используются браузером.

Указание типа бизнес-пользователя, на которого влияет описываемый дефект

Одно из приложений, которое мне довелось тестировать, поддерживало такие типы пользователей для работы с одной из бизнес операций:

  • кассир
  • оператор по загрузке товара
  • специалист по конфигурации системы

Бизнес операция: «один раз  в день передать данные о совершенных операциях на сервер.»

  • Это была основная ежевечерняя бизнес операция для роли кассир.
  • Оператор по загрузке товара мог отправить данный отчет, но это случалось редко (в случае порчи лотков для загрузки товара, например — с отчетом одновременно записывался код состояния системы (поломки и т.п.))
  • Специалист по конфигурации системы — отправленные отчеты человеком с этой ролью,  помечались определенным образом в базе.

Дефект был в том, что кнопка для передачи данных была недоступной для роли оператор по загрузке.
В дефект была добавлена табличка:

Степень влияния дефекта на данного бизнес пользователя

кассир Влияние: нет
оператор по загрузке товара Влияние: высокое
специалист по конфигурации системы Влияние: нет

Это делалось и для того, что бы:

  • Показать бизнесу что разделение и обработка ролей выполняется корректно.
  • Предоставить информацию программисту по дополнительным условиям, которые необходимы для того, что бы дефект был проявлен.
  • Тестировщику, проверяющему дефект, было ясно: какое влияние было до момента исправления проблемы, и что следует проверить после его фикса.

Возможные пути для окончательного выполнения бизнес-операции (workaround)

Пути, которые позволяют совершить бизнес-операцию, ту, которую хотел совершить изначально пользователь. Обходными маневрами, используя клавиатуру вместо мышки…
Всегда хорошо, когда они есть, пусть даже и не тривиальные. Описывать их стоит. Ведь дефект может быть найдем на системе находящейся в стадии RTM(Release To Manufacturing). И да, как-то до исправления пользователям надо будет работать 🙂

Если дефект безжалостен и беспощаден настолько, что операцию выполнить невозможно — стоит об этом написать БОЛЬШИМИ ЖИРНЫМИ КРАСНЫМИ БУКВАМИ.

Ожидаемый результат
Это то, что мы ожидаем получить пройдя шаги для воспроизведения.
Это может быть корректное сообщение об ошибке. Это может быть успешная транзакция перевода 24 миллионов долларов.

Желательно, этот ожидаемый результат сопровождать ссылкой на что-нибудь, конкретное. Спецификацию. Пожелание пользователя. Если, конечно, есть на что ссылаться.

Самый дикий ожидаемый результат, который я видел: «поведение системы соответствует .xls и здравому смыслу«.
Одно облегчало понимание — в .xls тогда хранились бизнес-требования 🙂

Фактический результат

Фактический результат — это то, что происходит в системе, после того, как были выполнены все шаги. Это должно быть всегда.
Самое любезное, что можно получить на дефект без фактического результата: «Ну, прошел я шаги, и что?».
Действительно, «к сожалению в IT работают умные люди»©В. Панкратов, люди умные и не играют в угадайки. Не всегда понятно, что именно из поведения программы  не понравилось создавшему дефект, что не соответствует ожидаемому результату? Не всегда у людей есть возможность взять и повторить шаги. Должно быть написано — что не так.

Часть III (окончание) здесь.