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

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

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

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

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

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

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

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

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

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

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

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

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