Уиттакер . - Как тестируют в Google

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

Вот вам обоснование. Фичи тестирования — это срез всего продукта. Поэтому разработчики, которые их создают, изучают продукт сверху донизу, от пользовательских интерфейсов до API. Разве можно еще глубже погрузиться в продукт и изучить его строение и архитектуру? Ответственность за тестовую фичу, будь то построение ее с нуля, изменение или сопровождение, — прекрасный старт для любого разработчика в команде. Мы бы даже сказали — лучший старт. С приходом новых участников тест-разработчики освобождают им место и переходят на разработку функциональности. Ребята не застаиваются, и со временем все разработчики становятся подкованными в тестировании и уже серьезно относятся к качеству.

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

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

Куда движется роль инженера по тестированию

Потребность в хороших тестировщиках как никогда высока. И все же мы думаем, что ее пик уже прошел. Традиционно тестировщики писали и выполняли тест-кейсы, проводили регрессионное тестирование. Но сейчас бˆольшая часть этой работы стала доступна в новых форматах, более полных и дешевых.

Большая часть новых возможностей появилась благодаря технологическому совершенствованию механизмов поставки программных продуктов. Во времена еженедельных или даже ежемесячных сборок и кропотливых интеграций важно было иметь под рукой тестировщиков, которые умели искать баги, имитируя поведение пользователей. Разумеется, баги нужно было найти до того, как продукт попадет в руки миллионов людей, когда трудно будет отслеживать дефекты и накатывать обновления. Эти времена давно прошли. Распространение приложений через веб позволяет выпускать продукт для ограниченного числа пользователей, получать от них обратную связь и быстро обновлять продукт. Препятствий для общения разработчиков с пользователями больше нет. Срок жизни багов уменьшился с нескольких месяцев до нескольких минут. Механизмы распространения и получения обратной связи настолько хороши, что мы пишем, выпускаем, исправляем и снова выпускаем продукт быстрее, чем большая часть аудитории успевает заметить дефект. Мы можем дать продукт только группе доверенных тестировщиков или внутренних пользователей, найти ранних последователей или выкатить для всей аудитории. Какое место в этой схеме занимает команда профессиональных инженеров по тестированию? Пользователи гораздо лучше защищены от проблем, чем раньше, поэтому настало время перераспределить наши ресурсы тестирования.

Подведем итог: кому бы вы доверили тестирование своего программного продукта? Высокооплачиваемым, нанятым экспертам по исследовательскому тестированию, которые всеми силами пытаются предугадать реальные сценарии использования, надеясь найти критические баги, или огромной армии настоящих пользователей, которые с горящими глазами ищут баги и сообщают о них? Общаться с реальными пользователями, готовыми искать баги в обмен на ранний доступ к продукту, еще никогда не было так просто. А с ежедневными или даже ежечасными обновлениями реальные риски для самих пользователей минимальны. В этом новом мире роль инженера по тестированию должна быть переосмыслена.

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

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

Что станет с тест-директором и тест-менеджером

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