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

Патрик Коупленд — старший директор направления продуктивности разработки, вершина пирамиды тестирования в Google. Все тестировщики в компании подчиняются Патрику, а его руководителем, кстати, является Ларри Пейдж, соучредитель и исполнительный директор Google. Карьере Патрика в Google предшествовала почти десятилетняя работа в Microsoft на должности директора по тестированию. Он часто выступает публично и известен как архитектор используемой в Google технологии быстрой разработки, тестирования и развертывания ПО.

Предисловие

Разрабатывать программные продукты сложно. Тестировать эти продукты тоже сложно. Когда кто-то говорит о разработке и тестировании в масштабах веб, он подразумевает Google. Если вы хотите узнать, как в одной из самых известных интернет-компаний решаются проблемы тестирования в грандиозных рамках всей Сети, то вы держите в руках правильную книгу.

В Google ежедневно тестируются и выпускаются сотни миллионов строк кода, распределенного по миллионам исходных файлов. Миллиарды операций по сборке запускают выполнение миллионов автоматизированных тестов в сотнях тысяч экземплярах браузеров ежедневно. Операционные системы строятся, тестируются и выпускаются в пределах одного календарного года. Браузеры собираются ежедневно. Веб-приложения выпускаются почти непрерывно. В 2011 году сто новых фич Google+ были выпущены за сто дней.

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

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

Специалисты этой области получали меньше, хотя и работали больше. Тестирование в основном было ручным, а люди, которые могли автоматизировать процесс, быстро переходили в разработчики, где они могли «приносить больше пользы». Основателям команды, которая сейчас называется направлением продуктивности разработки, пришлось продираться сквозь заблуждения о тестировании и корпоративную культуру, ставившую героические авралы на работе выше повседневной инженерной рутины. Сегодня зарплата тестировщиков Google соразмерна зарплате разработчиков, их премии и темпы карьерного роста сравнялись. То, что культура тестирования пережила непростой рост компании (по всем параметрам — количеству, разнообразию продуктов и объемам продаж) и структурные реорганизации, должно придать уверенности компаниям, которые решат следовать примеру Google. Тестирование можно организовать правильно. Добиться вменяемого отношения к нему со стороны разработчиков и руководства — реально.

Сейчас все больше компаний делает ставку на веб, поэтому технологии тестирования и организационная структура, описанные в этой книге, могут получить широкое распространение. Если вы с нами — читайте, эта книга объяснит вам, как добраться до цели.

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

Остальные главы можно читать в любом порядке. Сначала мы расскажем о роли разработчика в тестировании (Software Engineer in Test, SET), потому что с нее началось современное тестирование в Google. Разработчик в тестировании — тестировщик с высокой технической квалификацией, поэтому в этой главе много технических подробностей. Но мы постарались подать их в более общем ключе, чтобы основные концепции понял даже неподготовленный читатель. В следующей главе мы познакомимся с инженером по тестированию (Test Engineer, TE). Глава получилась большой, потому что обязанностей у инженера по тестированию много. В Google эти специалисты решают уйму разных задач на протяжении всего цикла разработки продукта. Эта роль хорошо знакома многим традиционным тестировщикам. Скорее всего, этот раздел книги будет максимально востребован, потому что он адресован самой широкой аудитории.

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