- Продолжают попытки оптимизировать свое решение до тех пор, пока их не попросят остановиться. Никто не может быть уверен, что его код идеален, через пару минут программирования и прогона нескольких тестовых вариантов входных данных. Кандидаты должны стремиться к тому, чтобы в итоге все работало правильно.
Дальше мы должны понять, сможет ли наш кандидат протестировать свой код. Запутанный или нелогичный тестовый код - это, наверное, самое худшее в мире. Уж лучше вообще без тестов. При отладке упавшего теста должно быть очевидно, что этот тест делал. Если это не так, разработчики могут отключить тест, пометить его как ненадежный или проигнорировать сбой - такое бывает. В том, что плохой тестовый код оказался в репозитории, виноваты все, кто писал и рецензировал код.
Разработчик в тестировании должен уметь тестировать и методом черного ящика, предполагая, что функцию написал кто-то другой, и методом белого ящика, зная, какие тест-кейсы не имеют смысла из-за особенностей реализации.
Подытожим. Признаки достойного кандидата:
- Действует методично и систематично. Выстраивает тестовые данные по определенной понятной схеме, например по размеру строки, а не просто выдает в виде случайного набора.
- Фокусируется на генерации реально полезных тестовых данных. Думает о том, как проводить большие тесты и где взять реальные тестовые данные.
Признаки лучшего кандидата:
- Пытается реализовать выполнение функции в параллельных потоках, чтобы выявить перекрестные помехи, дедлоки и утечку памяти.
- Создает тесты с большой продолжительностью выполнения. Например, запускает тесты в цикле while(true), чтобы убедиться, что они не падают со временем.
- Не перестает выдавать тестовые сценарии и предлагать новые подходы к тестированию, выбору данных, проверке и выполнению тестов.
Пример отличного кандидата
Джейсон Арбон
Одного нашего кандидата (который, кстати, уже великолепно справляется с работой в Google) спросили, как бы он организовал тестирование граничных условий для версии этой функции с 64-разрядными целыми числами. Он быстро догадался, что задача физически неразрешима из-за ограничений по времени и объемам данных. Но из любопытства, подогретого нетривиальностью задачи, прикинул, как можно хотя бы разместить большие объемы данных для таких тестов. В качестве входных данных он взял веб-индекс Google.
Как же он проверил свое решение? Кандидат предложил использовать параллельную реализацию и посмотреть, дадут ли обе реализации одинаковый результат. Он предложил применить метод статического выборочного контроля: знаем ли мы, какова предполагаемая частота появления буквы "А" на веб-страницах? Если нам известно количество проиндексированных страниц, мы можем сравнить результат вычислений программы с результатом, полученным теоретическим путем. Это подход к тестированию в духе Google. Хотя мы не стали реализовывать эти гигантские тесты, сама возможность таких решений наталкивает на интересные идеи для реальной работы.
Еще один параметр, который мы проверяем на собеседовании, - "гугловость", то есть соответствие нашей культуре. Насколько кандидат технически любознателен? Может ли он интегрировать в свое решение новые идеи? Как он справляется с неоднозначностью? Знакомы ли ему академические методы проверки качества, например доказательства теорем? Разбирается ли он в метриках качества или автоматизации в других областях, например в самолетостроении?
Пытается ли он оправдать наличие багов, которые мы нашли в его реализации? Может ли мыслить масштабно? Кандидаты, конечно, не обязаны обладать всеми перечисленными свойствами, но чем больше совпадений, тем лучше. И наконец, хотим ли мы вообще работать с этим человеком каждый день?
Важное замечание: если человек, проходящий интервью на должность разработчика в тестировании, оказался не таким уж сильным программистом, из него может получиться хороший инженер по тестированию. Некоторые из наших лучших инженеров по тестированию изначально пробовались на должность разработчика в тестировании.
Интересно, что мы часто упускаем хороших кандидатов, потому что за время собеседования они склоняются в сторону чистого программирования или, наоборот, зацикливаются на тестировании. Мы хотим, чтобы кандидатов собеседовали специалисты разных должностей, которым потом придется с ними работать, потому что роль разработчика в тестировании - это сплав двух ролей, и иногда ее сложно правильно оценить на собеседовании. Нужно быть уверенным в том, что плохие оценки выставлены людьми, понимающими такую двуликость хорошего кандидата.
Пат Коупленд во введении говорит, что по поводу найма разработчика в тестировании было и есть много полярных мнений. Если он хорошо программирует, может быть, поручать ему писать фичи? Ведь хороших разработчиков тоже сложно найти. А может, им стоит сосредоточиться только на тестировании, если они легко с этим справляются? Истина, как обычно, лежит где-то посередине.
Поиск хорошего кандидата на роль разработчика в тестировании - дело хлопотное, но оно того стоит. Даже один хороший разработчик в тестировании может оказать огромное влияние на работу всей команды.
Интервью с разработчиком инструментов Тедом Мао
Тед Мао - разработчик Google, который занимается исключительно инструментами тестирования. Он создает инструменты тестирования веб-приложений, которые масштабируются на все, что создается в Google. Тед хорошо известен среди разработчиков в тестировании, чья работа немыслима без хороших инструментов. Тед, вероятно, знает общую инфраструктуру веб-тестирования Google лучше всех.
- Когда ты пришел в Google и чем тебя привлекла эта работа?
Тед: Я присоединился к Google в июне 2004 года. До этого я работал только в крупных компаниях, таких как IBM и Microsoft, а тут появился Google - перспективный стартап, который привлекал многих талантливых инженеров. Казалось, что здесь будет много интересных и сложных задач, и я хотел поучаствовать в этой работе рука об руку с лучшими инженерами в мире.
- Ты придумал и реализовал Buganizer,багтрекинговую систему Google. Чего ты хотел добиться в первую очередь с помощью Buganizer и чем эта система была лучше старой BugDB?
Тед: Система BugsDB не только не поддерживала, а даже затрудняла наш процесс разработки. Честно говоря, на работу с ней уходило слишком много времени. Это была своего рода дань, которую она взимала с каждой команды. Она создавала проблемы по всем фронтам: пользовательский интерфейс тормозил, жизненный цикл бага был устроен ужасно, текстовые поля были плохо структурированы и требовали вводить данные особым образом. Проектируя Buganizer, мы позаботились о том, чтобы наша модель данных и пользовательский интерфейс отвечали реальным процессам разработки наших внутренних пользователей. Мы построили систему, которую можно было расширять в дальнейшем как саму по себе, так и с помощью интеграции.
- Итак, ты создал Buganizer. Правда, это лучшая багтрекинговая система, из всех, с которыми нам доводилось работать. А как ты начал заниматься автоматизацией веб-тестирования? Ты понял, что есть потребность, или тебя попросили решить проблему с выполнением тестов?
Тед: Занимаясь Buganizer, AdWords и другими продуктами Google, я постоянно наталкивался на то, что существующей инфраструктуры веб-тестирования не хватает для моей работы. Она никогда не была настолько быстрой, масштабируемой, надежной и полезной, насколько мне было нужно. Когда инструментальная команда объявила поиск рулевого для нового направления, я вызвался. Проект получил название Matrix, и я его возглавил.
- Сколько тестовых прогонов и команд поддерживает Matrix сегодня?
Тед: Зависит от того, как измерять количество прогонов и команд. Например, одна из наших метрик называется "сеанс браузера". Все новые сеансы одного конкретного браузера по умолчанию начинаются в одном состоянии, а значит, выполнение теста в браузере будет детерминировано так же, как сам тест, браузер и ОС. Matrix поддерживает больше миллиона сеансов браузера каждый день и используется почти всеми фронтенд-командами в Google.
- Сколько людей работало над этими двумя проектами: Buganizer и Matrix?
Тед: В самые жаркие периоды разработки над Buganizer работало пять инженеров, а над Matrix четыре. Я всегда расстраиваюсь, думая о том, чего бы мы добились с постоянной большой командой. Но, думаю, мы все-таки прекрасно справились теми силами, которыми располагали.
- Какие самые серьезные технические проблемы вы преодолевали, разрабатывая инструменты?
Тед: Самые сложные и зачастую самые интересные испытания всегда приходятся на этап проектирования: разобраться в проблеме, сравнить разные решения, а потом сделать правильный выбор. После вашего выбора реализация уже пойдет по накатанному пути. Эти решения принимаются один раз и на всю жизнь проекта. Вместе с реализацией они определяют успех или неудачу продукта.
- Что ты посоветуешь программистам, которые разрабатывают средства тестирования?
Тед: Сосредоточьтесь на своих пользователях, поймите, что им нужно, и решите их проблемы. Не забывайте о невидимых фичах вроде удобства использования и скорости. Инженеры умеют решать свои проблемы как никто другой, так дайте им возможность использовать ваши инструменты так, как им удобно.
- Какой ты видишь следующую масштабную или просто интересную проблему, которую нужно решить в области тестовых инструментов и инфраструктуры?
Тед: В последнее время я все чаще думаю о том, что наши инструменты становятся более мощными и сложными. И следовательно, все более трудными для понимания и использования. Например, в нашей текущей инфраструктуре веб-тестирования инженер может одной командой запустить параллельное выполнение тысяч веб-тестов в разных браузерах. С одной стороны, очень хорошо, что мы не вязнем в деталях происходящего: где именно выполняются эти тесты, откуда берутся браузеры, как определяется конфигурация среды тестирования и т.д. С другой стороны, если тест не пройдет и инженер займется его отладкой, все эти подробности все равно понадобятся. У нас уже есть несколько наработок в этой области, однако можно и нужно сделать гораздо больше.
Интервью с создателем WebDriver Саймоном Стюартом
Саймон Стюарт - создатель WebDriver и гуру браузерной автоматизации в Google. WebDriver - это опенсорс-инструмент для тестирования веб-приложений, который популярен как в Google, так и за его пределами. Исторически WebDriver - это одна из самых горячих тем на конференции Google Test Automation Conference.
Авторы встретились с Саймоном, чтобы узнать, что он думает об автоматизации тестирования веб-приложений и о будущем WebDriver.
- Мне кажется, многие люди не совсем понимают, в чем отличие Selenium от WebDriver. Ты можешь объяснить разницу?
Саймон: Джейсон Хаггинс начал проект Selenium, когда работал в ThoughtWorks. Джейсон писал веб-приложение и ориентировался преимущественно на браузер IE, который занимал тогда больше 90% рынка. Но он постоянно получал сообщения о багах от пользователей, пересевших на Firefox, причем исправление ошибки для Firefox могло нарушить работу приложения в IE. Джейсон придумал Selenium как механизм, запускающий и тестирующий приложение в обоих браузерах.
Я начал разрабатывать WebDriver примерно через год после создания Selenium, но еще до того, как проект Джейсона вышел на стабильность. Я ориентировался на более общее тестирование веб-приложений, поэтому неудивительно, что мы выбрали разные способы реализации. Проект Selenium строился на запуске JavaScript-кода в браузере, а WebDriver сам интегрировался в браузер через API. У каждого подхода были свои достоинства и недостатки. Selenium почти сразу же мог работать с новыми браузерами, например с Chrome, но не умел загружать файлы и нормально обрабатывать действия пользователя. Все-таки возможности песочницы JS ограничены. Механизм WebDriver был встроен в браузер, поэтому он мог обходить эти ограничения, но добавлять другие браузеры было тяжело. Когда мы оба пришли в Google, мы решили объединить проекты.
- Но мы до сих пор слышим оба названия. Это все еще разные проекты?
Саймон: Selenium - это "зонтичный" проект, под которым мы выпускаем все инструменты браузерной автоматизации, среди которых есть и WebDriver. Официально он называется Selenium WebDriver.
- А как Google начал участвовать в этом?
Саймон: Когда открылся лондонский офис Google, туда пригласили работать нескольких бывших сотрудников ThoughtWorks. Они пригласили меня рассказать о WebDriver. Тот доклад у меня не удался - какой-то парень в первом ряду все время засыпал, и мне пришлось перекрикивать его храп в аудитории. Для полного счастья что-то произошло с аппаратурой, и мой доклад не записался. Несмотря на все злоключения, проектом заинтересовались, и меня пригласили провести презентацию уже без храпа на конференции GTAC. Вскоре я начал работать в Google. И теперь знаю все их страшные тайны.
- Ну конечно, все наши шкафы забиты скелетами. Вообще-то мы видели, как ты выступаешь, и не можем представить, чтобы кто-то заснул на твоем докладе. Мы его знаем?
Саймон: Нет. Он уже давно покинул Google. Будем считать, что у него выдалась тяжелая ночь.
- Пусть это будет уроком нашим читателям. Засыпать на докладе Саймона Стюарта вредно для вашей карьеры. WebDriver стал твоей основной работой, когда ты присоединился к Google?
Саймон: Нет, это был мой "двадцатипроцентный" проект. Хотя в основное время я был разработчиком в тестировании, мне удавалось двигать WebDriver вперед. Очень помогало участие разработчиков со стороны. На ранней стадии опенсорс-проекта людям приходится вкладываться в проект, потому что это единственный вариант его развития. Теперь многие пользователи WebDriver узнают о проекте от других и относятся к нему скорее как потребители, чем как участники. Но в те дни WebDriver развивался силами энтузиастов сообщества.
- Что ж, мы знаем, к чему это привело - WebDriver стал очень популярен в Google. С чего все началось? С одного пилотного проекта? Были фальстарты?
Саймон: Все началось с Wave - социального продукта, который был создан в нашем сиднейском филиале. С тех пор проект успели закрыть. Разработчики Wave попытались использовать Selenium в качестве тестовой инфраструктуры, но у них это не вышло. Wave оказался слишком сложным продуктом. Разработчики были достаточно упрямы, чтобы докопаться до WebDriver. Они начали задавать мне много вопросов. Хороших вопросов.
Работы стало больше, чем я мог выполнять в свои "20 процентов". Они переговорили с моим руководством и договорились о месячной командировке. Так я отправился в Сидней, чтобы помочь им построить тестовую инфраструктуру.
- Насколько я понимаю, поездка увенчалась успехом.
Саймон: Да, команда очень сильно помогла, и мы справились. Та работа поставила новые требования перед моим продуктом и показала другим командам Google, что WebDriver - подходящий инструмент для современных веб-приложений. С этого момента у WebDriver не было недостатка в пользователях, а у меня появилась возможность работать над ним в основное время.
- С первым пользователем всегда сложнее всего. Как ты справился с необходимостью разрабатывать WebDriver и одновременно адаптировать его для Wave?
Саймон: Я пользовался процессом DDD (Defect-Driven Development - разработка через дефекты). Я объявлял WebDriver бездефектным, а когда пользователь находил баг, я его исправлял и снова объявлял продукт бездефектным. Так я исправлял только по-настоящему значимые для людей баги. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.
- Ты так и остаешься единственным разработчиком WebDriver?
Саймон: Нет, теперь у нас сформировалась команда. Мы - официальный внутренний проект Google и пользуемся активной поддержкой в опенсорс-сообществе. Число браузеров, версий и платформ постоянно растет. Я говорю людям, что мы тут все сумасшедшие и все же каждый день делаем невозможное. Думаю, большинство разработчиков в здравом уме от такого будут держаться подальше.
- Итак, после Wave вы набрали скорость. Именно в этот момент WebDriver стал отделяться от старой инфраструктуры Selenium? Мы имеем в виду в контексте пользователей.
Саймон: Думаю, да. Многие разработчики Selenium переключились на другие проекты, а у меня успех WebDriver с Wave вызвал приток энергии. Люди, которых я не знал лично, например Майкл Там из Германии, начали делать важную работу для WebDriver, и я старался бережно поддерживать эти отношения. Майкл стал первым человеком, не знакомым мне лично, который получил право заливать код в репозиторий проекта.
Но я не так уж пристально следил за распространением WebDriver. Понятно, что чем ближе команда находится ко мне физически, тем больше вероятность их перехода на WebDriver. Думаю, моими первыми пользователями еще до Wave стала команда Picasa Web Albums, а потом WebDriver подхватила команда Ads. По части использования веб-автоматизации в Google нет единства. Chrome использует PyAuto, Search использует Puppet (у которого есть версия с открытым кодом - Web Puppeteer), Ads использует WebDriver и т.д.
- Как насчет будущего WebDriver? К чему стремится ваша команда?
Саймон: Сейчас на поле вышло много игроков. Всего пару лет назад у нас был рынок с одним доминирующим браузером. Это в прошлом. Internet Explorer, Firefox, Chrome, Safari, Opera - далеко не все примеры, и это только десктоп. Браузеры на базе WebKit для мобильных устройств плодятся бешеными темпами. Коммерческие инструменты игнорируют все, кроме IE. Это кажется безумием, ведь 2008 год давно прошел. Следующим логичным шагом станет стандартизация WebDriver, чтобы мы могли гарантировать работу веб-приложений в разных браузерах. Конечно, было бы полезно сотрудничать с разработчиками браузеров, чтобы мы могли обеспечивать совместимость с WebDriver API.
- Похоже, это задача для комитета по стандартизации. Есть прогресс в этом направлении?