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

Однако компания росла, и наши продукты становились все более значимыми для пользователей и клиентов. Возьмем хотя бы AdWords: один из сервисов, за которые я отвечал, он быстро превращался в основной источник монетизации веб-сайтов. Пришло время пересмотреть свой подход к тестированию и увеличить инвестиции в эту область. Имея в арсенале только трех тестировщиков, мы не нашли других вариантов, кроме как попытаться вовлечь в тестирование разработчиков. Я и еще несколько сотрудников Google продвигали, развивали и обу­чали юнит-тестированию. Мы агитировали разработчиков начать писать тесты и использовать хотя бы JUnit для их автоматизации. Переход шел со скрипом. Идея тестирования собственного кода не вызывала у разработчиков ажиотажа. Для стимулирования сотрудников каждую пятницу на наших пивных вечеринках с говорящим названием «Thanks God, It's Friday!» я награждал разработчиков, которые писали тесты. Я напоминал дрессировщика, который дает собачкам лакомство за выполненный трюк, но, по крайней мере, это привлекало внимание к тестированию. Неужели мне повезло, и я смог заманить разработчиков в тестирование конфетками?

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

К чему такая спешка? Я не верю, что даже самое изощренное тестирование может привести к успеху изначально неудачную идею или непродуманный продукт. Но я верю, что плохое тестирование может загубить хороший продукт, компанию или, по меньшей мере, сможет замедлить ее рост и предоставит фору конкурентам. Это как раз портрет Google того времени. Мы были на пути к успеху, и только проблемы в тестировании удерживали компанию от решающего шага в светлое будущее. Нужно было выработать верные стратегии тестирования, адекватные нашим сверхзвуковым скоростям роста числа пользователей, продуктов и сотрудников. Мы вовсю применяли инновационные решения, нестандартные подходы и уникальные инструменты — нам нельзя было замедляться. Конечно, не все работало. Но в процессе мы получили ценные уроки и научились практикам, которые теперь может применить любая компания, желающая развиваться со скоростью Google. Мы поняли, как сохранить баланс между качеством продукта и скоростью разработки, не теряя ни в чем. Эта книга рассказывает о процессе, к которому мы пришли, о том, какие идеи лежат в его основе, и почему он работает. Если вы хотите понять, как Google справляется с проблемами тестирования в XXI веке, в среде современных интернет-, мобильных и клиентских приложений — вы обратились по адресу. Конечно, я хотел бы оказаться тем человеком, который рассказал бы вам все это, но Джеймс и его соавторы уже сделали это за меня. Главное, что им удалось передать суть тестирования в Google.

И последняя ремарка: Джеймс Уиттакер — человек, благодаря которому эта книга написана. Он пришел в Google, проникся нашей культурой, взялся за большие и важные проекты, выпустил такие громкие продукты, как браузер Chrome, операционная система Chrome OS и десятки других поменьше. В какой-то момент он стал лицом тестирования в Google. В отличие от его других книг, в этой — большая часть материала не его авторства, он скорее выступил в роли корреспондента с места события и представил свой репортаж об эволюции тестирования ПО в Google. Помните об этом, читая книгу, потому что Джеймс наверняка постарается прибрать всю славу себе!

Пока население Google росло с 200 до 20 000 сотрудников, было немало людей, которые оставили свой след в разработке и благодаря которым наши идеи тестирования живут. Джеймс благодарит многих из них. Они появляются на страницах книги в отступлениях и интервью. Тем не менее ни я, ни Джеймс не сделали так много, как Патрик Коупленд — архитектор нашей текущей организационной структуры и руководитель направления продуктивности разработки Google. Все тестировщики Google подотчетны Патрику. Это его видение реализовалось в наших подходах и вот теперь описано в этой книге Джеймсом. Если есть человек, благодаря которому тестирование ПО в Google организовано именно так, то это Патрик… Я говорю это не просто потому, что он мой начальник. Я говорю это потому, что он мой начальник, а еще он приказал мне это сказать!