Как тестируют в Google
Шрифт:
Будущее разработчика в тестировании
Если коротко, то мы думаем, что у разработчиков в тестировании нет будущего. Все-таки они — разработчики, и точка. Google платит им как разработчикам и оценивает их результаты по тем же критериям, что и разработчиков. Они даже называются одинаково — разработчики. Столько совпадений может говорить только об одном: это одна и та же роль.
Хотя роль, как нам кажется, обречена на вымирание, сама работа никуда не исчезнет. Эта деятельность — часть волшебной формулы успеха Google. Разработчики в тестировании обеспечивают тестируемость, надежность, возможность отладки и многое другое. Если мы будем рассматривать эти свойства как фичи продукта, так же как пользовательский интерфейс и другие функциональные компоненты, то разработчики в тестировании станут разработчиками, ответственными за реализацию
Сейчас эта часть процесса ущербна. Все пользовательские фичи официально управляются менеджером продукта, а создаются разработчиками. Код для этих фич управляется, и сопровождается, и поддерживается четкими автоматизированными процессами. При этом код тестов пишут разработчики в тестировании, а фактически управляют им инженеры по тестированию. Как так вышло? Это пережиток исторически сложившегося распределения ролей. Но эволюция не дремлет, и уже пора работать с кодом тестов так же, как и с кодом продукта: его должны писать разработчики, а управлять им должны менеджеры продукта.
Следующий вопрос: из каких разработчиков получатся хорошие разработчики тестов? Кому из них можно доверить ответственность за качество? Кто из них серьезно относится к этой работе? Что, если поступить наоборот? В Google, где роль разработчиков в тестировании давно устоялась, можно просто взять и одним махом превратить их всех в разработчиков. И тема закрыта. Но мы считаем, что это топорное решение. Каждый разработчик может выиграть от экскурсии в мир ответственности за фичи качества. [75] Тем не менее принуждать людей к этому несерьезно, да это и не в духе Google. Вместо этого ответственность за фичи тестирования должна отдаваться новым участникам команд, особенно менее опытным.
75
В Google есть программа подготовки инженеров по эксплуатационной надежности (SRE, Service Reliability Engineer), которая называется Mission Control. Разработчик, прошедший шестимесячную программу в роли SRE, получал приличную премию и кожаную куртку с эмблемой Google Mission Control.
Вот вам обоснование. Фичи тестирования — это срез всего продукта. Поэтому разработчики, которые их создают, изучают продукт сверху донизу, от пользовательских интерфейсов до API. Разве можно еще глубже погрузиться в продукт и изучить его строение и архитектуру? Ответственность за тестовую фичу, будь то построение ее с нуля, изменение или сопровождение, — прекрасный старт для любого разработчика в команде. Мы бы даже сказали — лучший старт. С приходом новых участников тест-разработчики освобождают им место и переходят на разработку функциональности. Ребята не застаиваются, и со временем все разработчики становятся подкованными в тестировании и уже серьезно относятся к качеству.
Для младших разработчиков и выпускников колледжа разработка тестов — самый удачный старт. Во-первых, они знакомятся с проектом в целом, во-вторых, большая часть тестового кода не участвует в выпуске, а значит, они далеки от давления и возможного стыда за баги, которые найдут пользователи. По крайней мере, на этом этапе карьеры.
Главное отличие этой модели с единой ролью в том, что экспертиза тестирования более равномерно распределена среди разработчиков. Сейчас же в Google, наоборот, все сконцентрировано у разработчиков в тестировании. Одно это важное изменение увеличило бы производительность, избавив нас от бутылочного горлышка в виде разработчиков в тестировании. Кроме того, отсутствие различий в должностях инженеров привело бы к свободным переходам от разработки тестов к разработке фич: один продукт, одна команда, одна роль.
Куда движется роль инженера по тестированию
Потребность в хороших тестировщиках как никогда высока. И все же мы думаем, что ее пик уже прошел. Традиционно тестировщики писали и выполняли тест-кейсы, проводили регрессионное тестирование. Но сейчас большая часть этой работы стала доступна в новых форматах, более полных и дешевых.
Большая часть новых возможностей появилась благодаря технологическому совершенствованию механизмов поставки программных продуктов. Во времена еженедельных или даже ежемесячных сборок и кропотливых интеграций важно было иметь под рукой
Подведем итог: кому бы вы доверили тестирование своего программного продукта? Высокооплачиваемым, нанятым экспертам по исследовательскому тестированию, которые всеми силами пытаются предугадать реальные сценарии использования, надеясь найти критические баги, или огромной армии настоящих пользователей, которые с горящими глазами ищут баги и сообщают о них? Общаться с реальными пользователями, готовыми искать баги в обмен на ранний доступ к продукту, еще никогда не было так просто. А с ежедневными или даже ежечасными обновлениями реальные риски для самих пользователей минимальны. В этом новом мире роль инженера по тестированию должна быть переосмыслена.
Мы думаем, что инженеры по тестированию станут проектировщиками тестов. Небольшое количество тест-дизайнеров будет оперативно планировать покрытие тестами, составлять тепловую карту рисков и туры для приложения (помните третью главу?). Получив обратную связь от доверенных тестировщиков, внутренних и ранних пользователей или краудсорсеров, тест-дизайнер оценит покрытие, пересчитает риски, убедится в их снижении и перераспределит активности. Тест-дизайнеры будут определять, где требуется специальная экспертиза по безопасности, конфиденциальности данных и производительности, а где — исследовательское тестирование, и передавать эту работу внешним специалистам. Их задачей будет создать или настроить инструменты для сбора и анализа всех входных данных. Им не придется ни создавать, ни выполнять тесты. Им не нужно будет тестировать. О’кей, может быть, «не нужно» — это слишком громкая фраза, но тестирования в работе тест-дизайнеров должно быть очень мало. Их работой будет проектирование, организация и управление ресурсами тестирования, которые по большей части бесплатны.
Мы думаем, что роль инженера по тестированию будет постепенно смещаться в сторону узкой специализации, например безопасности, или в сторону управления процессами тестирования, выполняемого другими. Это важная и серьезная должность, которая требует большого опыта. Возможно, она даже будет оплачиваться значительно выше, чем сейчас, но и людей на нее будет нужно намного меньше.
Что станет с тест-директором и тест-менеджером
Как все эти ролевые изменения отразятся на менеджерах, директорах и вице-президентах по тестированию? Их станет меньше. Те из них, у кого есть технические знания, перейдут на другие роли, более подходящие их инженерной специфике. Другие останутся идейными лидерами и будут координировать работу инженеров по тестированию и разработчиков (мы помним, что они теперь ориентированы на качество). Но они не будут управлять конкретным проектом и отвечать за его качество. За тестирование должны отвечать люди, непосредственно работающие с продуктами, а не централизованная организация, слабо связанная с продуктами и процессами разработки.
Будущее инфраструктуры тестирования
Инфраструктура тестирования в Google все еще клиентская. Множество тестов Selenium и WebDriver, написанных на Java или Python, хранится в репозитории, собирается и разворачивается на выделенных виртуальных машинах с помощью shell-скриптов. Тест-драйверы внедряют тестовую логику на Java в браузер, сами при этом выполняются как приложение в ОС. Решение работает, но инфраструктуру пора перестраивать, потому что этот метод требует дорогостоящих человеческих и машинных ресурсов для создания и выполнения тестов.