понедельник, 25 мая 2015 г.

Шаблон бага

Вариант для JIRA

h3. Шаги для воспроизведения
#
#
#
#
#

h3. Результат

h3. Ожидаемый результат

+ Аттач в виде скриншота.


Иногда еще нужна доп инфа, внизу добавляем:

h5. Дополнительная информация

******************************************************

В другом баг-трекере:
— Выделяем жирным заголовки (шаги, результат, ожидаемый результат).
— Нумеруем шаги. Единственный шаг нумеровать не надо.
— Отделяем шаги от результата и ожидаемого пустой строкой, дабы не получилась нечитабельная простыня текста.

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

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

На одном из курсов студентка написала с разницей в N времени:.

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

Наглядность — наше все Smile :)

Пример


Шаги для воспроизведения

Перейти в раздел «Статистика» в личном кабинете Дадаты — https://dadata.ru/profile/#stat (данные для авторизации: логин abc, пароль 1)
Результат

500 ошибка сервера, см скриншот «Ошибка 500 в ЛК». (названия у скриншотов должны быть «говорящими», потому что их со временем может накопиться много)

Ожидаемый результат

Открылась статистика обработки данных

* Не пытайтесь воспроизвести проблему, разумеется, никакой ошибки в Дадате нет :)

------------------------------------------------------------------------------------------------------------------

Я не пишу в этом посте о том, какие поля нужно заполнять при заведении задачи, как расписывать шаги и прочее. Это все — тема для отдельных бесед Smile :) 

Пока просто шаблон для бага — бери и используй!

См также:

Шаблон улучшения — Такой же шаблон, только для улучшения =)
Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.
Пример локализации бага в игре «Паук» для iPad → применяем шаблон на практике!
Неправильный ярлык, угадай почему → и снова применяем, но тут с разбором описания, на что обратить внимание

PS: Статья написана в помощь студентам моих курсов по тестированию:
и уже доступна на Testbase в навыке описания баг-репортов.

10 комментариев:

  1. >На одном из курсов студентка написала: «Я не понимала, зачем писать ожидаемый результат, пока не почитала баги, поставленные другими учениками». Наглядность — наше все :)

    Прямая цитата? А то я тоже писала что-то такое)

    ОтветитьУдалить
    Ответы
    1. Я писала «пока не попробовала пройти по некоторым чужим багам без результата и ожидаемого и не попала в замешательство — не поняла, нафиг это надо»

      Удалить
    2. Хорошо, поменяла цитату :)

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

    ОтветитьУдалить
    Ответы
    1. Владимир, отличный комментарий! В этой ситуации и правда "поди разбери...")))

      Удалить
  3. >В баге всегда пишется сначала результат, потом ожидаемый результат.

    Оль, я бы не был столь категоричен, а начал бы эту фразу со слов "У нас в баге..."

    И ещё. Ты не упомянула самую главную составляющую бага. Его название.
    У меня есть свое виденье на этот счет, но интересно как ты учишь своих формировать название бага.

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

    ОтветитьУдалить
    Ответы
    1. В блог-посте не надо писать везде "ИМХО", потому что это подразумевается :)
      А название в отдельной статье, на нее дается ссылка. Шаблона для названия у меня нет :) Разве что ответить на вопросы "Что? Где? Когда?" в одном предложении, но название → это тема отдельной статьи.

      Про редмайн — круто! :)

      Удалить
    2. Это не подразумевается, если мы используем подчеркнутое слово "всегда" ;)

      И сделай уже нормальный визивик в блоге, ну.

      >"Что? Где? Когда?"
      Я уже писал на эту тему статью, извини.

      Удалить
    3. Извиняю :)
      Я пишу всегда с подчеркиванием, потому что я там считаю, это же очевидно. Исключения из правил бывают всегда, но ооооень редко.

      Что такое визивик и что конкретно тебя не устраивает? А вроде писал статью про баги)))

      Удалить