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

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

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

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

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

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

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

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

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

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

Оглавление книги