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

— Дайте советы инженерам из других компаний, которые собираются запустить подобные программы у себя.

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

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

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

Как мы собеседуем на позицию разработчиков в тестировании

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

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

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

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

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

На заметку

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

Вот пример простой задачи для разработчиков в тестировании. Представьте, что сегодня ваш первый рабочий день и вас попросили реализовать функцию acount(void* s), которая возвращает число букв «A» в строке.

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