Anime-KPI

Пожалуйста, войдите или зарегистрируйтесь.

Расширенный поиск  

Новости:

Чем отличается вулканец от вулканийца? Тем же, чем и от вулканианца.

Автор Тема: Об эффективных багрепортах  (Прочитано 4257 раз)

0 Пользователей и 1 гость просматривают эту тему.

587

  • Модератор
  • *****
  • Карма: +2428/-112
  • Оффлайн Оффлайн
  • Сообщений: 10861
  • All your base are belong to us
    • Иконка твиттора
    • Просмотр профиля
    • Triskaidekaphilia
Об эффективных багрепортах
« : 02 Июня 2008, 14:35:25 »

Прекрасная статья, перепощу «на всякий случай», буду теперь на неё ссылаться, возможно, кому-то ещё пригодится:

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

Опубликовано 3.04.2008 в Статьи, Тестирование

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

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

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

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

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

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

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

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

Что сделала?
(Steps required to reproduce the problem)

Что получила?
(Actual results)

Что ожидала получить?
(Expected results)

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

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

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

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

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

А также:

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

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

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

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

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

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

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

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

    Что сделал:
    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 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. Открыл 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 коллективе будет ощущаться весьма. Багрепорт приносит прозрачность в работу, а прозрачность требует определённых усилий. Да и не каждому человеку в принципе под силу осознать, что такое «контекст» и почему собеседник его не понимает, ведь это же так просто, программа не работает, вот смотри.

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

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

Исходник: http://www.developers.org.ua/archives/egorfine/2008/04/03/effective-bug-reports/ (via)

Впрочем, сообщать об замеченных ошибках, как по мне, стоит в любом случае, возможно, разработчику нехватает именно ваших, пусть и не лучшим образом оформленных, сведений о них!..
« Последнее редактирование: 16 Июля 2009, 17:18:00 от Шаннар »
Записан
    nw: Aggretsuko, JoJo's Bizarre Adventure S01, Overlord S03
  • nr: Naruto (canon), Time Braid.
  • ng: Castle Wars, Bastion Siege, Pokemon Go, Borderlands 2, WoD: MtA, Go/Baduk
Не согласен — возражай.
Возражаешь — предлагай.
Предлагаешь — делай!
First message / Continue topic 

Antonz

  • * Отцы-основатели *
  • ***
  • Карма: +261/-11
  • Оффлайн Оффлайн
  • Пол: Мужской
  • Сообщений: 1472
  • Seen Anonymous?
    • Просмотр профиля
Об эффективных багрепортах
« Ответ #15 : 03 Июня 2008, 11:11:39 »

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

наоборот, оттого что по учёбе у нас слишком много рациональности, в жизни её остаётся даже меньше, чем у многих моих знакомых с "не очень техническими специальностями" )))
Это понятно и знакомо...
Записан
"Gentlemen, you can't fight in here! This is the War Room."

Tlia

  • Тюша
  • [Anime-KPI]
  • *****
  • Карма: +1173/-65
  • Оффлайн Оффлайн
  • Пол: Женский
  • Сообщений: 5550
  • танцующая в темноте (ц)
    • Мой статус
    • Просмотр профиля
Об эффективных багрепортах
« Ответ #16 : 03 Июня 2008, 11:14:50 »

Я уже про тонкости твоей работы думал, наверняка там будут формализованные процессы, лучше сразу привыкать, как ни крути.
так то, что они будут - это не страшно. главное, чтобы не только они. я же уже замечала выше - формальные элементы отлично выделяют и подчёркивают неформальные =) например, разграничение "работа-нерабочее время" =)
Записан
Спать/Тюша - мой новый старый ОТП
FAAAAAAAABULOUS~

Antonz

  • * Отцы-основатели *
  • ***
  • Карма: +261/-11
  • Оффлайн Оффлайн
  • Пол: Мужской
  • Сообщений: 1472
  • Seen Anonymous?
    • Просмотр профиля
Об эффективных багрепортах
« Ответ #17 : 03 Июня 2008, 11:42:34 »

Решил таки прочитать...

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

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

