Философия бага – описание ошибки

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

Молодые специалисты, прейдя на первый проект в своей жизни, воспринимают все традиции по ведению тестовой документации и тестированию как эталон, так как у них нет опыта и им не с чем этот процесс сравнить. Взяв за основу какой-либо стиль дизайна отчета об ошибке, при смене места работы на собеседовании могут возникнуть споры при ответе на вопрос: «Расскажите нам про дизайн баг-репорта», т.к. у команды, в которой вы хотите работать стиль описания может отличаться. Здесь важным моментом является не угадать этот самый стиль, а озвучив свой и услышав в его адрес критику, уметь обосновать свою точку зрения.


К делу

Итак, приступим. Часто я сталкивался с тем фактом, что члены команды очень болезненно реагируют на порядок расположения «Описания ошибки» («Description of error») и «Ожидаемого результата» («Expected result»). Одни считают, что первым делом должно быть рассказано о том, как должно правильно работать приложение, а после – что получаем на самом деле, другие же – наоборот. Я же придерживаюсь мнения второй группы и сейчас расскажу почему.

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

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

Третий аргумент вытекает из второго, и суть его заключается только на уровне восприятия при поиске нужной информации в отчете. Известно, что не все баги содержат «Ожидаемый результат», например такие, где приложение не запускается вообще, если оно десктопное, или при заходе на страницу мы видим ошибку 500, если это web-сайт. В таком случае «Ожидаемый результат» типа «Application should work without error 500» или «Website index page shoud be displayed» несет только бесполезную информационную нагрузку, усложняя визуальное восприятие отчета об ошибке, и зачастую не вставляется в отчет. Так вот те, кто читает только шаги для воспроизведения и само описание ошибки, не заметят отсутствия блока «Expected result» и быстро переключатся на принятие дальнейших решений, когда он в баг-репортах расположен ниже блока «Error description».

Это лишь сугубо мое мнение и я могу уверенно сказать, что есть сотни людей, которые считают иначе или которые полностью согласятся, дополнив перечисленные выше три аргумента своими. Каждая команда работает по тем правилам и обычаям, которые ей удобны.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 16

    +13
    похоже на старые споры типа, как креститься — слева на право или с право на лево :)
      0
      Так оно и есть, но когда я пришел без опыта на первую свою работу тестировщиком и меня периодически кидали с проекта на проект на подмогу, то тимлиды постоянно пытались переучить под свой стиль, причем для них этот вопрос был довольно-таки принципиальный…
        +10
        я ставлю скобки так:
        for(;;)
        {
        }

        if(var)
        {
        }
        +5
        Проблема выглядит высосанной из пальца, но как и многие так выглядящие проблемы порождает крупные холивары. Лично я согласен с автором по всем пунктам, как и с тем что в каждом проекте желательно придерживаться единообразия, чтобы не искать нужные логические элементы каждый раз в новом месте. Думаю если ты пришёл в чужой монастырь, а там желаемый результат пишут первым, то максимум, что можно сделать это предложить правильный, с твоей точки зрения вариант, и смирившись с отказом писать как пишут остальные и не ерепениться.
          0
          У каждого свое.
          Я привык к тому, что с теми разработчиками, с которыми я работаю — к каждому есть свой подход. Кому-то нужно расписывать баг по всем степам, со всеми пунктами, и т.д., а кому-то просто написать «там-то не работает то-то» и все. Это точно экономит кучу времени ввиду того, что разработчик знает свой кусок проекта, и мое время на детальное описание бага.
            –2
            В зависимости от того, как распределена команда. Например, сейчас я работаю на проекте, где все сидят в одной комнате: программисты, тестировщики, менеджеры, дизайнеры. Поэтому баг-репорты можно описывать поверхностно не вдаваясь в детали. Когда же я работал там, где тестировщики в одном офисе в Украине, программисты в Индии, а менеджеры в Англии, то тут проще будет полностью все расписать со всеми деталями и вытекающими, чем потом по скайпу объяснять отдельно в случае каких-то неясностей.
              0
              Считаю такой подход совершенно неправильным. Чтоб не отвлекать друг-друга от работы проще один раз все подробно расписать, чем потом несколько раз переспрашивать причем иногда одно и то же, т.к. когда на тебе висит, допустим, 50 багов, которые нормально не расписаны, то далеко не каждый сможет постоянно держать правильную и полную информацию по каждому из них, что опять таки ведет к отвлечению от работы тебя самого, потере времени.
            0
            кстати, а вы за описание багов на английском или русском? Понятно, что все сильно зависит от клиента, если он англоговорящий и ходит в баг-трекер, то должно быть понятно первым делом ему. Но почему-то многие QA инженеры владеют просто отвратительным английским (многие и русским :( ) и описания багов сводятся к предложениям типа «Нажимать на кнопка» (в дословном переводе). Ваше мнение?
              0
              это проблема не только QA инженеров(
                0
                да, но почему-то именно с ними это часто видно, ибо описания багов заносят рядовые инженеры, а не менеджеры, которые просто в силу опыта уже обладают более-менее сносным английским!
                0
                Я за английский, т.к. по большому счету вся компьютерная терминология на нем, хотя сейчас работаю на проекте, где заказчик требует всю документацию и названия исключительно на русском. Даже во время тренингов по Scrum просил переводить такие термины, как Product Backlog(продуктовый заднесписок), Product Owner(властелин продукта).
                +3
                Какой-то бред. В начале статьи поставлены глобальные вопросы о дизайне дефектов, а под катом детский лепет о правильной позиции ожидаемого результата. Есть куча интересных ситуаций, в которых действительно возникают вопросы о правильном дизайне дефекта в конкретном случае, но вот чтобы кто-то ругался по поводу положения expected result, которого, к слову, во многих случаях вообще не должно быть, — такое я встречаю впервые.

                Не удивлюсь, что прежде чем потратить полчаса на написание поста на хабре, автор (будучи, вероятно, менеджером тестовой группы) целый час парил эту чушь на статус митинге с разрабами и менеджером проектов. Инмайхамблопинион, вам просто нечем заняться.
                  –2
                  Честно, идея возникла написать пост, когда умнки с других проектов приходили и начинали доставать своим «феш-шуем». После подобных изъяснений успокаивались и тихо с миром уходили. Будучи на данный момент PM'ом, комманды работают спокойно и подобных споров ни у кого не возникает.
                  P.S. Философам тоже нечего было делать, вот они и размышляли.
                    0
                    А вот за P.S. — отельное фе. От меня как профессионального философа по диплому и тестировщика ПО по роду деятельности.
                  0
                  Пишите шаги, ожидаемый и актуальный результат в разных полях баг-трекера. Допилите его, если он этого не умеет, что бы он позволял настроить порядок следования этих полей.
                    0
                    Жизнь обычно все расставляет по своим местам.
                    Когда баг начинающего тестировщика девелопер завернет пару раз, поскольку «не смог воспроизвести» или «необходимы дополнительные данные о пользователе», — быстро научиться писать как надо. Ну или не задержится надолго, поскольку наука не бог весть какая сложная, чтобы еще по таким вопросам митинги собирать. Где-то скриншота достаточно, где-то — заголовок раскрытия не требует. А есть баги, где и условия воспроизведения заковыристые, и аналитика по числу пострадавших пользователей требуется, и и подборка ссылок на предыдущие баги есть они взаимосвязаны.

                    У нас ввели в качестве стандартного темплейта список вида:
                    Environment:
                    Browser:
                    User name:
                    Membership ID:
                    Screenshot:
                    Steps to reproduce:

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

                    Only users with full accounts can post comments. Log in, please.