×Закрыть

Об эффективных багрепортах

Ты ставишь чайник на плиту, включаешь над ней подсветку, чтобы увидеть, что вкусненького в соседней сковородке приготовил тебе муж, а света-то и нет. Как ты ему об этом скажешь?

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

Как сказать ему о подсветке? Точнее, давай так себя спросим: как ему сказать о подсветке таким образом, чтобы он услышал, обратил внимание и однозначно понял, в чем состоит проблема?

Это называется «баг репорт» (bug report), сообщение о дефекте. Это понятие пришло из области разработки программного обеспечения, но оно касается человеческого общения в целом. Не то чтобы это было очень уж важной частью нашей жизни, но для работы полезно знать, как обращать внимание людей и коллег на проблемы. Более того, ведь мы не ставим себе целью просто обратить внимание на проблему, на сам факт ее существования. Нам важно, чтобы наш собеседник понял, в чем именно ее суть и чтобы на фоне его сознания сразу же закрутился поиск решения.


Нечеткий багрепорт («там эта штука не светит») все равно придется редуцировать (уточнять) до внятного. Но на это уйдет время и дополнительные уточнения («какая штука? А почему ты считаешь что она должна светить?»), получить которые без нервов не получится. А нервы надо беречь.

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

Формула совершенного багрепорта

Формула совершенного багрепорта состоит из трех простых пунктов:


Что сделала?

(Steps required to reproduce the problem)




Что получила?

(Actual results)




Что ожидала получить?

(Expected results)



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


«Дорогой, я включила свет над плитой, чтобы посмотреть, что вкусного ты приготовил, а он не горит. Ты не мог бы посмотреть, в чем там дело?»

Что сделала. Конкретная пошаговая инструкция, что нужно сделать для того, чтобы воспроизвести дефект.

Что получила. Что было получено в результате выполнения этой инструкции. Собственно, дефект.

Что ожидала. Что должно было, по мнению репортера, получиться в результате выполнения этой инструкции.

А также:

Где получила. Эта информация должна присутствовать в багрепорте, чтобы тот, кто будет его читать, сразу понял, в какой части системы случилась беда. Необязательно эту информацию давать отдельным пунктом. Можно просто включить ее в «что сделала», поскольку путешествие по системе к сломавшейся формочке — это действия.

Условия. То, что не является действием, но что важно. Например, для веб-приложений нужно упомянуть броузер/ОС.

Название. Это самое краткое описание проблемы или ее части, какое только можно сформулировать. Используется для устного общения, для списков багрепортов и т.п.

Это — очень полезная форма:

  1. Она прозрачна. Она не позволяет репортеру отклониться в повествовательный стиль или транслировать поток сознания;
  2. По ней сложно написать что-то, отличное от багрепорта. Как следствие, уменьшается количество информационного шума в работе;
  3. Легко верифицировать. Т.е. выполнив указанные шаги, можно получить такой же результат и подтвердить что дефект существует; или же получить иной результат и создать новый багрепорт; или же получить ожидаемый результат и отклонить багрепорт;
  4. В таком багрепорте четко видно, валиден ли он, т.е. действительно ли данная ситуация является дефектом. Вдруг так и надо, чтобы лампочка над плитой не горела, потому что ее там вовсе не предусмотрено, а холостой выключатель по непонятным соображениям поставили загадочные китайцы?
  5. Такая форма избавляет от лишней коммуникации (донельзя надоевших общих уточняющих вопросов);
  6. Этой форме легко обучить несмышленных пользователей; Всего два-три дня истерик и ваши коллеги научатся внятно общаться;
  7. Сообщая вам в багрепорте, что именно ожидал увидеть пользователь, он тем самым как бы подтверждает, что он владеет системой и понимает, как она должна работать в данном случае;
  8. Такой багрепорт не мотивирует ответственное лицо заткнуть его в угол подальше и забыть поскорее;

А теперь — слайды

Типовая ошибка, которую заметил пользователь:


Не могу войти в систему



Что сделал:

1. Открыл www.something.com

2. Кликнул на «логин», увидел форму входа

3. Ввел «egor» в поле логина, ввел корректный пароль в поле пароля, кликнул на «вход»



Что получил:

Белая страничка, адрес www.something.com/checklogin



Что ожидал получить:

