В баге обычно пишут сначала фактический результат, а потом ожидаемый. Почему? Потому что вы описываете какую-то проблему. А читают люди сверху вниз и слева направо. В итоге я хочу понять, почему то, что в заголовке — это плохо. И читаю:
Погодите, погодите, то есть я выполняю шаги, получаю результат... Да он же классный, что в нем не так? И только потом я вчитываюсь в заголовки и понимаю, что это ожидания. Но ведь рано про ожидания говорить, я еще проблему не осознала.
Логичнее сначала описать проблему, а потом ваши ожидания. Если у вас еще нет шаблона бага — используйте мой, хотя бы на первых порах.
Понятное дело, что все компании разные. Бывает и так, что в команде уже принято писать сначала ожидания, потом факт. Им так удобно, им так привычно. Ок, делаем так, как удобно команде. Самое важное, чтобы всем все было понятно.
А вот если шаблона еще нет — пишите сначала факт, потом ожидания. Так разработчику будет проще читать. Можете мне поверить, я не раз видела в чате своих выпускников похожие рассказы:
— Взяли в компанию джуниором. И через неделю разработчики похвалили на планерке, как здорово и понятно я оформляю баги (еще бы, на курсе мы три шкуры за оформление понятное дерем). А ведь у остальных по несколько лет опыта работы, но похвалили меня!
Так что если видите, что баги вокруг оформляют тяп-ляп, не надо делать также. Да, они так уже год-два-три живут. Но они могли просто не видеть лучшей жизни!
Шаги
Делаем то, делаем се
Ожидаемый результат
Все работает круто! --- о_О
Фактический результат
Все плохо :(
Погодите, погодите, то есть я выполняю шаги, получаю результат... Да он же классный, что в нем не так? И только потом я вчитываюсь в заголовки и понимаю, что это ожидания. Но ведь рано про ожидания говорить, я еще проблему не осознала.
Логичнее сначала описать проблему, а потом ваши ожидания. Если у вас еще нет шаблона бага — используйте мой, хотя бы на первых порах.
Понятное дело, что все компании разные. Бывает и так, что в команде уже принято писать сначала ожидания, потом факт. Им так удобно, им так привычно. Ок, делаем так, как удобно команде. Самое важное, чтобы всем все было понятно.
А вот если шаблона еще нет — пишите сначала факт, потом ожидания. Так разработчику будет проще читать. Можете мне поверить, я не раз видела в чате своих выпускников похожие рассказы:
— Взяли в компанию джуниором. И через неделю разработчики похвалили на планерке, как здорово и понятно я оформляю баги (еще бы, на курсе мы три шкуры за оформление понятное дерем). А ведь у остальных по несколько лет опыта работы, но похвалили меня!
Так что если видите, что баги вокруг оформляют тяп-ляп, не надо делать также. Да, они так уже год-два-три живут. Но они могли просто не видеть лучшей жизни!
См также:
В баге есть фактический и ожидаемый результаты — подробнее о том, как описывать результаты
Как заводить задачи в баг-трекер — в целом о заведении задачи
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
"А читают люди сверху вниз и справа налево."
ОтветитьУдалитьКакие люди? Вроде только израильтяне и арабы. Остальной мир читает слева направо.
Да, подловили, исправила
УдалитьПри клике на ссылку "Как заводить задачи в баг-трекер" открывается статья "В баге есть фактический и ожидаемый результаты". А вообще спасибо вам огромное за знания!
ОтветитьУдалитьСпасибо, испавила)) И спасибо за фидбек))
Удалить