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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чудес не бывает или я ошибаюсь?

Ниже будет много букв, кому побыстрее — могу рекомендовать глянуть этот пост, от Никиты Макарова (тезисы отдельно здесь).

Если еще короче — надо идти и читать. И не важно, делаете вы web-приложения, мобильные или десктопные. Советы в этой книге пригодятся всем: разработчикам, и тестировщикам, а также их начальникам.

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

Да, пока не забыл, огромное спасибо Алене Васюхиной, Юлии Нечаевой, которые перевели книгу.

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

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

• В Google тесты различают по размеру того, что тестируется. И условно делятся три группы: малые (это, например, юнит-тесты), средние (например, тесты для проверки взаимодействия компонентов) , большие (это когда проверяются реальные пользовательские сценарии).
• Малые тесты направлены на проверку качества кода, а средние и большие — на проверку качества всего продукта.
• На каждый вид тестов действует ограничение по времени выполнения и то, с чем они могут взаимодействовать. Тип теста должны быть обозначен в свойствах теста. От этого зависит поведение системы автоматического запуска тестов: максимальное время выполнение каждого типа отличается и система просто рубанет якобы «зависший» тест.
• Рекомендуемое соотношение количества тестов разных типов: 70 — 20 -10% (малые-средние-большие). Малые всегда автоматизируются, средние и большие — it depends.

Про поиск правильных людей
В книге много рекомендаций по тому, как найти правильных людей на ту или иную роль.
Также есть неплохая анкета позволяющая отличить тестировщика от разработчика в тестировании. Правда у меня получилось, что по анкете я больше тестировщик 🙂 Но на последующее тестовое задание ответил плохо. И кто я в итоге? 🙂 Гусары, молчать ))

Еще интересно: «Часто забывается, что тестирование — это по сути проверка. Делает ли приложение то, что должно делать? Большая часть работы по тестированию сводится к планированию и выполнению проверок. Да, приложение может падать в процессе, но добиться сбоя — не цель тестировщика. Давить на программу, пока она не сломается, интересно, но куда интереснее давить на нее понемногу, снова и снова, имитируя ее реальную эксплуатацию пользователем. А как приятно убедиться в том, что она не сломается при таких условиях! Мы ищем именно такой позитивный взгляд на тестирование, когда проводим собеседование«

Интересно про оценку и повышение:
«Решения о повышении основываются на том, какое влияние специалист оказал на свой проект. Во время ежегодных отчетов менеджеров просят описать ценность вклада своих подчиненных и перечислить, на что это повлияло. Мы ожидаем, что при движении по карьерной лестнице сотрудник влияет на все большее количество вещей«.
Используются ежеквартальные и годовые OKR (Objectives and Key Results) — список целей и оценка успеха в достижении этих целей. «Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны«.

Хорошая (на мой взгляд разработчика) глава про навыки тест-менеджера.
Одним из полезных навыков является способность работы в условиях дефицита (людей). Дефицит приносит ясность и умножает чувство ответственности у всех участников проекта. «Когда ресурсов не хватает, приходится оптимизировать весь процесс. Руководитель не может просто бросить всех людей на задачу, поэтому все действия оптимизируются. Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся. Если разработчики требуют от тестировщиков определенной деятельности, они должны сами в ней участвовать. Люди не придумывают себе работу, чтобы просто не сидеть без дела. Не нужно делать то, что сейчас не принесет ценности«.

• Избегайте повествования, пишите списки.
• Оставьте продажи в покое. Тест-план — это не маркетинговый документ.
• Не лейте воду.
• Если какой-то пункт не важен и не требует действий, не включайте его в план.
• Пишите «от общего к частному». Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина проекта в голове, даже если он прекратил читать.
• Направляйте процесс мышления. Хороший процесс планирования помогает участнику тщательно продумать функциональность и потребности тестирования.
• Итогом должны стать тест-кейсы.

• Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.
• Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.

Про умирание кода
«При переводе проекта в режим сопровождения качества важно снизить зависимость от участия людей в поддержании качества. У кода есть интересное свойство: если оставить его без внимания, он черствеет и ломается сам по себе. Это верно и для кода продукта, и для кода тестов«.