1. Форму входа с диагностикой «неправильный пароль» или

2. Главную страничку системы для пользователя



Условия:

MSIE 4.01/Windows ME


Типовая ошибка, которую заметил системный администратор:


Exim’у капец



Что сделал:

Запустил /etc/init.d/exim4 restart на сервере lopata.something.com



Что получил:

touch: `/var/lib/exim4′: directory not found



Что ожидал:

exim перезапустился, стандартное сообщение Ubuntu об успешном перезапуске сервиса

Типовая ошибка, которую заметил программист:


Сломался dbPeerAccess->version()



Что сделал:

use dbPeerAccessor;

use DBI;



my $dbh = DBI->connect("dbi:mysql:telme«, «telme», «telme»);

my $dbAccess = $dbPeerAccessor->new($dbh);



Что получил:

$dbAccess->version() == undef



Что ожидал:

$dbAccess->version() == «1.3.0»;



Условия:

trust:htdocs egor$ mysql -utelme -ptelme telme

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 302

Server version: 5.0.51 Source distribution



Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the buffer.



mysql>

Кстати, такого рода багрепорты (по коду) вообще можно сообщать в виде тестов (reduced test case), примерно как вот здесь, только в виде одного, целого скрипта, например:


use dbPeerAccessor;

use DBI;



my $dbh = DBI->connect("dbi:mysql:telme«, «telme», «telme»);

my $dbAccess = $dbPeerAccessor->new($dbh);

printf("dbPeerInstance is %s\n«,

defined $dbAccess->version() ? «defined» : «undefined»);

Типовая ошибка, которую заметил проектный менеджер:


«Забыл пароль» должно работать иначе



Что сделал:

1. Открыл www.something.com

2. Кликнул в «забыл пароль»

3. Открылась форма с предложением ввести свой email, ввел туда свой email, существующий в базе и принадлежащий моему юзеру

4. Кликнул «восстановить»



Что получил:

1. «Вам отправлен новый пароль»

2. Пришло письмо, в котором был сгенерированный новый пароль

3. Этот пароль действительно работает, старый не работает



Что ожидал:

В соответствии с нашими user stories, письмом должен был прийти не новый пароль, а линк на страничку, на которой пользователь может сам создать себе новый пароль

Типовая ошибка, которую заметил финансовый директор:


Почему такие дорогие кресла?



В полученном 01.04.2008 от Васи отчете увидел раздел «офисная мебель», а в нем пункт «кресла для новых сотрудников, 2шт», по цене $1,400 за штуку. Мы ожидали, что Вася будет покупать в отдел кресла для сотрудников в пределах $200, но не полторы же тыщи баксов? Просьба на первое апреля не ссылаться.

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

No pain — no gain


Хорошо зафиксированный пациент не нуждается в анестезии.

Есть важный момент, который необходимо учитывать при внедрении вот такой формы багрепорта (а фактически — бизнес-процесса) в вашей команде. Дело в том, что никто не считает себя дураком; напротив, обнаружив багу, пользователь сразу почувствует себя умнее создателя системы. Даже бессознательно. Поэтому, находясь в контексте обнаруженного дефекта, пользователь будет абсолютно комфортно и уверенно себя чувствовать, заполняя багрепорт вида «программа не работает, точка».

Поэтому внедрение строгой формальной формы багрепорта будет болезненной для коллектива. Причем если для IT-коллектива эта боль переживается довольно быстро, поскольку все — люди рациональные, то внедрение в отдаленном от IT коллективе будет ощущаться весьма. Багрепорт приносит прозрачность в работу, а прозрачность требует определенных усилий. Да и не каждому человеку в принципе под силу осознать, что такое «контекст» и почему собеседник его не понимает, ведь это же так просто, программа не работает, вот смотри.

Мне доводилось внедрять этот «бизнес-процесс» на предприятии, где с пользователями общалась только менеджер по работе с клиентами. Она получала от пользователей замечания и заполняла по ним багрепорты. Как и всякий гуманитарий, она мыслила изящными линиями и написать прямой и тупой багрепорт ей было очень сложно. Это были слезы, истерики и обиды на меня, руководителя подразделения. Совершенно искренние слезы! И хоть мне и было ее жалко и совсем не хотелось причинять человеку боль, тем не менее, я отклонял багрепорт за багрепортом, пока она не научилась писать эту несложную форму. На это ушло около трех дней. Через еще пару дней она уже на полном автомате писала прекрасные багрепорты, а спустя еще недельку она поняла ценность такого подхода и стала его сторонником. Продуктивность ее работы возросла, и проблемы клиентов стали решаться оперативнее.

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

Перевод этой статьи на английский язык: Priceless bugreports.

  • Популярное

45 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо. Хорошая статья. Краткость сестра таланта.

Статейка — ПРОСТО КЛАСС!

Работаю руководителем отдела тестирования.Могу сказать, что статья, без сомнения, правильная. Были в моей практике индивидуумы, которые только в такой форме могли писать подробный репорт. В вольном стиле получалось как вилами по воде — ни черта не понятно, смысл предложения терялся в заумных формулировках.Однако: Сейчас я требую от багрепортов не детального ответа на каждый из вопросов, а лаконичного и доходчивого текста, в котором перечисленные выше пункты можно легко выделить. В этом случае и тестер не устаёт от излишней бюрократичности, и программист способен понять суть вопроса. Присутствие ответов на вопросы в тексте поначалу, конечно, приходится смотреть лично, но уже через несколько дней тестер привыкает делать это самостоятельно.P.S.: Я бы добавил ещё один пункт «поясняющие дополнения» (сюда можно отнести скриншоты, видеоролики, логи программы, в общем, всё, что облегчит программисту понимание предмета).

to 40. Выпивай валерианки перед тем как писать комменты. Такое ощущение что «узколобый» тут отнюдь не автор статьи. Если бы я не был студентом — самоучкой — то зачем мне читать статьи. Про «наше» образование тут уже не раз обсуждался вопрос. Если уж за то чело зашло — ты родился сразу одаренным и без вышки пошел на работу? Второй момент: с какой стати оскорбляешь персонально автора? Хотя, надеюсь что ты более не заглянешь на этот форум и мои вопросы останутся без ответов.Естественно, идеального баг репорта не придумаешь, но направление понимать надо. А то что тут пишут «формула совершенного баг репорта» — это значит всего лишь, что если эта информация для тебя актуальна и полезна — бери на вооружение, а если будет более мощный, если так можно выразиться, источник информации — черпай знания оттуда. Элементарным примером может служить: что-то в школе тебе рассказывали по физике, прийдя в институт узнаешь что даже самые простые вещи не такие уж и простые. Однако нельзя сказать что школа — это полная херня и все что там рассказывают — рассказывают узколобые идиоты. Все как раз зависит от ширины твоего лба. Статья — хорошая, но естественно это всего лишь первая ступенька для понимания.

То 40.Я не обязан знать, какая у меня машина. С чего бы это вдруг я бы знал, что ездит она на бензине. Какие права?

Перевод этой статьи на английский язык: Priceless bugreports.

стыдно стало. да стыдно...Попробую использовать.спасибо.

2 Thorn: сэр просто болван или для начала сам не умеет разговаривать с людьми? Или честно-честно верит в спойлеры «как зажить щасливо» до последней буковки?

Вы извините, господа самоуважаемые программеры, но статья — типичное, эгоцентричное фуфло, под которое узколобый программерпытается прогнуть весь мир. Юзер — это нежное, необременённое знаниями существо. Почему он обязан знать, какой у него браузер (и что это вообще такое), какая у него версия и что он должен был получить, если он не видел правильного результата? Вы слишком дохрена хотите, изнеженные офисом кнопочники. Хотите детальные репорты? УЧИТЕСЬ РАЗГОВАРИВАТЬ С ЛЮДЬМИ.На общем, а не вашем профессиональном слэнге. Подсказки к репорту — хорошо, но даже тут статья облажалась — видно, что сосали еёиз непонятного пальца. Баги имеют разные типы, могут НЕ иметь «ожидаемого результата», могут иметь важные данные об условиях работы, скриншоты, да много чего! Так что эта «фундаментальная троица» вопросов — вовсе не идеал «эффективного багрепорта». Думайте, прежде чемпеть дифирамбы, а то создаёте ощущение студентов-самоучек.

Например "В соответствии с нашими user stories письмом должен был прийти не новый пароль, а линк на страничку, на которой пользователь может сам создать себе новый пароль"не коректна. В ней отсутвует ссылка на версию-раздел юзер-сториёв. Вчера заказчик хотел так, сегодня так, а после завтра иначе. А потом девелопер на надцатом изменении багу закрыть забыл. А другой через месяц увидел и решил пофиксить закрывая по пинку ведущего все тикеты...И что в результате получитЬ заказчик?; o)

Кто там спрашивал на английском, можно найти здесь

No pain — no gainСреди врачей эту шутку принято переводить, как: «Не бывает плохой анестезии — бывает плохо привязанный больной».

Браво, про внедрение такого подхода написана чистая правда.К моему прискорбию... только так и работает. Мягкий подход наплодит ведро компромиссов и надолго отобьет желание совершенствовать процесс.

> используют subversion и счастливыЕгор, запарит мерж — заглядывай в гости.:) А за ссылку одни спасибы говорят, ну что такое!:)

TO 29. Как раз при разработке финансовых систем и их отладке деньги не теряются. Деньги просто становятся «реальными» после того, как система принята.Хотя бывает, что выделяются небольшие деньги на контрольные закупки, которые потом подтверждаются сданным товаром или являются вознаграждением полевого тестера.С другой стороны — нужно больше денег и времени для тестирования, которое зачастую бывает строго формальным — т.е. перебираются ВСЕ возможные воздействия и отклонения.А пул денег для дерибана — идея хорошая, но не от этой темы...

Руль!) Особенно про пациента)

А как у вас баги репортятся? Неужели, в текстовом виде или по электропочте? Везде, где я видел, новый багрепорт — это заполнение формы с правильными вопросами. По-моему, если заполняющему знаком язык системы, то он/она быстро научатся всё делать правильно.

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

Шигорин,:) я и все мои коллективы используют subversion и счастливы. GIT это хорошо. Но мы используем subversion.:)

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

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

Нічого принципово нового для себе в статті на побачив, але її цінність від цього не зменшується, особливо судячи з коментарів. Все написано правильно, від себе єдине що хотів би додати: частина «Что сделала. Конкретная пошаговая инструкция, что нужно сделать для того, чтобы воспроизвести дефект.» повинна бути якнайкоротшою, тобто кількість кроків, які ведуть до відтворення бага повинна бути мінімальною. Це, з одного боку економить час програміста на відтворення, а з іншого мотивує перед написання багрепорту глибше дослідити сам баг.

Под мэйнстримом имелось в виду, что при создании высоконагруженного сайта, наоборот, нужно забить на новые тенденции вроде RoR и Django и тупо кодить на PHP в любом случае.

jaguar, если баг не воспроизводится, то можно так и написать. Во всяком случае, если программист десять минут над ним помедитирует — хуже не будет, а лучше — запросто. некоторые баги ловятся мысленно. не очень частно, но есть.

Андрей,

Тем более пользователь — не злобный тиран, поставивший целью жизни максимально осложнить жизнь разработчику

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

Замечательно изложено. С моим опытом согласуется практически полностью.2 Мрачный заказчик: Контора должна обеспечивать корректные ответы программистов. Технически это весьма просто: project manager или кто там есть на должности руководителя проекта тоже просматривает эту переписку и дает по шапке слишком зарывающимся работникам. Или получает по шапке сам. Это же часть его работы. Если часть становится слишком большой — следует нанять чела на саппорт, и спрашивать с него.Разработчик должен уважать и любить своего пользователя — ведь именно он в конечном счете дает деньги. (Исключения из правила рассматриваются в особом порядке и обсуждаются отдельно).Но нужно заставить пользователя проявлять ответное уважение и помогать разработчику в решении общих проблем. Никакого противоречия не вижу. Несоблюдение этого простого принципа приводит к негативным результатам для всех учавствующих сторон.Тем более пользователь — не злобный тиран, поставивший целью жизни максимально осложнить жизнь разработчику. Он, как правило, готов задавать правильные вопросы чтобы получить ожидаемый ответ в виде исправления/улучшения функциональности. Попытки научить задавать хорошие вопросы воспринимает положительно — или плохо учили.

Правда жизни.Главное, не дать воспользоваться контраргументом «вы должны удовлетворить пользователя».

ничего нового, конечно, не написано:) но все равно было интересно. «правильные» багрепорты все равно получаются только после долгих исканий.Например, у меня багрепорт — это 1. исходный файл, на котором проявляется проблема, 2. использовавшиеся настройки программы и 3. указание, на что именно смотреть.

Отличная заметка! Согласен с каждым пунктом.В одной компании ответом на репорты а-ля «эта штучка не светит» была фраза из древнего анекдота — «Штурман, приборы».После того, как удивленный репортер прибегал/звонил за разьяснениями странного «шифра» — его заставляли записать 5 вопросов из списка выше и отправляли заново оформлять репорт.При повторном звонке с вопросом «Какие такие приборы? Вы о чем? » — можно было нарваться на весьма нецензурно оформленное указание читать свои же записки.Третьего вопроса «что за приборы? » — ещё ни разу не дождался:)

Офтопик: Егорушка, это ж правда не ты вникал в это непотребное тормозное глюкало? Если вдруг по какому несчастному случаю ты — сильно рекомендую посмотреть на git (или хотя бы DSCM как таковые), другой вид спорта и мержи там — не бомжи.

капча — да:) ну, а тема статьи она и есть тема статьи. на другие темы есть другие статьи:)

У статьи есть центрирование вокруг процедуры, а не вокруг оптимизации ресурсов и снижении времени на достижение результата. Процедура сама по себе хороша, важно понимать, что как только ее поднимут программисты как знамя (а они поднимут), то все будет плохо. Хорошо когда менеджер не программист и понимает деструктивность такого стереотипного мышления, а если программист? Вот и получаются такие продукты.PS: капча всё время одинаковая, просит 9

Ага. Но думаю цель статьи — не в том чтобы помочь всем. Это инфа. А кто сможет с её помощью себе помочь, а кто нет — это другой вопрос:)

Фантастика на втором этаже.

2Мрачный>> Программист [...] посылает багрепортера>> [...] >> программсита увольняют... А потому что не надо посылать. Не надо. Да и багрепортер должен фильтровать когда ему правильное замечание делают, а когда — нет. И то что программистам не нравится что-то количество фидбека снижаться не должно. Так что приходим ко всем известной истине что работники должны быть нормальными. И программисты, и тестеры, и все остальные:)

А теперь ситуация: Программист не вник в описание бага, не понимает с первого раза о чем баг-репорт (такое бывает, мысли читать еще не научились, равно как и нежелание работать или нет настроения или еще что-то), посылает багрепортера писать репорт правильно (как правило без уточнения что и как) Результат: 1. количество фидбека резко снижается2. качество продукта неуклонно падает, ибо кому приятно быть посланым3. программиста увольняют за некачественный продукт/разрывают отношения с девелопментомРешение — обе стороны двигаются планомерно не вокруг процедуры (а репортить надо отак бл, а не то что ты мне написал г-но!), а вокруг общей цели — улучшения качества продукта.

Кому интересно, небольшое уточнение: Неправильное срабатывание софта это строго говоря не дефект. Это следствие дефекта.Вот один и вариантов детальной классификации, которую можно встретить в литературе по тестированию: — Error/Mistake — ошибка, сделанная человеком- Defect/Fault/Bug — воплощение этой ошибки (например в документе с требованиями, конфигурациях или программном коде) — Failure — неправильное функционирование софта в результате дефектаА статья прикольная — на оч доступном языке и фраза об анестезии понравилась:)

Хорошая статья. Нашёл для себя нечто новое, а именно — что название баг-репорта нужно лишь для того, чтобы отличать один баг-репорт от другого кроме как по номеру и содержанию (и в некоторых ситуациях можно обойтись без названий баг-репортов).

Хорошая статья, спасибо.P.S. про пациента и анастезию — это ж явно эпиграф, а оформлен как цитата.

Статья супер! Именно такую мордочку должны показывать пользователям багтрэкеры.

Хммм... есть спрос на английскую версию. Я подумаю о переводе. Спасибо за позитивный фидбек)

Автору большой респект. Вопрос к автору: есть ли вариант этой статьи на английском, если есть — буду очень презнатен за ссылку.

Отличная статья прям в точку) Было бы еще неплохо такую иметь в английском варианте для заказчиков, я бы перевел, но мой английский не файн (

Чудная заметка. Дзенюкую бардзо.

Подписаться на комментарии