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

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

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

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

Пат Коупленд во введении говорит, что по поводу найма разработчика в тестировании было и есть много полярных мнений. Если он хорошо программирует, может быть, поручать ему писать фичи? Ведь хороших разработчиков тоже сложно найти. А может, им стоит сосредоточиться только на тестировании, если они легко с этим справляются? Истина, как обычно, лежит где-то посередине.

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

Интервью с разработчиком инструментов Тедом Мао

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

— Когда ты пришел в Google и чем тебя привлекла эта работа?

Тед:Я присоединился к Google в июне 2004 года. До этого я работал только в крупных компаниях, таких как IBM и Microsoft, а тут появился Google — перспективный стартап, который привлекал многих талантливых инженеров. Казалось, что здесь будет много интересных и сложных задач, и я хотел поучаствовать в этой работе рука об руку с лучшими инженерами в мире.

— Ты придумал и реализовал Buganizer30 , багтрекинговую систему Google . Чего ты хотел добиться в первую очередь с помощью Buganizer и чем эта система была лучше старой BugDB ?

Тед:Система BugsDB не только не поддерживала, а даже затрудняла наш процесс разработки. Честно говоря, на работу с ней уходило слишком много времени. Это была своего рода дань, которую она взимала с каждой команды. Она создавала проблемы по всем фронтам: пользовательский интерфейс тормозил, жизненный цикл бага был устроен ужасно, текстовые поля были плохо структурированы и требовали вводить данные особым образом. Проектируя Buganizer, мы позаботились о том, чтобы наша модель данных и пользовательский интерфейс отвечали реальным процессам разработки наших внутренних пользователей. Мы построили систему, которую можно было расширять в дальнейшем как саму по себе, так и с помощью интеграции.

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

Тед:Занимаясь Buganizer, AdWords и другими продуктами Google, я постоянно наталкивался на то, что существующей инфраструктуры веб-тестирования не хватает для моей работы. Она никогда не была настолько быстрой, масштабируемой, надежной и полезной, насколько мне было нужно. Когда инструментальная команда объявила поиск рулевого для нового направления, я вызвался. Проект получил название Matrix, и я его возглавил.

— Сколько тестовых прогонов и команд поддерживает Matrix сегодня?

Тед:Зависит от того, как измерять количество прогонов и команд. Например, одна из наших метрик называется «сеанс браузера». Все новые сеансы одного конкретного браузера по умолчанию начинаются в одном состоянии, а значит, выполнение теста в браузере будет детерминировано так же, как сам тест, браузер и ОС. Matrix поддерживает больше миллиона сеансов браузера каждый день и используется почти всеми фронтенд-командами в Google.

— Сколько людей работало над этими двумя проектами: Buganizer и Matrix ?

Тед:В самые жаркие периоды разработки над Buganizer работало пять инженеров, а над Matrix четыре. Я всегда расстраиваюсь, думая о том, чего бы мы добились с постоянной большой командой. Но, думаю, мы все-таки прекрасно справились теми силами, которыми располагали.

— Какие самые серьезные технические проблемы вы преодолевали, разрабатывая инструменты?

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

— Что ты посоветуешь программистам, которые разрабатывают средства тестирования?

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

— Какой ты видишь следующую масштабную или просто интересную проблему, которую нужно решить в области тестовых инструментов и инфраструктуры?

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