Автор: Грег Готьер (Greg Gauthier)
Оригинал статьи: http://www.gmgauthie...and-the-future/
Перевод: Ольга Алифанова
Ученый, рассказчик, или официальный представитель?
Мне с трудом далась четвертая глава книги Джеймса Баха "Lessons Learned in Software Testing" ("В защиту багов"). Нет, она не была менее понятной или более интеллектуально насыщенной, чем первые три. Просто она полна противоречий.
Вопрос в моем подзаголовке очень волнует меня. В некотором роде тестировщик выполняет каждую из этих ролей. Ранее я уже говорил об этом. Однозначно ответить на этот вопрос невозможно. Крутой рассказчик может быть уважаемым ученым. А прекрасный ученый - интереснейшим рассказчиком.
Но тут всплывает более интересный вопрос - а как мы должны воспринимать сами себя, когда мы создаем и курируем свои баг-репорты? Бах, Кейнер и Петтикорд дают на это очень расплывчатый ответ.
Судя по главе в книге Баха, авторы рисуют два крайне различных - и очень противоречивых - портрета тестировщика. С одной стороны, это дисциплинированный, объективный, дотошный автор отчетов, который борется с желанием все преувеличить и выдает только голые факты, необходимые для принятия рациональных решений насчет реакции на баг-репорт.
"Вы информ-бюро... Ваша задача - сообщать о багах точно и внятно, чтобы читатель понял весь объем проблемы... Если вы преувеличиваете серьезность бага, вы утратите доверие... Ваша работа - сообщать о багах, а не выяснять, почему они произошли... старайтесь быть нейтральным... Не настаивайте на фиксе каждого бага, расставляйте приоритеты..."
С другой стороны, тестировщик отстаивает баги, вкладывается в них эмоционально, и мотивирован бороться за них из политических соображений. Он готов использовать свое влияние в офисе через головы коллег, чтобы вопросы исправления багов решались так, как нужно ему.
"Любой баг-репорт - это адвокатская речь, призывающая к исправлению этого бага... это инструмент продаж, его цель - убедить людей... вы можете обнаружить сравнительно минорный баг и, исследуя его, узнать о серьезных последствиях... Чтобы баг исправили, вам нужно заставить всех ответственных за контроль изменений одобрить это исправление... Если убедить разработчиков сложно, но вы считаете, что баг надо исправить, подумайте, кому в компании еще выгодно исправление этого бага..."
Какой портрет более точный? Какую роль выбирать? Читая эту главу, определиться невозможно. На самом деле я вообще не уверен, что из этой главы можно извлечь некий универсальный принцип. Реальность такова, что иногда вы просто докладчик, а иногда - адвокат, и чтобы понять, какую роль сыграть, нужен опыт. Хотелось бы, конечно, чтобы Джеймс Бах и Кем Кейнер изложили чуть больше своих идей на этот счет.