Вот как то так. Получилось длинновато, но хотелось дать шанс ленивцам, которые не возьмутся найти время почитать книгу, получить хоть какую то информацию. Но не думайте, что тут все написано — книга гораздо толще и интересней 🙂

Кстати, неожиданный инсайт из другого источника, все что описано работает в таких вот условиях: «one monolithic C++ codebase, 4000+ engineers working on it, 30,000 commits a day» — по материалам конференции CppCon 2014. Для меня это действительно показатель.

Поделиться

• Получить ссылку
• Facebook
• Twitter
• Pinterest
• Электронная почта
• Другие приложения

Книга «Как тестируют в Google» — бесплатная электронная версия

Привет, Хаброжители!

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

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

Отрывок. Снижение рисков

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

В разработке программного продукта самое простое — избегать рискованных областей: чем меньше кода, тем меньше риск. Но кроме использования «топора и секиры», мы можем сделать еще много чего, чтобы снизить риски:

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

В некоторых проектах именно тестировщиков спрашивают о готовности продукта к выпуску. Хорошему тестировщику достаточно бросить взгляд на тепловую карту, чтобы определить, стоит еще подержать продукт в духовке или пора подавать его на стол. Если речь о запуске экспериментального Google Labs, то наличие красных зон риска не так существенно, если они не относятся к безопасности, конечно. А если это выпуск новой версии Gmail, тогда даже желтые зоны представляют серьезную опасность. Такая простая цветовая градация понятна всем, даже топ-менеджерам.

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

Тест-план за десять минут по рецепту Джеймса Уиттакера

Любая задача в разработке ПО, которую можно решить за десять минут, считается простой или не заслуживающей внимания. Предположим, что мы верим в это, — тогда что мы можем сказать о планирования тестирования? Конечно же, то, что оно занимает более десяти минут. Когда я работал директором по тестированию в Google, я руководил несколькими командами, которые создавали огромное количество тест-планов. Ответы на вопрос о том, сколько времени займет его составление, могли быть такими: «завтра», «к концу недели» и лишь пару раз — «к концу дня» (если задача озвучивалась рано утром). О’кей, примем к сведению, что составление тест-плана занимает некоторое количество часов, а то и дней.

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

Иногда тест-план нежизнеспособен потому, что содержит слишком много или, наоборот, слишком мало подробностей. Или он способствовал началу работы, а вот процессу — уже нет. И снова вопрос знатокам: стоило ли создавать документ с ограниченной или постоянно уменьшающейся ценностью?

Некоторые тест-планы содержат настолько очевидную информацию, что ее и документировать-то не стоило. Мы просто зря тратим время. Давайте посмотрим правде в глаза: у нас проблема с тест-планами.

Чтобы справиться с этим, я придумал для своей команды простое задание: написать тест-план за десять минут. Если уж он и имеет какую-то ценность, то давайте доберемся до нее как можно скорее.

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

Однако я ничего этого я не говорил участникам эксперимента. Я просто сказал: «Вот приложение, составьте тест-план не более чем за десять минут». Имейте в виду, что эти люди получали зарплату за то, что они выполняли мои задачи. И все же я предполагал, что они испытывали ко мне определенное уважение, а следовательно, знали, что я не поручу им невыполнимую задачу.

Они могли потратить некоторое время на знакомство с приложением, но, так как речь шла о приложениях, которые они используют каждую неделю (Google Docs, App Engine, Talk Video и т. д.), я дал им совсем немного времени на это.

Во всех случаях команды изобретали методы, схожие с методами ACC-анализа. Они оформляли решения в форме таблиц и списков, не используя большие объемы текста. То есть предложениям — да, абзацам текста — нет. Они не тратили время на форматирование текста, не вдавались в излишние объяснения. У всех тест-планов было одно общее — команды документировали возможности. Они признали, что это было лучшим решением, куда потратить весьма ограниченное время.

О’кей, ни одна команда не завершила тест-план вовремя. Тем не менее они успели за десять минут пройтись по атрибутам и компонентам и начали вычленять возможности исследуемого продукта. К концу дополнительных двадцати минут большинство моих подопытных записали довольно большой набор возможностей, который мог бы служить отличной отправной точкой
при создании тест-кейсов и пользовательских историй.

