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

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

Джейсон Арбон

Джефф Каролло

В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием. Книга рассчитана на профессионалов из индустрии разработки программного обеспечения: специалистов по тестированию, программистов, менеджеров.

Дж. Уиттакер, Дж. Арбон, Дж. Каролло

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

Всем тестировщикам из Google, Microsoft и всех остальных компаний, которые заставили меня мыслить нестандартно.

    Джеймс А. Уиттакер

Моей жене Хизер и моим детям Луке, Матео, Данте и Одессе, которые думали, что я все это время работал в Starbucks.

    Джейсон Арбон

Маме, папе, Лорен и Алексу.

    Джефф Каролло

© ООО Издательство "Питер", 2014

Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

Предисловие к русскому изданию

Я пришла в тестирование в 2006 году маленьким тестировщиком на большой аутсорсный проект. Сначала я научилась тестировать, заводить баги и общаться с разработчиками и менеджерами. Со временем я стала писать тесты, научилась планировать и управлять тестированием. У меня появилась своя команда.

И чем дальше, тем больше мне становилось понятно, что тестировщики только находят проблемы, но не могут их исправить. Они не могут сделать так, чтобы проблема больше не повторилась. И я чувствовала, что тестирование может приносить больше пользы.

Я начала ездить на конференции, читала книги и статьи по тестированию, общалась с коллегами по индустрии. Везде учили, как лучше тестировать, как находить больше ошибок, как быстрее находить ошибки. Тестировщики не хотели выходить за рамки своей профессии. Им как будто нравилось чувствовать собственную важность от того, что они нашли много багов.

Ответы на свои вопросы я нашла в статьях и докладах Джеймса Уиттакера. Его основная идея в том, что тестирование должно перестать просто предоставлять информацию и начать влиять на качество. Главная задача тестирования, говорил Уиттакер, – это уменьшение количества ошибок в процессах разработки. Тогда улучшится качество выпускаемого продукта.

Создать процесс, в котором сложно допустить ошибку, – вот настоящая цель тестирования. Мы не можем полностью избавиться от ошибок, но можем построить работу так, что сделать сразу правильно будет легче, чем ошибиться.

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

Книга «Как тестируют в Google» рассказывает, как тестировщики в Google пришли к пониманию, что нужно меняться, как строили новые процессы, каких результатов достигли и как видят дальнейшее развитие тестирования. Очень здорово, что компания Google настолько открыта и делится своим опытом. Но все же, я думаю, что именно приход Уиттакера в Google послужил катализатором процесса написания этой книги. Слишком уж много у него энергии и желания делиться знаниями с внешним миром.

Я начала переписываться с Уиттакером в 2009 году, а в марте 2010-го познакомилась с ним лично на конференции Swiss Testing Day. Он оказался очень простым в общении. С ним можно было обсудить тренды мирового тестирования и посмеяться над тестировщиками-консерваторами. Джеймс очень остроумный и харизматичный оратор. В 2011-м я слушала его мастер-класс «Как тестируют в Google» на конференции EuroSTAR. Он легко парировал реплики из зала вроде «в авиационном софте не получится сделать так, как в Google» простой фразой «так вы даже не пробовали».

Эта книга повторяет легкий и остроумный стиль общения Джеймса. Вы почувствуете характер Уиттакера, читая ее. Мы очень старались сохранить в переводе эту легкость и живость. Я хотела, чтобы текст получился таким, как будто его написал кто-то очень знакомый: наш коллега, который говорит на том же языке, что и мы. В итоге книга получилась не похожей на большинство технических книг на русском языке, переведенных сухо и формально.

Если вы начинающий тестировщик – прочитайте книгу сейчас, а потом еще раз через год. Если вы опытный тестировщик – дайте ее почитать вашим разработчикам и менеджерам. Если они не загорятся идеей сделать тестирование «как в Google», задумайтесь, стоит ли с ними работать. Если вы менеджер или разработчик – прочитайте и сравните с тем, как работает тестирование в вашей компании.

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

Думайте, «как в Google», а не делайте «как в Google». Приятного чтения!

Спасибо всем ребятам, кто помогал в начале проекта: Илье Фомину, Ане Якшиной, Наташе Курашкиной, Леше Лянгузову, Севе Лотошникову, Игорю Любину, Ване Федорову, Жене Ткаченко, Илье Шубкину. Спасибо «Иннове» и Геворку, что этот проект состоялся. Спасибо Ксюше Развенской и Сергею Сурганову, что помогали вычитывать финальный вариант.

Юля Нечаева

P.S. У меня остался только один вопрос к Джеймсу Уиттакеру: о каком инциденте с костюмом Бедняжки Мэри говорит Фред в четвертой главе?

Вступление от Альберто Савоя

Писать вступление к книге, автором которой вы сами хотели быть, – сомнительное удовольствие. Все равно что стать шафером на свадьбе вашего друга и девушки, на которой вы сами давно мечтали жениться. Но Джеймс Уиттакер – хитрый малый. Прежде чем спросить, не соглашусь ли я написать это предисловие, он воспользовался моей слабостью к мексиканской кухне и угостил меня превосходным обедом. Только после того, как мы опустошили пару бутылок пива, он задал мне этот вопрос «на десерт». К этому моменту я был такой же мягкий и податливый, как порция гуакамоле, которую только что прикончил. «Si, senor» – вот и все, что я смог ответить. План сработал, и вот Джеймс стоит со своей книгой, как с невестой, а я собираюсь произнести свадебную речь.

Как я уже сказал, он хитрый малый.

Ну, поехали… предисловие к книге, которую я хотел бы написать сам. Звучит трогательная свадебная музыка.

Нужна ли миру еще одна книга по тестированию ПО? Особенно если это еще одна книга по тестированию ПО, написанная плодовитым Джеймсом Уиттакером, которого я зову «октомамой»[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.

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

Пока население Google росло с 200 до 20 000 сотрудников, было немало людей, которые оставили свой след в разработке и благодаря которым наши идеи тестирования живут. Джеймс благодарит многих из них. Они появляются на страницах книги в отступлениях и интервью. Тем не менее ни я, ни Джеймс не сделали так много, как Патрик Коупленд – архитектор нашей текущей организационной структуры и руководитель направления продуктивности разработки Google. Все тестировщики Google подотчетны Патрику. Это его видение реализовалось в наших подходах и вот теперь описано в этой книге Джеймсом. Если есть человек, благодаря которому тестирование ПО в 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 тогда была значительно у?же, чем сейчас, и для поддержки качества достаточно было исследовательского тестирования. Но мир менялся. Пользователи приходили в веб в невиданных количествах, и веб стал ориентироваться на приложения, а не на документы. Все чувствовали необходимость роста и изменений. Если ты не хотел оказаться за бортом индустрии, нужно было уметь оперативно масштабировать продукт и быстро выпускать его на рынок.