Об эффективных багрепортах
Егор ЕгоровОпубликовано 3.04.2008 в Статьи, Тестирование
Ты ставишь чайник на плиту, включаешь над ней подсветку, чтобы увидеть, что вкусненького в соседней сковородке приготовил тебе муж, а света-то и нет. Как ты ему об этом скажешь?
«Дорогой, поменяй лампочку на кухне» или «Любимый, там эта штука не светит»? В этот момент любимый вникает в свежую версию subversion, пытается понять как сделать merge двух репозиториев и ему твоя лампочка — до лампочки.
Как сказать ему о подсветке? Точнее, давай так себя спросим: как ему сказать о подсветке таким образом, чтобы он услышал, обратил внимание и однозначно понял, в чем состоит проблема?
Это называется «баг репорт» (bug report), сообщение о дефекте. Это понятие пришло из области разработки программного обеспечения, но оно касается человеческого общения в целом. Не то чтобы это было очень уж важной частью нашей жизни, но для работы полезно знать, как обращать внимание людей и коллег на проблемы. Более того, ведь мы не ставим себе целью просто обратить внимание на проблему, на сам факт ее существования. Нам важно, чтобы наш собеседник понял, в чем именно ее суть и чтобы на фоне его сознания сразу же закрутился поиск решения.
Нечеткий багрепорт («там эта штука не светит») все равно придется редуцировать (уточнять) до внятного. Но на это уйдет время и дополнительные уточнения («какая штука? А почему ты считаешь что она должна светить?»), получить которые без нервов не получится. А нервы надо беречь.
Программисты, привыкшие формулировать мысли ясно (ладно-ладно, это комплимент), за долгие годы развития индустрии пришли к простой формуле, по которой можно сообщать друг другу о проблемах.
Формула совершенного багрепорта
Формула совершенного багрепорта состоит из трех простых пунктов:
Что сделала?
(Steps required to reproduce the problem)
Что получила?
(Actual results)
Что ожидала получить?
(Expected results)
Кроме того, нужно сообщить, где именно произошла проблема, при каких условиях а также дать ошибке название.
«Дорогой, я включила свет над плитой, чтобы посмотреть, что вкусного ты приготовил, а он не горит. Ты не мог бы посмотреть, в чем там дело?»
Что сделала. Конкретная пошаговая инструкция, что нужно сделать для того, чтобы воспроизвести дефект.
Что получила. Что было получено в результате выполнения этой инструкции. Собственно, дефект.
Что ожидала. Что должно было, по мнению репортера, получиться в результате выполнения этой инструкции.
А также:
Где получила. Эта информация должна присутствовать в багрепорте, чтобы тот, кто будет его читать, сразу понял, в какой части системы случилась беда. Необязательно эту информацию давать отдельным пунктом. Можно просто включить ее в «что сделала», поскольку путешествие по системе к сломавшейся формочке — это действия.
Условия. То, что не является действием, но что важно. Например, для веб-приложений нужно упомянуть броузер/ОС.
Название. Это самое краткое описание проблемы или ее части, какое только можно сформулировать. Используется для устного общения, для списков багрепортов и т.п.
Это — очень полезная форма:
- Она прозрачна. Она не позволяет репортеру отклониться в повествовательный стиль или транслировать поток сознания;
- По ней сложно написать что-то, отличное от багрепорта. Как следствие, уменьшается количество информационного шума в работе;
- Легко верифицировать. Т.е. выполнив указанные шаги, можно получить такой же результат и подтвердить что дефект существует; или же получить иной результат и создать новый багрепорт; или же получить ожидаемый результат и отклонить багрепорт;
- В таком багрепорте четко видно, валиден ли он, т.е. действительно ли данная ситуация является дефектом. Вдруг так и надо, чтобы лампочка над плитой не горела, потому что ее там вовсе не предусмотрено, а холостой выключатель по непонятным соображениям поставили загадочные китайцы?
- Такая форма избавляет от лишней коммуникации (донельзя надоевших общих уточняющих вопросов);
- Этой форме легко обучить несмышленных пользователей; Всего два-три дня истерик и ваши коллеги научатся внятно общаться;
- Сообщая вам в багрепорте, что именно ожидал увидеть пользователь, он тем самым как бы подтверждает, что он владеет системой и понимает, как она должна работать в данном случае;
- Такой багрепорт не мотивирует ответственное лицо заткнуть его в угол подальше и забыть поскорее;
А теперь — слайды
Типовая ошибка, которую заметил пользователь:
Не могу войти в систему
Что сделал:
1. Открыл http://www.something.com/
2. Кликнул на “логин”, увидел форму входа
3. Ввел “egor” в поле логина, ввел корректный пароль в поле пароля, кликнул на “вход”Что получил:
Белая страничка, адрес http://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 distributionType ‘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. Открыл http://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 голосов, средний: 4.67 из 5)
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
Чудная заметка. Дзенюкую бардзо.
Отличная статья прям в точку)
Было бы еще неплохо такую иметь в английском варианте для заказчиков, я бы перевел, но мой английский не файн (
Автору большой респект. Вопрос к автору: есть ли вариант этой статьи на английском, если есть - буду очень презнатен за ссылку.
Хммм… есть спрос на английскую версию. Я подумаю о переводе. Спасибо за позитивный фидбек)
Статья супер! Именно такую мордочку должны показывать пользователям багтрэкеры.
Хорошая статья, спасибо.
P.S. про пациента и анастезию - это ж явно эпиграф, а оформлен как цитата.
Хорошая статья. Нашёл для себя нечто новое, а именно - что название баг-репорта нужно лишь для того, чтобы отличать один баг-репорт от другого кроме как по номеру и содержанию (и в некоторых ситуациях можно обойтись без названий баг-репортов).
Кому интересно, небольшое уточнение:
Неправильное срабатывание софта это строго говоря не дефект. Это следствие дефекта.
Вот один и вариантов детальной классификации, которую можно встретить в литературе по тестированию:
- Error/Mistake - ошибка, сделанная человеком
- Defect/Fault/Bug - воплощение этой ошибки (например в документе с требованиями, конфигурациях или программном коде)
- Failure - неправильное функционирование софта в результате дефекта
А статья прикольная - на оч доступном языке и фраза об анестезии понравилась
А теперь ситуация:
Программист не вник в описание бага, не понимает с первого раза о чем баг-репорт (такое бывает, мысли читать еще не научились, равно как и нежелание работать или нет настроения или еще что-то), посылает багрепортера писать репорт правильно (как правило без уточнения что и как)
Результат:
1. количество фидбека резко снижается
2. качество продукта неуклонно падает, ибо кому приятно быть посланым
3. программиста увольняют за некачественный продукт/разрывают отношения с девелопментом
Решение - обе стороны двигаются планомерно не вокруг процедуры (а репортить надо отак бл, а не то что ты мне написал г-но !), а вокруг общей цели - улучшения качества продукта.
2Мрачный
>> Программист [...] посылает багрепортера
>> [...]
>> программсита увольняют
… А потому что не надо посылать. Не надо. Да и багрепортер должен фильтровать когда ему правильное замечание делают а когда - нет. И то что программистам не нравится что-то количество фидбека снижаться не должно. Так что приходим ко всем известной истине что работники должны быть нормальными. И программисты, и тестеры, и все остальные
Фантастика на втором этаже.
Ага. Но думаю цель статьи - не в том чтобы помочь всем. Это инфа. А кто сможет с её помощью себе помочь а кто нет - это другой вопрос
У статьи есть центрирование вокруг процедуры, а не вокруг оптимизации ресурсов и снижении времени на достижение результата. Процедура сама по себе хороша, важно понимать, что как только ее поднимут программисты как знамя (а они поднимут), то все будет плохо. Хорошо когда менеджер не программист и понимает деструктивность такого стереотипного мышления, а если программист ?
Вот и получаются такие продукты.
PS: капча всё время одинаковая, просит 9
капча - да
ну а тема статьи она и есть тема статьи. на другие темы есть другие статьи
Офтопик: Егорушка, это ж правда не ты вникал в это непотребное тормозное глюкало? Если вдруг по какому несчастному случаю ты — сильно рекомендую посмотреть на git (или хотя бы DSCM как таковые), другой вид спорта и мержи там — не бомжи.
Отличная заметка! Согласен с каждым пунктом.
В одной компании ответом на репорты а-ля “эта штучка не светит” была фраза из древнего анекдота - “Штурман, приборы”.
После того, как удивленный репортер прибегал/звонил за разьяснениями странного “шифра” - его заставляли записать 5 вопросов из списка выше и отправляли заново оформлять репорт.
При повторном звонке с вопросом “Какие такие приборы? Вы о чем?” - можно было нарваться на весьма нецензурно оформленное указание читать свои же записки.
Третьего вопроса “что за приборы?” - ещё ни разу не дождался
ничего нового, конечно, не написано
но все равно было интересно.
“правильные” багрепорты все равно получаются только после долгих исканий.
Например, у меня багрепорт - это
1. исходный файл, на котором проявляется проблема,
2. использовавшиеся настройки программы и
3. указание, на что именно смотреть.
Правда жизни.
Главное, не дать воспользоваться контраргументом “вы должны удовлетворить пользователя”.
Замечательно изложено. С моим опытом согласуется практически полностью.
2 Мрачный заказчик:
Контора должна обеспечивать корректные ответы программистов. Технически это весьма просто: project manager или кто там есть на должности руководителя проекта тоже просматривает эту переписку и дает по шапке слишком зарывающимся работникам. Или получает по шапке сам. Это же часть его работы. Если часть становится слишком большой - следует нанять чела на саппорт, и спрашивать с него.
Разработчик должен уважать и любить своего пользователя - ведь именно он в конечном счете дает деньги. (Исключения из правила рассматриваются в особом порядке и обсуждаются отдельно).
Но нужно заставить пользователя проявлять ответное уважение и помогать разработчику в решении общих проблем. Никакого противоречия не вижу. Несоблюдение этого простого принципа приводит к негативным результатам для всех учавствующих сторон.
Тем более пользователь - не злобный тиран, поставивший целью жизни максимально осложнить жизнь разработчику. Он, как правило, готов задавать правильные вопросы чтобы получить ожидаемый ответ в виде исправления/улучшения функциональности. Попытки научить задавать хорошие вопросы воспринимает положительно - или плохо учили.
Андрей,
Это только в том случае, если пользователь (человек) == заказчик (компания). А так бывает довольно редко.
И реально софт заказывает компания, а человек, реальный человек с реальными эмоциями, манал весь ваш прогресс далеко и надолго.
Ему надо чтобы его поменьше трогали и дали возмонжость спокойно дожить до пенсии, а тут новый софт какой-то зачем-то и еще и глючит, щас я этим горе-программистам покажу, уроды.
И вот тут рождаются кретинские багрепорты с перцем.
Егор, очень правильно, что ты наконец выжал всю шелуху о правилах баг-репорта, а отдельную короткую доходчивую статью. Вери сенкью, щас пошлю лин нашим киевским тестерам, а то они там преиодчески не понимают этих элементарных вещей.
Мне очень понравился совет Вадика Войтюка кодировать старую надоевшую резолюцию unable to reproduce или need more information в “Штурман, приборы” 
Я таки возьму это себе на вооружение. Я просто помню как сам работал тестировщиком и как меня Олег Золочевский гонял за неправильные баг-репорты. Не девелоперы и менеджеры, а мой непосредственный начальник. Теперь я уже пытаюсь втолковать некоторым куаям, что они пишут репорт не понятно. Жаль тока не до всех с первого раза доходит 
А причиной всему как раз то бессознательное ощущение превосходства, когда тестер получив баг, думает, что “вот же я такой хороший вижу баг, который сделал дурак программер, а он , этот дурак, еще и смеет мне говорить, что я не так зарепортил, что он не может его воспроизвести. Как он не может воспроизвести, если у меня он воспроизводится?!! Тестеру и не в домек, что это не проблема девелопера искать “как он может не воспроизвести”. При чем по многим причинам, одна из которых, девелопер всегда проверяет работу функционала только один раз, только на одной системе, только с одним набором данных и только на одном сервере. Короче ТОЛЬКО ОДНУ ситуацию из 100, 200 или 1000 возможных. И хорошо если вообще хоть раз проверяет. Иногда комитит вообще без проверки, если правил однотипный баг по всему коду в 100 местах, то он 100% не будет запускать код на выполнение во всех 100 местах чтобы обнаружить одну свою опечатку. Потому что ему платят не за тестирование, а за написание кода. А тестерам платят за проверку того что они написали во всяких возможных ситуациях, и проверка занимает больше времени чем кодинг, потому невыгодно заставлять заниматься этим программиста. Еще часта ошибка которую допускают тестеры, найдут баг, не могут его точно воспроизвести еще раз и все равно репортят с мыслями “ну девелоперу там в коде виднее где он наплужил”. Более дурацкого оправдания для недорепорта от профи-тестера я еще не слышал. Это принимается от любителя бета-тестера, но не от профессионала. Уфф.. шо та я дофига букв написал, буду закругляться.
jaguar, если баг не воспроизводится, то можно так и написать. Во всяком случае, если программист десять минут над ним помедитирует - хуже не будет, а лучше - запросто. некоторые баги ловятся мысленно. не очень частно, но есть.
Кстати, в оправдание тестерам можно поставить, что чаще всего они и не знают толком, как оно должно работать
ибо четка спека и написанные тест-кейсы - это в наших реалиях таки редкость 
Егор Егоров , когда ты 70% работы медитируешь на невоспроизводимыми багами, при чем не потому что их на самом деле, а просто потому что степсы описаны не полностью, это таки означает, что что то в процессе тестирования не так
Ваще таки если посмотреть лог моих комитов за последние пару месяцев на проекте и лог моих резолюций в мантисе, то можно заметить, что больше 60% фиксов я сделал без репорта issue, а потому что сам на них наткнулся по ходу проверки других багов, а больше 60% репортов issue я завернул с резолюцией unable to reproduce (и схожие по смыслу). Тут конечно виной не только низкий уровень тестеров, но и специфика отношений с заказчиком и специфика процесса разработки проекта в целом. Но факт есть факт. И качество тестирования, это то, на что я как девелопер могу повилять в первую очередь своими советами.
Твоя статья, Егор, в этом плане окажется очень полезной.
Под мэйнстримом имелось в виду, что при создании высоконагруженного сайта, наоборот, нужно забить на новые тенденции вроде RoR и Django и тупо кодить на PHP в любом случае.
Нічого принципово нового для себе в статті на побачив, але її цінність від цього не зменшується, особливо судячи з коментарів. Все написано правильно, від себе єдине що хотів би додати: частина “Что сделала. Конкретная пошаговая инструкция, что нужно сделать для того, чтобы воспроизвести дефект.” повинна бути якнайкоротшою, тобто кількість кроків, які ведуть до відтворення бага повинна бути мінімальною. Це, з одного боку економить час програміста на відтворення, а з іншого мотивує перед написання багрепорту глибше дослідити сам баг.
К такому стилю баг-репортов необходимо добавить пункт в договоре, согласно которому разработчик компенсирует ущерб,
нанесенный Программой интересам Заказчика. Ибо невоспроизводимый баг может случайно отправить не туда энную сумму денег
(если их перевод - это предмет деятельности программы).
И вообще, каждая область применения имеет свои законы жанра, и унифицировать их нужно осторожно.
При разработке финансовых систем с монетарной логикой вообще следует учитывать что в результате дефектов будут потеряны деньги. Поэтому в бюджет разработки заранее нужно закладывать пул денег под списание в результате багов.
Шигорин,
я и все мои коллективы используют subversion и счастливы. GIT это хорошо. Но мы используем subversion. 
Stas,
А я бы заметил, что многие баги, которые многие тестеры считают воспроизводимыми sometimes на самом деле имеют четкие степсы для их воспроизводства, но тестерам просто лень потратить пару часов на их поиск, потому они просто репортят их как sometimes. Это занаешь, как например баг проявляется только у неавторизованного юзера, а тестеру лень проверить его под авторизованным и неавторизованным и он репортит sometimes. Это конечно утрированный пример, но ты понял, что я хочу сказать.
А как у вас баги репортятся? Неужели, в текстовом виде или по электропочте?
Везде, где я видел, новый багрепорт - это заполнение формы с правильными вопросами. По-моему, если заполняющему знаком язык системы, то он/она быстро научатся всё делать правильно.
Руль! ) Особенно про пациента )
TO 29. Как раз при разработке финансовых систем и их отладке деньги не теряются.
Деньги просто становятся “реальными” после того, как система принята.
Хотя бывает, что выделяются небольшие деньги на контрольные закупки, которые потом подтверждаются
сданным товаром или являются вознаграждением полевого тестера.
С другой стороны - нужно больше денег и времени для тестирования, которое зачастую бывает строго
формальным - т.е. перебираются ВСЕ возможные воздействия и отклонения.
А пул денег для дерибана - идея хорошая, но не от этой темы…
> используют subversion и счастливы
Егор, запарит мерж — заглядывай в гости.
А за ссылку одни спасибы говорят, ну что такое!
Браво,
про внедрение такого подхода написана чистая правда.
К моему прискорбию… только так и работает. Мягкий подход наплодит ведро компромиссов и надолго отобьет желание совершенствовать процесс.
No pain - no gain
Среди врачей эту шутку принято переводить, как: “Не бывает плохой анестезии - бывает плохо привязанный больной”.
Кто там спрашивал на английском, можно найти здесь
Например
“В соответствии с нашими user stories письмом должен был прийти не новый пароль, а линк на страничку, на которой пользователь может сам создать себе новый пароль”
не коректна. В ней отсутвует ссылка на версию-раздел юзер-сториёв.
Вчера заказчик хотел так, сегодня так, а после завтра иначе. А потом девелопер на надцатом изменении багу закрыть забыл. А другой через месяц увидел и решил пофиксить закрывая по пинку ведущего все тикеты…
И что в результате получитЬ заказчик? ;o)
Вы извините, господа самоуважаемые программеры, но статья - типичное, эгоцентричное фуфло, под которое узколобый программер
пытается прогнуть весь мир. Юзер - это нежное, необременённое знаниями существо. Почему он обязан знать, какой у него браузер
(и что это вообще такое), какая у него версия и что он должен был получить, если он не видел правильного результата?
Вы слишком дохрена хотите, изнеженные офисом кнопочники. Хотите детальные репорты? УЧИТЕСЬ РАЗГОВАРИВАТЬ С ЛЮДЬМИ.
На общем, а не вашем профессиональном слэнге. Подсказки к репорту - хорошо, но даже тут статья облажалась - видно, что сосали её
из непонятного пальца. Баги имеют разные типы, могут НЕ иметь “ожидаемого результата”, могут иметь важные данные об условиях работы,
скриншоты, да много чего! Так что эта “фундаментальная троица” вопросов - вовсе не идеал “эффективного багрепорта”. Думайте, прежде чем
петь дифирамбы, а то создаёте ощущение студентов-самоучек.
2 Thorn: сэр просто болван или для начала сам не умеет разговаривать с людьми? Или честно-честно верит в спойлеры “как зажить щасливо” до последней буковки?
стыдно стало. да стыдно…
Попробую использовать.
спасибо.
Перевод этой статьи на английский язык: Priceless bugreports.