Правильный багрепорт 2: точность описания и исследование проблем

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

В прошлом посте про качество багрепортов я писал, как не забыть упомянуть в описании проблемы важную информацию, которая в момент описания бага кажется очевидной (для тестировщика, находящегося в контексте собственных действий). Я тогда предлагал простое техническое решение, которое напоминало, что помимо самой проблемы нужно еще упомянуть ряд параметров окружения и ожидания тестировщика от поведения приложения. Однако подобным образом можно перечислить только небольшой набор самых общих параметров, упоминание которых необходимо, но зачастую недостаточно для исследования/понимания сути проблемы. Набор данных, которые стоит упомянуть в описании проблемы, разнится от проблемы к проблеме - где-то достаточно сделать скриншот, где-то нужно добавить логи, нередко и в базу данных заглянуть полезно. Как же понять, что писать, а что нет? Ведь избыток информации тоже может запутать разработчика.

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

Важно докопаться до сути проблемы и акцентировать на ней внимание в багрепорте. Так, в случае особого поведения при специфических настройках, с точки зрения приложения все может быть верно: оно и должно так себя вести. И программист закроет баг как "инвалид" - ведь в программе проблемы нет. Однако в продукте проблема есть: документация должна явно сообщать о подобных зависимостях поведения приложения от настроек. Соответственно, если в багрепорте написано про нехватку описания работы программы, фокус багрепорта смещается с непосредственной работы приложения, и становится понятно, что хотя приложение и ведет себя правильно, баг продукта тем не менее присутствует.

Но как понять, в чем проблема? Как вообще догадаться, что нужно посмотреть в эти настройки? В сложных продуктах подобные зависимости могут быть не очень-то очевидными, и даже не упомянутыми в спецификациях. Подобные знания и чутье приходят с опытом - опытом "вообще" и опытом работы с данным конкретным продуктом. Но независимо от количества накопленной маны, полезно всегда помнить следующее: если ты сам не понимаешь, что происходит и почему, то скорее всего и описать проблему толком не сможешь. И прочитав подобный невнятный багрепорт, разработчик может понять его как-то по-своему и начать менять или исследовать нечто, о чем и вовсе речи не шло. 

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

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

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

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

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