Чтение онлайн

Трэйси: Мы хотели изменить культуру разработчиков Google, чтобы тестирование стало ежедневной обязанностью каждого программиста. Вначале мы просто делились положительным опытом в тестировании и уговаривали команды писать тесты. Некоторые заинтересовались, но не могли решить, с чего начать. Другие включали совершенствование тестирования в список квартальных целей. Обычно это так и оставалось только на бумаге, как постоянные обещания себе похудеть в следующем году. Хорошая, достойная цель, но если ее формулировать абстрактно, не удивляйтесь, если она так и не сможет обрести плоть.

Программа тест-сертификации помогает спланировать совершенствование тестирования по шагам. На первом уровне мы формируем основу: настраиваем фреймворк для запуска автотестов и собираем данные о тестовом покрытии, выявляем недетерминированные тесты и создаем пакет смоук-тестов, если полный тестовый пакет выполняется долго.

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

Теперь все сотрудники Google знают, что тестирование входит в обязанности разработчиков. Одной проблемой меньше. Но у нас остается задача помочь командам повысить навыки тестирования и научить их новым методам. Так что сейчас тест-сертификация направлена именно на это.

— Как оценивали разработчики тест-сертификацию на старте?

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

Марк: Да, нам пришлось отступить на несколько шагов назад. Мы постарались стать более реалистичными и увеличить длину взлетной полосы. Тем не менее, каким бы длинным ни был разгон, все равно для взлета надо развить порядочную скорость. Так мы сформулировали первый шаг: настроить непрерывную сборку, доводить хотя бы некоторые сборки до состояния «зеленый свет», определить покрытие кода. Это и так было у многих команд. Когда мы оформили это в правила, команды смогли сразу перейти на первый уровень и уже хотели работать дальше по программе.

— А кто принял вашу идею с энтузиазмом?

Нил: У нас организовалась группа ребят, заинтересованных в тестировании. Мы регулярно собирались. Потом мы стали приглашать знакомых коллег. Приятным сюрпризом оказалось, что многим инженерам это интересно. Интерес к программе вырос, когда мы стали применять «тестирование в туалете» [25] и другие штуки, которые делали тестирование более прикольным: «починялки», [26] массовая рассылка электронной почты, плакаты, выступления на пятничных встречах «Thanks God It’s Friday» и пр.

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

— Кто не хотел поддерживать ваше нововведение?

Нил: Большинство проектов. Как я уже сказал, всем казалось, что это слишком сложно. Мы должны были умерить свои начальные амбиции. По сути, в Google было два вида проектов: без тестов и с очень скверными тестами. Мы должны были показать тестирование как обычную рутину, с которой можно расправиться еще до обеда. И это было реально — с нашей помощью.

Марк: Кроме того, в то время в Google еще не было единого понимания ценности тестирования и автоматизации. Сегодня все по-другому. А тогда большинство команд полагало, что все эти идеи очень милые, но у них есть дела поважнее, а именно — писать код.

— Какие препятствия пришлось преодолеть, чтобы собрать единомышленников?

Нил: Инертность. Плохие тесты. Отсутствие тестов. Время. Тестирование рассматривалось как проблема кого-то другого — не важно, другого разработчика или тестировщика. Когда заниматься тестами, если нужно написать столько кода?

Марк: Пришлось искать команды, которые были бы достаточно заинтересованными и не имели особых проблем со старым кодом. В них должен был быть хотя бы один человек, который хотел заниматься тестированием и ориентировался в теме. Это были три основных препятствия, и мы последовательно преодолевали их, команда за командой.

— Как тест-сертификация стала популярной? Рост был вирусный или линейный?

Расс: Сначала мы прогнали пилотную версию на командах, которые дружили с тестированием, и на тех, кто помогал организовать программу. Мы тщательно выбирали свою аудиторию — привлекали команды с самыми высокими шансами на успех.

Когда мы объявили глобальный запуск тестовой сертификации в середине 2007 года, в Google уже было 15 пилотных команд, находящихся на разных уровнях. Перед запуском мы обклеили стены всех наших зданий в Маунтин-Вью плакатами «Что скрывает тест-сертификация». На плакатах были фотографии команд и внутренние названия проектов (Rubix, Bounty, Mondrian, Red Tape и т.д.). Мы сделали провокационные надписи типа «Будущее начинается сегодня» и «Это важно, не отставай» со ссылкой на программу. Мы получили огромное количество посещений от любопытствующих, которые хотели раскрыть тайну или подтвердить свои догадки. Мы задействовали «туалетное тестирование», чтобы прорекламировать программу и рассказать людям, где они могут узнать больше о проекте.

Мы объясняли, почему программа важна для команд и чем она им поможет. Мы подчеркивали, что команды получат наставника по тест-сертификации и доступ к сообществу экспертов тестирования. За участие в проекте команды получали два подарка. Первый — светящийся шар «статуса сборки», который показывал командам состояние тестов их непрерывных сборок в цвете: тесты прошли успешно — зеленый, не прошли — красный. Второй — комплект прикольных фигурок из «Звездных войн», который мы назвали «Дарт Тестер». Всего было три фигурки, и мы выдавали командам по одной по мере продвижения. Команды, на чьих столах появлялись такие шары и фигурки, вызывали любопытство и разговоры о программе.

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

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