Джеймс Уиттакер: Как тестируют в Google

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

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

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

Тестировщики, к моему удивлению, реагировали аналогично. Они привыкли к текущему состоянию дел, охотно оплакивали свой статус, но не торопились его менять.

Когда я пожаловался своему начальнику, он сказал: «Это Google. Если ты хочешь, чтобы что-то было сделано, — сделай это».

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

Первые несколько месяцев были самыми тяжелыми. В процессе проверки часто отбраковывались неплохие кандидаты. Возможно, они недостаточно быстро решали какую-нибудь хитроумную задачу по программированию или плохо проявляли себя в области, важной для интервьюера, но на самом деле не имеющей никакого отношения к навыкам тестирования. Я знал, что с наймом у нас будут проблемы, и каждую неделю строчил докладную за докладной. Они уходили Ларри Пейджу, который был (и остается) последней инстанцией в процессе найма. Он утвердил достаточное количество кандидатов, и моя команда начала расти. Я иногда думаю, что мое имя у Ларри ассоциируется только с фразой «Нам нужны тестировщики!».

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

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

Команды разработчиков испытывали сильное давление. Google начал покупать компании со своими веб-приложениями (YouTube, Google Docs и прочие), которые только усиливали нагрузку на нашу внутреннюю инфраструктуру. Проблемы, с которыми я сталкивался в тестировании, не уступали проблемам, с которыми сталкивались разработчики при написании кода. Я пытался решить проблему тестирования, которую просто невозможно было решить отдельно от разработки. Рассматривать тестирование и разработку как обособленные дисциплины или даже как разнородные задачи было в корне неверно, и мы не могли решить ни одну из проблем. Улучшение команды тестирования стало бы всего лишь временным успехом.