Мне кажется, что эксперимент удался. Я выделил им десять минут, хотя ориентировался на час. В итоге за полчаса было выполнено 80% работы. Разве этого недостаточно? Мы точно знаем, что не будем тестировать все, ну и зачем нам все документировать? Мы отлично знаем, что в ходе тестирования многие вещи (графики, требования, архитектура) будут изменяться. Настаивать на скрупулезной точности планирования, когда завершенность вовсе не требуется, не имеет смысла.

Восемьдесят процентов работы выполнено за тридцать минут или даже меньше. Вот это я называю десятиминутным тест-планом!

Напоследок о рисках

Google Test Analytics берет за основу описанные выше критерии оценки рисков («очень редко», «редко», «иногда», «часто»). Мы специально не хотим превращать анализ рисков в сложную задачу, иначе она не будет выполнена. Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимания на точное значение рисков. Простое знание, какая возможность рискованнее другой, позволит тест-менеджеру более эффективно распределять работу тестировщиков. А такие люди, как Патрик Коупленд, смогут легко решать, сколько тестировщиков нужно назначить в каждую команду разработки. Понимание рисков приносит пользу на уровне всей компании.

Анализ рисков — это самостоятельная научная область, уважаемая во многих отраслях. Мы используем упрощенную версию методологии, но это не мешает нам интересоваться новыми исследованиями, чтобы улучшить свой подход к тестированию. Если вы хотите узнать больше об анализе рисков, то начните со статьи «Управление рисками» в Википедии.

GTA помогает обозначить риски, а тестирование помогает их снизить. Тестировщик служит посредником в этом процессе. Он может выполнить внутренние тесты по некоторым наиболее рискованным направлениям или поставить задачу разработчикам и разработчикам в тестировании, чтобы они добавили регрессионные тесты. В его арсенале есть и другие инструменты: исследовательское тестирование, привлечение внутренних и бета-пользователей и силы внешнего сообщества.

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

1. Для самых рискованных возможностей и пар «атрибут/компонент», отмеченных красным, напишите набор пользовательских историй, сценариев использования или руководство по тестированию. В Google ответственность за наиболее рискованные возможности лежит на тестировщике. Он может координировать свою работу с коллегами, использовать разные инструменты, но личная ответственность все равно на нем.
2. Внимательно изучите все то, что делалось по тестированию разработчиками и разработчиками в тестировании до вас. Как результаты повлияли на риски, выявленные с помощью GTA? Хорошо ли это тестирование было организовано с точки зрения управления рисками? Стоит ли добавить новые тесты? Тестировщику может понадобиться дописать эти тесты самому или обратиться к разработчикам. В конечном счете важно, чтобы тесты были написаны, а не кто именно их напишет.
3. Проанализируйте баги, обнаруженные у каждой пары атрибут/компонент высокого риска, и убедитесь в том, что соответствующие регрессионные тесты написаны для каждого из них. Баги имеют свойство возвращаться при изменении кода.
4. Будьте внимательнее к областям высокого риска — поинтересуйтесь механизмами восстановления и отката. Учтите возможное негативное влияние на пользователя, когда он столкнется с наихудшим сценарием. Обсудите такие ситуации с другими инженерами, проверьте реалистичность этих сценариев. К тестировщику, который часто кричит: «Волк!», вскоре перестанут прислушиваться. Громкие предупреждения о вероятных опасностях допустимы только в отношении сценариев с высоким риском, которые к тому же признаны реалистичными и уже были покрыты тестами.
5. Вовлекайте в работу как можно больше людей, заинтересованных в успешности проекта. Внутренних пользователей следует тормошить на тему обратной связи, иначе они будут просто использовать систему, игнорируя те или иные ошибки. Просите их проводить конкретные эксперименты, задавайте им вопросы типа «А как это работает на вашей машине?» или «Как бы вы использовали такую фичу?». Сотрудники Google много участвуют в тестировании, и их нужно активно направлять именно тестировать, а не просто пользоваться продуктами.
6. Если ни один из механизмов не работает, а подверженный риску компонент так и недотестирован, да еще и постоянно падает, постарайтесь добиться удаления элемента. Поздравляем! Вам выпал шанс объяснить руководству концепцию анализа рисков и подчеркнуть важность тестировщиков на проекте.

