Вариант для JIRA
h3. Шаги для воспроизведения
#
#
#
#
#
h3. Результат
h3. Ожидаемый результат
+ Аттач в виде скриншота.
Иногда еще нужна доп инфа, внизу добавляем:
h5. Дополнительная информация
******************************************************
В другом баг-трекере:
— Выделяем жирным заголовки (шаги, результат, ожидаемый результат).
— Нумеруем шаги. Единственный шаг нумеровать не надо.
— Отделяем шаги от результата и ожидаемого пустой строкой, дабы не получилась нечитабельная простыня текста.
В баге всегда пишется сначала результат, потом ожидаемый результат. Потому что менеджер или разработчик читают задачу, чтобы понять, в чем проблема. Читают читают шаги и тут бац, нормальный результат. Так в чем проблема? А потом зато фактический идет, это сбивает с толку.
В баге всегда пишется ожидаемый результат. Даже если он кажется вам очевидным.
— Он может быть очевидным только для вас. Другие члены команды не понимают, что нужно сделать.
— Он может быть очевидным для всех, но только сейчас. Если баг отложить на полгода, можно долго вспоминать, «что же тут ожидалось?»
На одном из курсов студентка написала с разницей в N времени:.
— А в багрепортах надо писать ожидаемый результат и фактический? оО
...
— Пока не попробовала пройти по некоторым чужим багам без результата и ожидаемого, и не попала в замешательство — не поняла, нафиг это надо.
Наглядность — наше все
Шаги для воспроизведения
Перейти в раздел «Статистика» в личном кабинете Дадаты — https://dadata.ru/profile/#stat (данные для авторизации: логин abc, пароль 1)
------------------------------------------------------------------------------------------------------------------
PS: Статья написана в помощь студентам моих курсов по тестированию:
и уже доступна на Testbase в навыке описания баг-репортов.
h3. Шаги для воспроизведения
#
#
#
#
#
h3. Результат
h3. Ожидаемый результат
+ Аттач в виде скриншота.
Иногда еще нужна доп инфа, внизу добавляем:
h5. Дополнительная информация
******************************************************
В другом баг-трекере:
— Выделяем жирным заголовки (шаги, результат, ожидаемый результат).
— Нумеруем шаги. Единственный шаг нумеровать не надо.
— Отделяем шаги от результата и ожидаемого пустой строкой, дабы не получилась нечитабельная простыня текста.
В баге всегда пишется сначала результат, потом ожидаемый результат. Потому что менеджер или разработчик читают задачу, чтобы понять, в чем проблема. Читают читают шаги и тут бац, нормальный результат. Так в чем проблема? А потом зато фактический идет, это сбивает с толку.
В баге всегда пишется ожидаемый результат. Даже если он кажется вам очевидным.
— Он может быть очевидным только для вас. Другие члены команды не понимают, что нужно сделать.
— Он может быть очевидным для всех, но только сейчас. Если баг отложить на полгода, можно долго вспоминать, «что же тут ожидалось?»
На одном из курсов студентка написала с разницей в N времени:.
— А в багрепортах надо писать ожидаемый результат и фактический? оО
...
— Пока не попробовала пройти по некоторым чужим багам без результата и ожидаемого, и не попала в замешательство — не поняла, нафиг это надо.
Наглядность — наше все
Пример
Шаги для воспроизведения
Перейти в раздел «Статистика» в личном кабинете Дадаты — https://dadata.ru/profile/#stat (данные для авторизации: логин abc, пароль 1)
Результат
500 ошибка сервера, см скриншот «Ошибка 500 в ЛК». (названия у скриншотов должны быть «говорящими», потому что их со временем может накопиться много)
Ожидаемый результат
Открылась статистика обработки данных
* Не пытайтесь воспроизвести проблему, разумеется, никакой ошибки в Дадате нет :)
------------------------------------------------------------------------------------------------------------------
Я не пишу в этом посте о том, какие поля нужно заполнять при заведении задачи, как расписывать шаги и прочее. Это все — тема для отдельных бесед
Пока просто шаблон для бага — бери и используй!
См также:
Шаблон улучшения — Такой же шаблон, только для улучшения =)
Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.
Пример локализации бага в игре «Паук» для iPad → применяем шаблон на практике!
Неправильный ярлык, угадай почему → и снова применяем, но тут с разбором описания, на что обратить внимание
Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.
Пример локализации бага в игре «Паук» для iPad → применяем шаблон на практике!
Неправильный ярлык, угадай почему → и снова применяем, но тут с разбором описания, на что обратить внимание
PS: Статья написана в помощь студентам моих курсов по тестированию:
и уже доступна на Testbase в навыке описания баг-репортов.
>На одном из курсов студентка написала: «Я не понимала, зачем писать ожидаемый результат, пока не почитала баги, поставленные другими учениками». Наглядность — наше все :)
ОтветитьУдалитьПрямая цитата? А то я тоже писала что-то такое)
Прямую не нашла :)
УдалитьЯ писала «пока не попробовала пройти по некоторым чужим багам без результата и ожидаемого и не попала в замешательство — не поняла, нафиг это надо»
Удалить:з
Хорошо, поменяла цитату :)
УдалитьОжидаемый результат нужен еще и тогда, когда тестируется новый функционал без документации, поди разбери, кто там что ожидает-) Так хотя бы юзер экспириенс сравните.
ОтветитьУдалитьВладимир, отличный комментарий! В этой ситуации и правда "поди разбери...")))
Удалить>В баге всегда пишется сначала результат, потом ожидаемый результат.
ОтветитьУдалитьОль, я бы не был столь категоричен, а начал бы эту фразу со слов "У нас в баге..."
И ещё. Ты не упомянула самую главную составляющую бага. Его название.
У меня есть свое виденье на этот счет, но интересно как ты учишь своих формировать название бага.
И, да. В редмайне можно поставить плагин, который выдаст шаблон (который формируется тобой) при нажатии одной кнопки. Останется только заполнить его по готовому примеру.
В блог-посте не надо писать везде "ИМХО", потому что это подразумевается :)
УдалитьА название в отдельной статье, на нее дается ссылка. Шаблона для названия у меня нет :) Разве что ответить на вопросы "Что? Где? Когда?" в одном предложении, но название → это тема отдельной статьи.
Про редмайн — круто! :)
Это не подразумевается, если мы используем подчеркнутое слово "всегда" ;)
УдалитьИ сделай уже нормальный визивик в блоге, ну.
>"Что? Где? Когда?"
Я уже писал на эту тему статью, извини.
Извиняю :)
УдалитьЯ пишу всегда с подчеркиванием, потому что я там считаю, это же очевидно. Исключения из правил бывают всегда, но ооооень редко.
Что такое визивик и что конкретно тебя не устраивает? А вроде писал статью про баги)))