Home

Автор: Грег Готьер (Greg Gauthier)

Оригинал статьи: http://www.gmgauthier.com/advocacy-observation-and-the-future/

Перевод: Ольга Алифанова

Ученый, рассказчик, или официальный представитель?

Мне с трудом далась четвертая глава книги Джеймса Баха "Lessons Learned in Software Testing" ("В защиту багов"). Нет, она не была менее понятной или более интеллектуально насыщенной, чем первые три. Просто она полна противоречий.

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

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

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

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

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

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

Какой портрет более точный? Какую роль выбирать? Читая эту главу, определиться невозможно. На самом деле я вообще не уверен, что из этой главы можно извлечь некий универсальный принцип. Реальность такова, что иногда вы просто докладчик, а иногда - адвокат, и чтобы понять, какую роль сыграть, нужен опыт. Хотелось бы, конечно, чтобы Джеймс Бах и Кем Кейнер изложили чуть больше своих идей на этот счет.

Придерживайтесь правды

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

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

Как только вы теряете свою объективность, вы становитесь человеком с миссией. С вами нужно "справляться", вам нужно сопротивляться, вас нужно избегать, или, в лучшем случае, вас нужно подозревать в предвзятости. Бах сотоварищи осторожно намекают на это в уроках 65, 66 и 86, подчеркивая, что не надо использовать статистику багов для оценки производительности, и следует избегать эмоционально заряженных фраз, составляя баг-репорты. Однако они, похоже, не замечают, что в уроке 64 всплывает именно эта проблема, когда мы давим на заинтересованных лиц, чтобы заставить разработчиков делать то, чего они делать не хотят. На мой взгляд, этот подход не менее токсичен, чем упомянутое в уроках 72, 98 и 99 безразличие, благодаря которому смутные или неприятные баги растворяются в системе.

Ваша бесстрастность дает вам власть, которую вы не можете получить иначе. Даже авторы это признают - см. урок 84:

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

Новое платье тестировщика

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

Разработка ПО (как организационная деятельность) и тестирование (как дисциплина) серьезно развились с момента выпуска этой книги в 2002 году. Процессы и инструменты, которые сейчас используются для продвижения технологий и приложений, совершенно неузнаваемы по сравнению с тем, что применялось на заре Интернета. Большинство инструментов тогда были наследием 80-х и 90-х.

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

Именно в этом контексте мы получаем первый неявный урок - через уроки 91, 92 и 95 (и именно это стало отраслевым стандартом 10 лет спустя):

"Общайтесь с программистами, которые будут читать ваши репорты... Как только тестировщик находит баг, он подходит к программисту, отвечающему за эту область, и рассказывает о баге/демонстрирует его... Тестировщик может многому научиться у программиста. У программиста есть доступ к системе... пусть он разговаривает с вами, когда у него есть время... если фикс бага постоянно не срабатывает, обсудите это напрямую с программистом..."

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

Даже там, где Agile официально не используется, такой подход наблюдается очень часто. Я работал в американских, британских и европейских компаниях, где принцип "люди и коммуникации важнее процессов и инструментов" был принят неявным образом, иногда даже случайно, как наиболее эффективный подход к разработке ПО.

Наша задача

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

Тем не менее Бах, Кейнер и Петтифорд, кажется, предчувствовали, что такая трансформация была неизбежной, и завуалированно признают ее последствия в уроках вроде 69-го:

"Команды тестировщиков могут повысить эффективность оценки ошибок, нанимая людей с различным опытом. Тестировщик с отраслевым опытом... может лучше фокусировать свои тесты и разъяснения... Если один тестировщик умеет обращаться с базами данных, другой владеет сетевой безопасностью, а третий - эксперт в области UI, группа принесет ценный вклад в оценку багов системы..."

В современном мире тестировщикам недостаточно хорошего критического мышления и скептицизма. Они должны быть технически подкованы. Технологии и приложения экспоненциально выросли в плане сложности и запутанности со времен 16/32-битных компьютеров. Темпы перемен ускорились, и рыночные требования увеличились вместе с ними.

В этом новом мире тестировщики должны помнить о принципах Agile - "реагировать на изменения вместо того, чтобы следовать плану", и "работающее ПО вместо всеобъемлющей документации". На практике это означает, что различие между "тестировщиком" и "техническим тестировщиком" стерлось. Каждый тестировщик должен быть экспертом в чем-то. Он должен быть способен поднять сервер с нуля так же легко, как любой компетентный технарь. Он должен быть способен дебажить проблемный Java-класс так же легко, как любой опытный разработчик, и он должен знать инструменты, которые требуются для подобной работы. Такие вещи, как командная строка, системы контроля версий, дебаггеры и редакторы кода должны быть друзьями тестировщика.

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

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

Обсудить статью в форуме