Имея опыт работы в нескольких командах по тестированию ПО в различных проектах и компаниях, начиная от фриланса и заканчивая аутсорсинговыми и продуктовыми фирмами, я заметил такой факт, что в каждой команде отчет об ошибке пишется по своим традициям и стилям. При этом большинство тимлидов или ведущих QA-инженеров, которые эти традиции придумали, утверждают, что именно их стиль описания бага является наиболее правильным и максимально приближен к фен-шую. Нет, я не хочу сказать, что баг-репорты везде кардинально отличаются, нет, они приближены к стандартному виду с заголовком, шагами для воспроизведения, описанием ошибки и ожидаемым результатом, но от проекта к проекту имеют свой стиль. Например, подробность описания шагов воспроизведения (свое видение на эту тему я опишу в следующем посте), порядок расположения ожидаемого результата и описания ошибки и т.д. Молодые специалисты, прейдя на первый проект в своей жизни, воспринимают все традиции по ведению тестовой документации и тестированию как эталон, так как у них нет опыта и им не с чем этот процесс сравнить. Взяв за основу какой-либо стиль дизайна отчета об ошибке, при смене места работы на собеседовании могут возникнуть споры при ответе на вопрос: «Расскажите нам про дизайн баг-репорта», т.к. у команды, в которой вы хотите работать стиль описания может отличаться. Здесь важным моментом является не угадать этот самый стиль, а озвучив свой и услышав в его адрес критику, уметь обосновать свою точку зрения.
К делу
Итак, приступим. Часто я сталкивался с тем фактом, что члены команды очень болезненно реагируют на порядок расположения «Описания ошибки» («Description of error») и «Ожидаемого результата» («Expected result»). Одни считают, что первым делом должно быть рассказано о том, как должно правильно работать приложение, а после – что получаем на самом деле, другие же – наоборот. Я же придерживаюсь мнения второй группы и сейчас расскажу почему.
Открыв формочку заполнения информации о новом жителе баг-трекера, не стоит забывать с какой целью мы это делаем. Да-да, именно, мы пришли рассказать о нем всей команде разработчиков. И первым делом, мы будем рассказывать о том, какого красавца мы увидели на просторах тестируемого ПО и должны постараться донести его во всей красе со всеми подробностями. Очевидно, что в приоритете первыми в описании будут идти те детали, которые касаются непосредственно самой ошибки. Эти детали должны располагаться в той последовательности, в которой все желающие посмотреть на найденного «зверя» будут выполнять шаги для его полного воспроизведения. Поэтому первый аргумент за первоочередность расположения описания ошибки – это то, что выполнив шаги воспроизведения, программист или другой член команды должен увидеть что по этим шагам все таки получилось не так, а не то, как оно должно работать на самом деле.
Вторым аргументом является то, что члены команды (особенно программисты) по истечении нескольких недель уже более-менее ознакомлены со спецификацией продукта (если она есть) и приблизительно знают как он должен правильно работать. Поэтому им будет достаточно взглянуть на описание ошибки и сразу понять что не так и как оно должно быть, не читая раздел «Ожидаемый результат», что экономит какую-то долю времени, особенно если проект горит по срокам и вся команда стучит одновременною десятью пальцами по клавишам, стараясь в эти сроки вложиться.
Третий аргумент вытекает из второго, и суть его заключается только на уровне восприятия при поиске нужной информации в отчете. Известно, что не все баги содержат «Ожидаемый результат», например такие, где приложение не запускается вообще, если оно десктопное, или при заходе на страницу мы видим ошибку 500, если это web-сайт. В таком случае «Ожидаемый результат» типа «Application should work without error 500» или «Website index page shoud be displayed» несет только бесполезную информационную нагрузку, усложняя визуальное восприятие отчета об ошибке, и зачастую не вставляется в отчет. Так вот те, кто читает только шаги для воспроизведения и само описание ошибки, не заметят отсутствия блока «Expected result» и быстро переключатся на принятие дальнейших решений, когда он в баг-репортах расположен ниже блока «Error description».
Это лишь сугубо мое мнение и я могу уверенно сказать, что есть сотни людей, которые считают иначе или которые полностью согласятся, дополнив перечисленные выше три аргумента своими. Каждая команда работает по тем правилам и обычаям, которые ей удобны.