Книга: Как тестируют в Google
Интервью с разработчиком инструментов Тедом Мао
Интервью с разработчиком инструментов Тедом Мао
Тед Мао — разработчик Google, который занимается исключительно инструментами тестирования. Он создает инструменты тестирования веб-приложений, которые масштабируются на все, что создается в Google. Тед хорошо известен среди разработчиков в тестировании, чья работа немыслима без хороших инструментов. Тед, вероятно, знает общую инфраструктуру веб-тестирования Google лучше всех.
— Когда ты пришел в Google и чем тебя привлекла эта работа?
Тед: Я присоединился к Google в июне 2004 года. До этого я работал только в крупных компаниях, таких как IBM и Microsoft, а тут появился Google — перспективный стартап, который привлекал многих талантливых инженеров. Казалось, что здесь будет много интересных и сложных задач, и я хотел поучаствовать в этой работе рука об руку с лучшими инженерами в мире.
— Ты придумал и реализовал Buganizer,[30] багтрекинговую систему Google. Чего ты хотел добиться в первую очередь с помощью Buganizer и чем эта система была лучше старой BugDB?
Тед: Система BugsDB не только не поддерживала, а даже затрудняла наш процесс разработки. Честно говоря, на работу с ней уходило слишком много времени. Это была своего рода дань, которую она взимала с каждой команды. Она создавала проблемы по всем фронтам: пользовательский интерфейс тормозил, жизненный цикл бага был устроен ужасно, текстовые поля были плохо структурированы и требовали вводить данные особым образом. Проектируя Buganizer, мы позаботились о том, чтобы наша модель данных и пользовательский интерфейс отвечали реальным процессам разработки наших внутренних пользователей. Мы построили систему, которую можно было расширять в дальнейшем как саму по себе, так и с помощью интеграции.
— Итак, ты создал Buganizer. Правда, это лучшая багтрекинговая система, из всех, с которыми нам доводилось работать. А как ты начал заниматься автоматизацией веб-тестирования? Ты понял, что есть потребность, или тебя попросили решить проблему с выполнением тестов?
Тед: Занимаясь Buganizer, AdWords и другими продуктами Google, я постоянно наталкивался на то, что существующей инфраструктуры веб-тестирования не хватает для моей работы. Она никогда не была настолько быстрой, масштабируемой, надежной и полезной, насколько мне было нужно. Когда инструментальная команда объявила поиск рулевого для нового направления, я вызвался. Проект получил название Matrix, и я его возглавил.
— Сколько тестовых прогонов и команд поддерживает Matrix сегодня?
Тед: Зависит от того, как измерять количество прогонов и команд. Например, одна из наших метрик называется «сеанс браузера». Все новые сеансы одного конкретного браузера по умолчанию начинаются в одном состоянии, а значит, выполнение теста в браузере будет детерминировано так же, как сам тест, браузер и ОС. Matrix поддерживает больше миллиона сеансов браузера каждый день и используется почти всеми фронтенд-командами в Google.
— Сколько людей работало над этими двумя проектами: Buganizer и Matrix?
Тед: В самые жаркие периоды разработки над Buganizer работало пять инженеров, а над Matrix четыре. Я всегда расстраиваюсь, думая о том, чего бы мы добились с постоянной большой командой. Но, думаю, мы все-таки прекрасно справились теми силами, которыми располагали.
— Какие самые серьезные технические проблемы вы преодолевали, разрабатывая инструменты?
Тед: Самые сложные и зачастую самые интересные испытания всегда приходятся на этап проектирования: разобраться в проблеме, сравнить разные решения, а потом сделать правильный выбор. После вашего выбора реализация уже пойдет по накатанному пути. Эти решения принимаются один раз и на всю жизнь проекта. Вместе с реализацией они определяют успех или неудачу продукта.
— Что ты посоветуешь программистам, которые разрабатывают средства тестирования?
Тед: Сосредоточьтесь на своих пользователях, поймите, что им нужно, и решите их проблемы. Не забывайте о невидимых фичах вроде удобства использования и скорости. Инженеры умеют решать свои проблемы как никто другой, так дайте им возможность использовать ваши инструменты так, как им удобно.
— Какой ты видишь следующую масштабную или просто интересную проблему, которую нужно решить в области тестовых инструментов и инфраструктуры?
Тед: В последнее время я все чаще думаю о том, что наши инструменты становятся более мощными и сложными. И следовательно, все более трудными для понимания и использования. Например, в нашей текущей инфраструктуре веб-тестирования инженер может одной командой запустить параллельное выполнение тысяч веб-тестов в разных браузерах. С одной стороны, очень хорошо, что мы не вязнем в деталях происходящего: где именно выполняются эти тесты, откуда берутся браузеры, как определяется конфигурация среды тестирования и т.д. С другой стороны, если тест не пройдет и инженер займется его отладкой, все эти подробности все равно понадобятся. У нас уже есть несколько наработок в этой области, однако можно и нужно сделать гораздо больше.
- Использование инструментов Visual Studio для создания базы данных
- Панель инструментов
- Сколько интервью нужно взять?
- Интервью с популярными блогерами «Инстаграма»
- Непосредственно перед интервью
- 9. Оценка эффективности email-маркетинга Как повысить продажи с помощью простых инструментов
- 5.4. Определение основных вариантов коммуникаций. Анализ основных инструментов продвижения
- Использование инструментов с графическим интерфейсом
- 2.4.7. Панель инструментов
- Сразу после интервью
- Приложение III. Кибернетика и человек (Интервью для советского журнала «Природа»)
- 8.3. Панели инструментов