Так ли уж сложно описывать баги - понятно?

Я — человек ленивый. И заставить себя что-то полезное-доброе-вечное сделать дома мне довольно сложно. Ну, например, посмотреть видео с конференции. Максимум одно в день. На большее нет ни времени, ни желания.

Но зато есть время в конференции поучаствовать! То есть, например, зарегистрировалась я на ConfetQA и это время, эти 2-3 часа у меня есть. А если я просто в обычный день пришла с работы, этих 2 часов на видео с конференций у меня нет.

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

Вот например, начинающих тестировщиков учат, как правильно оформлять баг-репорты. Ну вот казалось бы - что проще то, а?

А вот нет. На самом деле, оглядываясь назад, я вижу, что и сама грешила оформлением "здесь и сейчас под себя". А бага ррраз и переехала в следующий релиз. И вот ты через пару месяцев читаешь ее (свою же багу!) и пытаешься понять, а что там написано... Это я еще молчу о попытках понять, что написал другой человек 

Это вообще отдельная тема, поэтому пока о себе. Как один из примеров - был у нас большой и сложный отчет. Который можно было настроить под себя как душе угодно — из общего списка возможных колонок накидать себе нужные, даже со вложенностью! (на которой и возникали проблемы...).

А, главное, создал отчет — и его сохранить можно. Просто жмешь "Сохранить" и вводишь имя отчета и все. Даешь ссылку на тестовый стенд разработчику и говоришь "открой отчет А1". Он открывает, у него падает, можно подцепиться и локализовать. Так зачем расписывать все эти настройки? Ой как не хотелось этого делать, все равно разработчик напротив сидит и баги за 5 минут правит... Быстрее же просто ссылку дать!

Только вот однажды такой баг отложили в долгий ящик. И вот, значит, спустя 3 месяца ты сидишь и читаешь "Открыть «Отчет 1»". Зашибись, этого отчета уже давно не существует... Как теперь воспроизводить? Элементарного скриншота с внешним видом отчета (где какие колоночки) нету. Не то чтобы описания. Просто "Открой «Отчет 1» и все упадет". Воспроизводи как хочешь.

Но писалось то с мыслью, что сегодня-завтра поправят! Поэтому зачем долго описывать! И так сойдет! А еще лучше было, когда на отчет ссылочка давалась, ведущая в никуда 

Вот именно поэтому и надо писать подробно:

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

Шаги для воспроизведения
1. Открыть отчет
2. Установить по горизонтали ***, по вертикали ***
3. Нажать "Загрузить".

Результат
В такой то строчке такое-то значение

Ожидаемый результат
Там должно быть пусто, это поле пока не используется Заказчиком!

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

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

Но ладно, допустим, мы, как тестировщики, все это знаем и умеем. А как быть с Заказчиками? Они ведь пишут нам в суппорт! А если их пустили в баг-трекер, то даже ставят там задачи. И не всегда эти задачи выглядят... Понятно. Вот вроде ты и знаешь систему, но сути претензии не понимаешь... Почему так происходит?

У Томаса Лимончелли в его замечательной книге "Тайм-менеджмент для системных администраторов" есть просто потрясающий пример ответа на этот вопрос. Поэтому я продолжу развивать свой ярлык "выдержки из книг", самые самые интересные выдержки 

Если вы установили взаимную защиту от прерываний, вы можете отослать клиента к своему партнеру. Вовсе необязательно говорить "Я сейчас занят проектом, так что отправляйтесь к другому сисадмину". Можно поступить гораздо вежливее.

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

Люди не хотят заново объяснять свою проблему каждому, к кому их делегируют, поэтому я всегда излагаю суть вопроса своему коллеге. Я часто могу сформулировать ее в технических терминах гораздо эффективнее, чем клиент.

Итак, вот общая линия поведения. Я громко говорю "Я попрошу Мэри заняться этой проблемой". А затем я звоню Мэри: "Привет! Тут у меня Джо. Ему нужно то-то и то-то". Я поворачиваюсь к клиенту: "Мэри ждет Вас и готова Вам помочь". Джо получает подтверждение, что его запрос принят, а Мэри готова решить проблему.

Но наиболее шикарен даже не сам пример, а заметка, сделанная после него:

Будучи технически грамотными, мы нередко забываем, каково нетехнарям сформулировать запрос. Это очень трудно, может быть, даже страшно. Объясняя Мэри, чего хочет Джо, я облегчаю ему жизнь.

Вот оно! Вот почему нам кажутся запросы в поддержку странными, а порой даже смешными. Мы просто забываем, как тяжело нашим клиентам формулировать свои "не работает".  Это даже хорошо, что у нас таких проблем не возникает в принципе, что мы перешли в область неосознанного знания корректного составления баг-репортов или формулирования своих мыслей. Но не все же такие.

Помните о том, что все мы люди и помогайте своим Заказчикам грамотно формулировать свои запросы. Они не нарочно, им просто тяжело 


См также:
Как заводить задачи в баг-трекер — подробнее обо всех пунктах, не только шагах
Не пишите в баге «Ввести 6,9»! — как описывать шаги, чтобы и абстрактно, и конкретно.
Шаблон бага — использовался в статье
Упс, аттач то забыла... — история из жизни про ссылку на аттач, которого нету)

PS — статья написана давно, но редактируется специально для студентов моих курсов:

• Техники и инструменты поиска и оформления дефектов
• Интенсив для начинающих