Как тестируют в Google - [2]
Как я уже сказал, он хитрый малый.
Ну, поехали… предисловие к книге, которую я хотел бы написать сам. Звучит трогательная свадебная музыка.
Нужна ли миру еще одна книга по тестированию ПО? Особенно если это еще одна книга по тестированию ПО, написанная плодовитым Джеймсом Уиттакером, которого я зову «октомамой»[1] книг по тестированию? Разве мало книг, раздающих сомнительные и устаревшие советы по методологии тестирования? Да, таких книг достаточно, но это произведение, боюсь, к ним не относится. Вот почему я хотел бы написать его сам. Миру действительно нужна именно такая книга по тестированию.
Интернет значительно изменил подход к проектированию, разработке и распространению программных продуктов. Многие передовые методы тестирования, описанные в книгах прошлых лет, сейчас уже неэффективны, иногда вообще бесполезны, а в некоторых случаях даже вредны. В нашей отрасли условия меняются очень быстро. Книги, написанные пару лет назад, уже похожи на древние медицинские манускрипты по лечению пиявками и сверлению дырок в черепе для изгнания злых духов. Такие книги лучше переработать в подгузники для взрослых, чтобы они не попадали в руки доверчивых неофитов.
Развитие отрасли разработки ПО идет семимильными шагами, и я не удивлюсь, если через десять лет эту книгу тоже можно будет пустить на подгузники. Но пока не произошла очередная смена парадигмы, книга «Как тестируют в Google» дает очень своевременный и практичный взгляд на то, как одна из самых успешных и быстро развивающихся интернет-компаний справляется с уникальными задачами тестирования в XXI веке. Джеймс Уиттакер и его соавторы ухватили самую суть того, как Google успешно тестирует одни из самых сложных и популярных программных продуктов нашего времени. Я наблюдал становление отрасли и знаю, о чем говорю.
В 2001 году я присоединился к Google в качестве директора по разработке. Тогда у нас было около двухсот разработчиков и… целых три тестировщика! Мои разработчики уже тестировали свой код сами, но метод TDD (Test-Driven Development, разработка через тестирование[2]) и средства автоматизации тестирования (такие как JUnit) только делали свои первые шаги. Поэтому наше тестирование было по большей части случайным и зависело от добросовестности разработчика, написавшего код. Но это нормальная ситуация для стартапа. Нам нужно было двигаться быстро и не бояться рисковать, иначе мы бы не смогли конкурировать с матерыми игроками нашей отрасли.
Однако компания росла, и наши продукты становились все более значимыми для пользователей и клиентов. Возьмем хотя бы AdWords: один из сервисов, за которые я отвечал, он быстро превращался в основной источник монетизации веб-сайтов. Пришло время пересмотреть свой подход к тестированию и увеличить инвестиции в эту область. Имея в арсенале только трех тестировщиков, мы не нашли других вариантов, кроме как попытаться вовлечь в тестирование разработчиков. Я и еще несколько сотрудников Google продвигали, развивали и обучали юнит-тестированию. Мы агитировали разработчиков начать писать тесты и использовать хотя бы JUnit для их автоматизации. Переход шел со скрипом. Идея тестирования собственного кода не вызывала у разработчиков ажиотажа. Для стимулирования сотрудников каждую пятницу на наших пивных вечеринках с говорящим названием «Thanks God, It's Friday!» я награждал разработчиков, которые писали тесты. Я напоминал дрессировщика, который дает собачкам лакомство за выполненный трюк, но, по крайней мере, это привлекало внимание к тестированию. Неужели мне повезло, и я смог заманить разработчиков в тестирование конфетками?
К сожалению, нет. Идея с поощрением не сработала. Разработчики поняли, что для создания нормальных тестов им нужно писать две-три строки кода юнит-тестов на каждую строку тестируемого кода. Вдобавок тесты тоже нужно сопровождать, и в них самих могут заводиться баги. Стало очевидно, что одними разработчиками в юнит-тестировании сыт не будешь. Нам нужны были интеграционные тесты, системные тесты, тесты пользовательского интерфейса и прочие полезные штуки. Нам предстояло еще много узнать о тестировании и многому научиться, причем сделать это надо было быстро. Очень быстро!
К чему такая спешка? Я не верю, что даже самое изощренное тестирование может привести к успеху изначально неудачную идею или непродуманный продукт. Но я верю, что плохое тестирование может загубить хороший продукт, компанию или, по меньшей мере, сможет замедлить ее рост и предоставит фору конкурентам. Это как раз портрет Google того времени. Мы были на пути к успеху, и только проблемы в тестировании удерживали компанию от решающего шага в светлое будущее. Нужно было выработать верные стратегии тестирования, адекватные нашим сверхзвуковым скоростям роста числа пользователей, продуктов и сотрудников. Мы вовсю применяли инновационные решения, нестандартные подходы и уникальные инструменты — нам нельзя было замедляться. Конечно, не все работало. Но в процессе мы получили ценные уроки и научились практикам, которые теперь может применить любая компания, желающая развиваться со скоростью Google. Мы поняли, как сохранить баланс между качеством продукта и скоростью разработки, не теряя ни в чем. Эта книга рассказывает о процессе, к которому мы пришли, о том, какие идеи лежат в его основе, и почему он работает. Если вы хотите понять, как Google справляется с проблемами тестирования в XXI веке, в среде современных интернет-, мобильных и клиентских приложений — вы обратились по адресу. Конечно, я хотел бы оказаться тем человеком, который рассказал бы вам все это, но Джеймс и его соавторы уже сделали это за меня. Главное, что им удалось передать суть тестирования в Google.
