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

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

Роковая ошибка номер два тоже связана с разделением разработчиков и тестировщиков: тестировщики отождествляются со своей ролью, а не с продуктом.

Если фокус не на продукте — продукт всегда страдает. В конце концов, цель всей разработки — создание продукта, а не программирование, тестирование или документирование. Каждый инженер работает на продукт. Его должность при этом вторична. Признак здоровой компании — когда люди говорят «Я работаю в Chrome», а не «Я работаю тестировщиком».

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

Разделение разработки и тестирования в Google подчеркивает эту разницу в ролях и мешает тестировщикам осознавать свое место в продукте.

Роковая ошибка номер три: тестировщики часто ставят артефакты тестирования выше самого продукта. Ценность тестирования — в действии, а не в артефактах.

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

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

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

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

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

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

Будущее разработчика в тестировании

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

Хотя роль, как нам кажется, обречена на вымирание, сама работа никуда не исчезнет. Эта деятельность — часть волшебной формулы успеха Google. Разработчики в тестировании обеспечивают тестируемость, надежность, возможность отладки и многое другое. Если мы будем рассматривать эти свойства как фичи продукта, так же как пользовательский интерфейс и другие функциональные компоненты, то разработчики в тестировании станут разработчиками, ответственными за реализацию этих фич. Мы думаем, что эта эволюция роли скоро произойдет не только в Google, но и в других зрелых IT-компаниях. Есть ли более эффективный способ поднять статус тест-разработки, чем рассматривать ее наравне с остальными фичами продукта?

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

Следующий вопрос: из каких разработчиков получатся хорошие разработчики тестов? Кому из них можно доверить ответственность за качество? Кто из них серьезно относится к этой работе? Что, если поступить наоборот? В Google, где роль разработчиков в тестировании давно устоялась, можно просто взять и одним махом превратить их всех в разработчиков. И тема закрыта. Но мы считаем, что это топорное решение. Каждый разработчик может выиграть от экскурсии в мир ответственности за фичи качества. [75] Тем не менее принуждать людей к этому несерьезно, да это и не в духе Google. Вместо этого ответственность за фичи тестирования должна отдаваться новым участникам команд, особенно менее опытным.

75

В Google есть программа подготовки инженеров по эксплуатационной надежности (SRE, Service Reliability Engineer), которая называется Mission Control. Разработчик, прошедший шестимесячную программу в роли SRE, получал приличную премию и кожаную куртку с эмблемой Google Mission Control.

Вот вам обоснование. Фичи тестирования — это срез всего продукта. Поэтому разработчики, которые их создают, изучают продукт сверху донизу, от пользовательских интерфейсов до API. Разве можно еще глубже погрузиться в продукт и изучить его строение и архитектуру? Ответственность за тестовую фичу, будь то построение ее с нуля, изменение или сопровождение, — прекрасный старт для любого разработчика в команде. Мы бы даже сказали — лучший старт. С приходом новых участников тест-разработчики освобождают им место и переходят на разработку функциональности. Ребята не застаиваются, и со временем все разработчики становятся подкованными в тестировании и уже серьезно относятся к качеству.

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

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