пятница, 14 декабря 2012 г.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

  1. Вот это мне сейчас очень актуально. Три года работала в компании, где баги описывались четко по шаблону, шаг влево,шаг вправо недозволялся буквально.
    пришла в новую компанию, а тут совсем нет таких требований и зачастую я вижу баг в трекере,описанный в стиле "что это? *скриншот*"
    это жутко бесит, ничего же непонятно, но ловлю себя на том,что зачастую уже и я начинаю скатываться в описание бага без шагов и тп. просто - вот тут вот так то, а должно быть так то. Да, я это делаю именно потому,что знаю что фикситься это будет вот буквально сейчас.
    но мне не нравится так делать :) поэтому все чаще заставляю себя оформлять все четко, чтобы и самой понимать и девелоперу жизнь облегчить.
    один мой коллега-программист с прошлой работы всегда говорил - "из тайтла бага я должен понять в чем проблема, а из дескрипшена - в какой строке кода мне делать изменения" :)

    ОтветитьУдалить
    Ответы
    1. >> Да, я это делаю именно потому,что знаю что фикситься это будет вот буквально сейчас

      Да да, конечно, я тоже так думала :)
      А потом разработчик заболеет или появится внезапная задача... В общем, в итоге ты увидишь свою задачку через месяц и будешь вспоминать "а что же я тут имела в виду?". Не очень продуктивный подход :)

      Удалить
  2. "Даешь ссылку на тестовы стенд разработчику" - баг в четвёртом слове.

    ОтветитьУдалить
    Ответы
    1. Спасибо, поправила, но баги еще стоит поучиться описывать)

      Удалить
  3. Добрый день
    После статьи "Так ли уж сложно описывать баги - понятно?" в блоке "См. также" ссылки: "Как заводить задачи в баг-трекер" и "Шаблон бага" ведет на одну и ту же страницу по адресу http://okiseleva.blogspot.ru/2015/02/blog-post_19.html
    Является ли это ошибкой или это так задумано?

    ОтветитьУдалить
  4. Стаття очень хорошая, но вот у меня возникла проблема при поступление на курсы тестировщиков.Дан скрин программы, и надо найти и описать баги, подскажите, как корректно выполнить это задание? (Фото прилогается) https://goo.gl/photos/ub3VKiuZ3inD5iHX9

    ОтветитьУдалить
    Ответы
    1. Нет, я не буду решать тестовое задание за вас :) Баги ищите сами, как "корректно оформить" — вон в статье ссылка на шаблон бага

      Удалить
  5. "один мой коллега-программист с прошлой работы всегда говорил - "из тайтла бага я должен понять в чем проблема, а из дескрипшена - в какой строке кода мне делать изменения"- золотые слова! Теперь я лучше понимаю к чему стремиться)

    ОтветитьУдалить