Как тестируют в Google - Уиттакер Джеймс, Арбон Джейсон, Каролло Джефф (2014)

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

На заметку

Тест – это еще одна фича приложения, и за нее отвечают разработчики в тестировании.

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

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

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

Ранняя стадия проекта

В Google нет правила, когда именно разработчики в тестировании должны присоединиться к проекту. Так же как нигде не прописано, когда именно проект становится «реальным». Типичный сценарий создания нового проекта такой: эксперимент, над которым работали в «двадцатипроцентное» время, набирается сил и становится самостоятельным продуктом Google. Именно так развивались Gmail и Chrome OS. Эти проекты начинались с неформальных идей, а со временем выросли в полноценные продукты со своими командами разработчиков и тестировщиков. Наш друг Альберто Савоя (написавший введение к этой книге) любит повторять, что «качество не имеет значения, пока ваш продукт не имеет значения».

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