«

»

Май 13

Мысли о баг-репортах. Часть 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 (окончание) здесь.

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

4 комментария

3 пинга

Перейти полю для комментария

  1. Alex

    Теперь все это свести в один документ, убрать эмоции, и получится хит с названием примерно следующим — «Как правильно описывать баги».
    будет массово скачиваться начинаюшими тестировщиками, да и опытными тоже.
    И использоваться в качестве внутрикорпоративных инструкций.
    Насчет хита я серьезно — когда на основе парочки постов можно сделать весьма полезную инструкцию, это ОЧЕНЬ круто!

    1. Сергей Атрощенков

      Спасибо. Хочу заметить — это ещё не всё, окончание дописываю.

      Идея со сведением — согласен, интересна, думаю можно будет посмотреть, после завершения эпопеи, и до начала следующей:)

  2. Tatyana Durova

    Спасибо за статьи, но не совсем понятно различие в описании бага и ожидаемым/достигнутым результатом. Часто это еще и в заголовок идет как я понимаю. Повторение?

    1. Сергей Атрощенков

      Справедливое замечание, спасибо.

      Да, повторение, и в большинстве случаев излишнее.
      Почему я и рекомендую, ориентироваться по ситуации, в которой находимся. По ПО которое тестируем и т.п.

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

      Например,
      при тестировании реализации протокола, по сути ПО, которое по COM порту посылало пакеты данных, сгенерированных в зависимости от события, указывать целиком полученный пакет, я не видел смысла.
      Разница была не в несколько байтов.

      В ожидаемый результат указывался ожидаемый пакет, вида:
      AA B0 0A FF A0 FF


      00 CA 01 11 23 00
      это были осмысленные значения (данные программы, основанные на том, что мы получали проделав шаги для воспроизведения), переведенные в шестнадцетиричную систему счисления)

      Фактический результат был вида:
      BB 90 11 11 20 FA

      11 11 11 11 11 11

      Выносить это в заголовок — было бы не разумно.

      Заголовок был примерно такого вида:
      Неверные данные отображаются в программе «Ы» при событии А.

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

      В детальном описании дефекта:
      Неверные данные отображаются в программе «Ы» при событии А:
      1.разное количество собранных данных.
      2. нет соответствия между введенными пользователем данными и полученными «Ы».
      3. Текст требования, которое реализовывалось.

      //Сейчас я допускаю использования линка на конкретное требование, только не на всю спецификацию. Однако, практика показывает, что по линкам люди переходят неохотно. 🙁

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

      PS.
      Если сбоила генерация не всего пакета, а нескольких байтов: например: сбор информации о системном времени, это описывалось в заголовке.

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

    […] II.2 здесь. Tweet Поделиться Tweet Запись опубликована в рубрике […]

  2. Nothing found for Blog ?p=774

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

  3. Итоговое руководство по составлению отчетов об ошибках. | BarbaricQA.com

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>