Пользовательские сценарии

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

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

Создавая пользовательскую историю, мы смотрим на продукт только через пользовательский интерфейс, мы не включаем в описание технические подробности. Тогда тестировщик будет каждый раз проходить этот путь по-разному, как и разные пользователи по-разному решают одну и ту же задачу в нашем приложении — вот в чем главная идея!

Главное в пользовательских историях — ценность продукта для пользователя. Это не тест-кейсы с их определенными вводными данными и ожидаемыми результатами. Хорошая практика — создавать отдельные учетные записи. Мы в Google часто создаем помногу тестовых учетных записей для пользователей, описанных в историях. Старые аккаунты могут быть полезны по-другому: при тестировании Google Documents мы выявили самые интересные баги как раз для старых учетных записей — при загрузке в новой версии документов, созданных в предыдущих версиях.

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

Мы не будем слишком придираться к возможностям с низкими рисками. Мы можем решить, что писать тест-кейсы для этих областей — слишком затратное занятие. Вместо этого мы можем ограничиться исследовательским тестированием или оставить на откуп краудсорс-тестированию. Чтобы управлять работой тестировщиков из внешнего сообщества, мы часто пользуемся концепцией туров — это высокоуровневые инструкции для исследовательского тестирования. Проще говоря, такой подход дает вашему запросу нужную конкретику. Например, попросив сообщество: «Проведите FedEx-тур для такого-то набора возможностей», — мы получим намного лучший результат, чем просто отдав приложение и понадеявшись на лучшее. Мы сразу определяем фичи, которые нужно протестировать, и даем инструкции, как это делать.

Краудсорсинг

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

Представим, что есть группа опытных пользователей, которые разбираются в тестировании и согласились нам помочь за разумную плату. Все, что им нужно, — это доступ к среде, где они могут работать с приложением, и отлаженный механизм предоставления обратной связи и баг-репортов. Для таких проектов, как наш опенсорсный Chromium, тестирование при помощи большой группы людей подходит идеально. Однако для проектов, открытых только внутри компании, это более проблематично. Нужно отбирать тестировщиков, пользующихся особым доверием.

Еще одна ключевая ценность краудсорсинга (кроме множества конфигураций) — это более широкий взгляд на приложение. Вместо того чтобы один тестировщик имитировал действия тысячи пользователей, у нас есть тысяча пользователей, работающих как тестировщики. Есть ли лучший способ найти сценарии, приводящие приложение к сбою, чем сразу выдать эти сценарии пользователям и получить обратную связь? Разнообразие и масштаб — вот в чем ценность краудсорсинга.

Людей, желающих протестировать программный продукт, в избытке, и доступны они круглосуточно. Допустим, дано: топ-1000 сайтов, задача: протестировать их в последней версии Chrome, тогда решение: 1 тестировщик = 1000 итераций или 20 тестировщиков = 50 итераций. Математика на стороне краудсорсинга.

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

Краудсорс-тестирование — это следующий этап развития стандартных каналов Google: канареечного канала, канала разработки, тестового канала и канала внутреннего продукта. Это наш способ привлечения ранних пользователей и людей, которым просто нравится искать баги и сообщать о них. Мы уже попробовали набирать тестировщиков внутри компании среди наших коллег, которые любят работать со свежим продуктом, подключать к командам людей из компаний поставщиков, пользоваться услугами коммерческих компаний краудсорсинга (например, uTest). Мы даже запустили программу поощрения лучших искателей багов.

Итак, сила ACC-анализа в том, что мы получаем список возможностей продукта, который можно упорядочить по риску и закрепить за разными исполнителями. Тестировщики, работающие над одним проектом, могут получить разные наборы возможностей для проверки. Внутренние пользователи, «двадцатипроцентные» участники, тестировщики-подрядчики, тестировщики из сообщества, разработчики, разработчики в тестировании — все получат свои списки возможностей, и, к радости тестировщика, важные области будут покрыты с меньшим перекрытием, чем если бы мы просто раздали приложение для тестирования всем желающим.

