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

Альберто Савоя— директор по разработке и популяризатор инноваций в Google. Он пришел в компанию в 2001 году и возглавил выпуск Google AdWords, а кроме того, сыграл ключевую роль в развитии культуры разработки и юнит-тестирования в компании. Он написал книгу «The Way of Testivus» и раздел «Beautiful Tests» в книге издательства O’Reilly «Beautiful Code».

Примечание от Джеймса Уиттакера:Согласен на все сто! Я ничего не придумывал, просто пересказал схему организации, которую создал Патрик. И я говорю это не потому, что он разрешил мне написать эту книгу. Как мой начальник, он заставил меня написать ее!

Мое приключение в Google началось в марте 2005 года. Если вы прочитали вступление Альберто, то вы уже примерно представляете, что тогда происходило в компании. Google был еще маленький, но в нем уже начали проявляться признаки болезни роста. Это было время стремительных технологических изменений: на замену клиент-серверной модели приходили динамический контент и облачные технологии.

В первую неделю я, как и остальные новички, сидел в фирменной трехцветной кепке с пропеллером, слушая, как основатели компании обсуждают корпоративную стратегию на еженедельном собрании «Thanks God, It’s Friday». Тогда я еще не понимал, во что влип. Я был наивен настолько, чтобы испытывать энтузиазм, и достаточно опытен, чтобы начать подозревать неладное. Мой предыдущий опыт с пятилетними циклами разработки продукта выглядел не очень убедительно по сравнению со скоростью роста и масштабами Google. Что еще хуже, я был единственным тестировщиком в кепке новичка. Я надеялся, что где-то есть и другие!

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

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

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

Мне бы очень хотелось сказать, что я воспользовался своим огромным опытом и с ходу выдал идеальный механизм организации тестирования. Но, честно говоря, мой опыт научил меня только тому, как делать не надо . Каждая структура тестирования, в которой я участвовал (или которую возглавлял), была по-своему ущербной. В ней всегда что-то работало плохо: иногда код, иногда тесты, иногда сама команда. Я отлично знал, как можно оказаться погребенным под грудой технических и качественных проблем, когда каждая новая идея с ходу отвергается, если она хоть немного угрожает хрупкому проекту. Если я чему-то и научился к этому времени, так это тому, как не нужно проводить тестирование.

Я уяснил одно: Google уважает компьютерные технологии и искусство программирования. Если тестировщики хотят влиться в эту компанию, они должны быть технически грамотными и уметь писать код. Только так остальные инженеры будут воспринимать тестировщиков равными себе.

Ну и уж если я собрался что-то менять в структуре тестирования Google, то начинать надо было с самих тестировщиков. Я представлял идеальную команду и то, как она будет обеспечивать качество, и все время возвращался к одному очень важному условию: команда может сделать качественный продукт только в том случае, если за качество отвечают все ее участники. Менеджеры, разработчики, тестировщики… все. Мне казалось, что лучший способ это обеспечить — превратить тестирование в фичу кода . Фича «тестирование» должна была обладать теми же правами, что и любая другая фича, которую может увидеть пользователь. А для создания фич нам нужен разработчик.

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

К сожалению, мало кто в компании разделял мой энтузиазм по поводу столь принципиальных и фундаментальных изменений. Рассказывая о своем подходе «все будет точно так же, только по-другому», я обнаружил, что мне стало труднее найти компанию для обеда! Разработчиков, казалось, пугала мысль о том, чтобы играть более важную роль в процессе: «А тестировщики нам зачем?» Тестировщики тоже не горели желанием менять привычный стиль работы. Попытки что-либо изменить сталкивались с сильным сопротивлением.

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