Это называется «баг репорт» (bug report), сообщение о дефекте. Это понятие пришло из области разработки программного обеспечения, но оно касается человеческого общения в целом. Не то чтобы это было очень уж важной частью нашей жизни, но для работы полезно знать, как обращать внимание людей и коллег на проблемы.
Многие баги имеют поначалу настолько странную и непостижимую природу, или же низкий reproduce rate, или самые разные ситуации в которых они возникают... в общем, очень неконкретны, что предпочтительнее время от времени сказать нужному человеку "а у тебя там что-то стучит", нежели пытаться завести официальный тикет (когда её сузят, тогда уже можно заводить). А если команда работает в одном офисе, то часто куча багов находится и решается вообще неофициально, в ходе неформального общения и "посиделок" друг у друга. В багтрекер же заносятся баги:
- засабмиченные левыми тестерами;
- когда человека нет на месте;
- когда это нужно для отчётности;
- когда долго не могут его починить, и полезно загнать в систему, дабы не забыть.

Всё это конечно зависит от применяемой методологии и от того, насколько построены процессы в компании. Я ещё значит не встречал компаний, где это доведено до упора (когда ты ни к кому и никогда не обращаешься с проблемой без формального багрепорта, заполненного  в системе).

А теперь — слайды
В общем, насчёт работы я не узнал ничего нового - у нас оно и так применяется. А за её пределами - спасибо, не надо.

Полная формализация тоже не нравится, она ведёт к стрессам, а при излишней фанатичности и к потерям времени (когда на "бумажно-электронную" волокиту тратишь больше чем на дела). Скажем, дневные репорты я ещё согласен писать (хотя недельные предпочтительнее, а ещё лучше автоматическое выгребание из version control/wiki/багтрекера). А вот отчитываться за каждый час рабочего времени и за небольшие опоздания - спасибо, не радует.

P.S. А тему таки стоит снести в Технологии.

P.P.S. Очень весёлое именно в моей области деятельности - манагить дезигнеров и строить их на предмет соответствия техническим требованиям. Дизайнер таки должен быть хорошо закреплён и вымуштрован. ;)
Записан
"Gentlemen, you can't fight in here! This is the War Room."

Шушпанчик

  • [Anime-KPI]
  • ****
  • Карма: +42/-5
  • Оффлайн Оффлайн
  • Сообщений: 322
  • Never give up.
    • Мой статус
    • Просмотр профиля
Об эффективных багрепортах
« Ответ #18 : 03 Июня 2008, 12:52:13 »

Я ещё значит не встречал компаний, где это доведено до упора (когда ты ни к кому и никогда не обращаешься с проблемой без формального багрепорта, заполненного  в системе).
Я зустрічав. Це не так жахливо, як здається. Принаймі, відповідальністю керувати так набагато легше. :)
Записан
[ісходник моєї аватарки] | [блог] | We live as we do to show the world what it could be...

587

  • Модератор
  • *****
  • Карма: +2428/-112
  • Оффлайн Оффлайн
  • Сообщений: 10861
  • All your base are belong to us
    • Иконка твиттора
    • Просмотр профиля
    • Triskaidekaphilia
Об эффективных багрепортах
« Ответ #19 : 16 Июля 2009, 17:23:42 »

«Маленькие шажки для людей» http://ay5.livejournal.com/256725.html

Ещё одна родственная, как по мне, тема, а именно — весьма неплохо иллюстрированная статья про написание инструкций: как оптимально писать оные, как сделать их более эффективными и полезными, какие стандартные ошибки совершаются и т. д. и т. п.
    nw: Aggretsuko, JoJo's Bizarre Adventure S01, Overlord S03
  • nr: Naruto (canon), Time Braid.
  • ng: Castle Wars, Bastion Siege, Pokemon Go, Borderlands 2, WoD: MtA, Go/Baduk
Не согласен — возражай.
Возражаешь — предлагай.
Предлагаешь — делай!

587

  • Модератор
  • *****
  • Карма: +2428/-112
  • Оффлайн Оффлайн
  • Сообщений: 10861
  • All your base are belong to us
    • Иконка твиттора
    • Просмотр профиля
    • Triskaidekaphilia
Как правильно составлять баг-репорты
« Ответ #20 : 26 Октября 2012, 12:00:16 »

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

Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.

Больше и детальней: http://habrahabr.ru/post/156099/ (via fox_mulder_cp)
Записан
    nw: Aggretsuko, JoJo's Bizarre Adventure S01, Overlord S03
  • nr: Naruto (canon), Time Braid.
  • ng: Castle Wars, Bastion Siege, Pokemon Go, Borderlands 2, WoD: MtA, Go/Baduk
Не согласен — возражай.
Возражаешь — предлагай.
Предлагаешь — делай!
 

Страница сгенерирована за 0.301 секунд. Запросов: 46.