Работа тестировщика, в отличие от работы разработчика в тестировании, с впуском продукта не заканчивается.

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

Также данная книга доступна ещё в библиотеке. Запишись сразу в несколько библиотек и получай книги намного быстрее.

Как читать книгу после покупки

Посоветуйте книгу друзьям! Друзьям – скидка 10%, вам – рубли

По вашей ссылке друзья получат скидку 10% на эту книгу, а вы будете получать 10% от стоимости их покупок на свой счет ЛитРес. Подробнее

Стоимость книги: 399 ₽
Ваш доход с одной покупки друга: 39,90 ₽
Чтобы посоветовать книгу друзьям, необходимо войти или зарегистрироваться Войти

• Объем: 450 стр. 76 иллюстраций
• Жанр:з арубежная компьютерная литература, и нтернет, п рограммирование
• Теги:в еб-программирование, п оисковые системы, п родукты 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 тогда была значительно у́же, чем сейчас, и для поддержки качества достаточно было исследовательского тестирования. Но мир менялся. Пользователи приходили в веб в невиданных количествах, и веб стал ориентироваться на приложения, а не на документы. Все чувствовали необходимость роста и изменений. Если ты не хотел оказаться за бортом индустрии, нужно было уметь оперативно масштабировать продукт и быстро выпускать его на рынок.

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

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

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

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

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

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

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

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

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

Тестировщики, к моему удивлению, реагировали аналогично. Они привыкли к текущему состоянию дел, охотно оплакивали свой статус, но не торопились его менять.

Когда я пожаловался своему начальнику, он сказал: «Это Google. Если ты хочешь, чтобы что-то было сделано, – сделай это».

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

Первые несколько месяцев были самыми тяжелыми. В процессе проверки часто отбраковывались неплохие кандидаты. Возможно, они недостаточно быстро решали какую-нибудь хитроумную задачу по программированию или плохо проявляли себя в области, важной для интервьюера, но на самом деле не имеющей никакого отношения к навыкам тестирования. Я знал, что с наймом у нас будут проблемы, и каждую неделю строчил докладную за докладной. Они уходили Ларри Пейджу, который был (и остается) последней инстанцией в процессе найма. Он утвердил достаточное количество кандидатов, и моя команда начала расти. Я иногда думаю, что мое имя у Ларри ассоциируется только с фразой «Нам нужны тестировщики!».

Конечно, я поднял столько шума, пытаясь найти поддержку, что пути назад у нас уже не было. За нами наблюдала вся компания, и неудача могла стать фатальной. От маленькой тестовой команды с вечно меняющимся штатом контрактников ожидали великих свершений. И все же – на фоне моих битв с наймом и сокращения числа внештатных сотрудников – я начал замечать изменения. Чем сильнее становился дефицит тестировщиков, тем больше тестовой работы приходилось выполнять разработчикам. Многие команды приняли вызов. Думаю, если бы технологии не развивались, уже этого было бы достаточно, чтобы со временем выйти на нужный уровень.

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

Команды разработчиков испытывали сильное давление. Google начал покупать компании со своими веб-приложениями (YouTube, Google Docs и прочие), которые только усиливали нагрузку на нашу внутреннюю инфраструктуру. Проблемы, с которыми я сталкивался в тестировании, не уступали проблемам, с которыми сталкивались разработчики при написании кода. Я пытался решить проблему тестирования, которую просто невозможно было решить отдельно от разработки. Рассматривать тестирование и разработку как обособленные дисциплины или даже как разнородные задачи было в корне неверно, и мы не могли решить ни одну из проблем. Улучшение команды тестирования стало бы всего лишь временным успехом.

Но все-таки положительные сдвиги начались. Полезно нанимать умных людей – они могут сами исправить ситуацию. К 2007 году позиции дисциплины тестирования укрепились. Мы неплохо справлялись с завершающей фазой цикла выпуска. Команды разработки знали, что могут рассчитывать на нас как на партнеров в производстве. Правда, наше существование как команды поддержки позднего цикла ограничивало нас рамками традиционной модели контроля качества. Несмотря на неплохие результаты, мы все еще не достигли состояния, в котором я хотел бы оказаться. Я разобрался с проблемой найма, тестирование двигалось в нужном направлении, но мы все еще слишком поздно включались в процесс.

Наша концепция «Тест-сертификации» делала успехи (вы прочитаете про нее дальше в книге). Мы общались с командами разработчиков и помогали улучшить чистоту кода и внедрить юнит-тестирование на ранней стадии. Мы разрабатывали инструменты и обучали команды основам непрерывной интеграции, чтобы наши продукты всегда были готовы к тестированию. Бесчисленные мелкие усовершенствования и приемы, многие из которых описаны в книге, развеяли скептицизм. Тем не менее чего-то не хватало. Разработка все еще была разработкой, а тестирование так и оставалось тестированием. Все ингредиенты для изменения культуры присутствовали, но нам был нужен катализатор, который смог бы запустить объединение дисциплин.

Глядя на организацию, которая выросла из моей идеи о привлечении разработчиков на позиции тестирования, я понял, что тестирование было лишь частью нашей работы. У нас были команды, которые создавали все инструменты – от репозиториев исходного кода до инфраструктуры для багтрекинговой системы. Среди нас были инженеры по тестированию, инженеры по выпуску продуктов, разработчики инструментов и консультанты. Меня поражало, как сильно тот аспект нашей работы, который не являлся непосредственно тестированием, влиял на производительность. Возможно, наша команда называлась «службой тестирования», но наши обязанности были намного шире.

Поэтому я решил оформить все официально и сменил название команды на «направление продуктивности разработки». Смена названия привела к культурному сдвигу. Люди начали говорить не о контроле качества и тестировании, а о производительности. Повышение производительности – наша работа, а тестирование и контроль качества – работа всех, кто пишет код. Это означает, что и тестирование, и контроль качества входят в обязанности разработчика. Команда продуктивности разработки должна заботиться о том, чтобы разработчик мог заниматься этими двумя вещами.

На первых порах идея была абстрактной, а наш девиз «Ускоряем Google» поначалу звучал наигранно. Со временем мы выполнили обещание. Наши инструменты ускорили темпы разработки, мы переходили от одного бутылочного горлышка к другому, расчищали пути и решали проблемы, с которыми сталкивались разработчики. Наши инструменты помогли разработчикам писать тесты и наблюдать их результаты при каждой сборке. Тестовые сценарии уже не выполнялись локально на компьютере тестировщика. Их результаты публиковались на информационных панелях и собирались от версии к версии, так что в итоге они становились частью общедоступных данных о готовности приложения к выпуску. Мы не просто требовали участия разработчиков, мы упрощали его. Разница между тестированием и обеспечением продуктивности наконец-то стала ощутимой: Google мог создавать новое с меньшими затратами и обходиться без накопления технического долга.

Результаты? Пожалуй, я не буду предвосхищать содержание книги, потому что ее написали для того, чтобы рассказать о них миру. Авторы приложили огромные усилия, чтобы на основании собственной работы и опыта своих коллег из Google свести наш секретный рецепт успеха к конкретному набору практических методов. Мы добились успеха во многих отношениях – от сокращения времени сборки до автоматизированного тестирования в формате «запустил и забыл» и публикации в опенсорс новаторских инструментов тестирования. Когда я писал это вступление, в направлении продуктивности разработки работало около 1200 специалистов, что немногим больше численности всего технического персонала в 2005 году, когда я пришел в Google. Бренд «продуктивности» укрепился, а наше стремление ускорить Google стало неотъемлемой частью нашей технической культуры. С того первого дня, когда я сидел озадаченный и неуверенный на пятничной встрече, наша команда проделала путь длиной во много световых лет. Единственное, что не изменилось с тех пор, – моя трехцветная кепка с пропеллером. Она лежит у меня на столе и напоминает о том, как далеко мы ушли.

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

1. Не поняли, о чем речь? Погуглите!

2. Разработка через тестирование – процесс разработки программного обеспечения, который основан на том, что тесты пишутся до того, как будет написан код. Таким образом, функциональные обязанности кода определяются заранее. – Примеч. перев.