— Подумают о безопасности:
— Если эта функция является частью кода, чувствительного к безопасности, то, может быть, стоит проверить не только ненулевые указатели в общем виде. В некоторых системах единица тоже является недействительным значением для указателя.
— Если учитывать параметр длины строки, можно убедиться, что код не выходит за конец строки. Хорошо бы проверить значение параметра длины для надежности. Строки, завершаемые null-символом, — лучшие друзья хакера.
— Если существует вероятность того, что буфер может быть модифицирован другим потоком во время выполнения этой функции, это может создать проблемы с безопасностью.
— Должна ли эта проверка выполняться в конструкции try-catch? Если вызывающий код не ожидает исключений, вероятно, ему следует вернуть код ошибки. Если существуют коды ошибок, насколько четко они определены и задокументированы?
Так кандидат показывает, что он думает широко, учитывая окружение кода своей функции и условия ее выполнения. Такой подход помогает избежать путаницы и упущений в дальнейшем.
В итоге самые лучшие кандидаты найдут свой угол зрения на эти вопросы. Любой способ решения задачи хорош, если он обоснован.
На заметку
Хорошему кандидату на роль разработчика в тестировании не нужно напоминать, что написанный им код нужно тестировать. Он должен считать тестирование частью решения.
На самом деле любой инженер, прошедший вводный курс программирования, сможет написать код для решения этой задачи. А вот вопросы и подход к решению отличают лучших кандидатов. Мы стараемся создать комфортную обстановку на собеседовании, чтобы кандидат не стеснялся задавать вопросы. Если он молчит, то мы можем легонько подтолкнуть его к разговору, чтобы понять, не вызвано ли стремление поскорее погрузиться в код атмосферой интервью. Сотрудники Google должны уметь задавать любые вопросы, лишь бы это помогло решению задачи.
Было бы скучно перебирать сотни правильных реализаций и распространенные ошибки — все-таки книга не о программировании и не о проведении собеседований. Поэтому мы покажем только одну простую и очевидную реализацию. Заметим, что кандидаты обычно используют язык, который знают лучше всего, например Java или Python. При этом стоит задать дополнительные вопросы, чтобы убедиться, что они правильно понимают специфические детали языка: как язык работает с памятью и типами данных, особенности компиляции и выполнения.
int64 Acount(const char* s) {
if (!s) return 0;
int64 count = 0;
while (*s++) {
if (*s == 'a') count++;
}
return count;
}
Кандидат должен уметь объяснять свой код, показывать, как меняются значения указателей и счетчиков в процессе выполнения кода с тестовыми входными значениями.
Еще раз. Достойный кандидат на роль разработчика в тестировании:
— Решает эту задачу без особых проблем. Он пишет код с первого раза, не путается в базовом синтаксисе и не смешивает конструкции из разных языков.
— Правильно понимает работу указателей и не засоряет память.
— Реализует проверку входных данных, чтобы избежать проблем, связанных с null-указателями, или может объяснить, почему он этого не делает.
— Понимает, что время выполнения его кода линейно зависит от объема входных данных. Если зависимость нелинейная, это может говорить о творческом подходе, но может оказаться просто ошибкой.
— Исправляет мелкие недочеты в коде, если вы на них укажете.
— Пишет четкий и легко читаемый код. Если кандидат использует побитовые операции или пишет несколько команд в одной строке — это плохой признак, даже если код работает.
— Может рассказать последовательность выполнения своего кода для тестового ввода «A» или null.
Более талантливые кандидаты способны на большее. Они:
— Предлагают использовать int64 для типа счетчиков и возвращаемого значения, чтобы обеспечить будущую совместимость и предотвратить переполнение, если кто-то использует функцию для подсчета букв «A» в очень длинной строке.
— Пишут код, который работает для сегментированного или распределенного выполнения вычислений. Некоторые кандидаты, не знакомые с MapReduce, могут самостоятельно прийти к простым способам уменьшить задержки, обрабатывая большие строки параллельно.
— Записывают свои предположения в примечаниях или комментариях к коду.
— Используют много вариантов входных данных и исправляют все найденные баги. Если кандидат на роль разработчика в тестировании не ищет и не исправляет баги — это тревожный признак.
— Тестируют свои функции до того, как их попросят. Наши люди должны тестировать без напоминаний.
— Продолжают попытки оптимизировать свое решение до тех пор, пока их не попросят остановиться. Никто не может быть уверен, что его код идеален, через пару минут программирования и прогона нескольких тестовых вариантов входных данных. Кандидаты должны стремиться к тому, чтобы в итоге все работало правильно.
Дальше мы должны понять, сможет ли наш кандидат протестировать свой код. Запутанный или нелогичный тестовый код — это, наверное, самое худшее в мире. Уж лучше вообще без тестов. При отладке упавшего теста должно быть очевидно, что этот тест делал. Если это не так, разработчики могут отключить тест, пометить его как ненадежный или проигнорировать сбой — такое бывает. В том, что плохой тестовый код оказался в репозитории, виноваты все, кто писал и рецензировал код.
Разработчик в тестировании должен уметь тестировать и методом черного ящика, предполагая, что функцию написал кто-то другой, и методом белого ящика, зная, какие тест-кейсы не имеют смысла из-за особенностей реализации.
Подытожим. Признаки достойного кандидата:
— Действует методично и систематично. Выстраивает тестовые данные по определенной понятной схеме, например по размеру строки, а не просто выдает в виде случайного набора.
— Фокусируется на генерации реально полезных тестовых данных. Думает о том, как проводить большие тесты и где взять реальные тестовые данные.
Признаки лучшего кандидата:
— Пытается реализовать выполнение функции в параллельных потоках, чтобы выявить перекрестные помехи, дедлоки и утечку памяти.
— Создает тесты с большой продолжительностью выполнения. Например, запускает тесты в цикле while(true), чтобы убедиться, что они не падают со временем.
— Не перестает выдавать тестовые сценарии и предлагать новые подходы к тестированию, выбору данных, проверке и выполнению тестов.
Пример отличного кандидата
Джейсон Арбон
Одного нашего кандидата (который, кстати, уже великолепно справляется с работой в Google) спросили, как бы он организовал тестирование граничных условий для версии этой функции с 64-разрядными целыми числами. Он быстро догадался, что задача физически неразрешима из-за ограничений по времени и объемам данных. Но из любопытства, подогретого нетривиальностью задачи, прикинул, как можно хотя бы разместить большие объемы данных для таких тестов. В качестве входных данных он взял веб-индекс Google.
Как же он проверил свое решение? Кандидат предложил использовать параллельную реализацию и посмотреть, дадут ли обе реализации одинаковый результат. Он предложил применить метод статического выборочного контроля: знаем ли мы, какова предполагаемая частота появления буквы «А» на веб-страницах? Если нам известно количество проиндексированных страниц, мы можем сравнить результат вычислений программы с результатом, полученным теоретическим путем. Это подход к тестированию в духе 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 четыре. Я всегда расстраиваюсь, думая о том, чего бы мы добились с постоянной большой командой. Но, думаю, мы все-таки прекрасно справились теми силами, которыми располагали.
— Какие самые серьезные технические проблемы вы преодолевали, разрабатывая инструменты?
Тед: Самые сложные и зачастую самые интересные испытания всегда приходятся на этап проектирования: разобраться в проблеме, сравнить разные решения, а потом сделать правильный выбор. После вашего выбора реализация уже пойдет по накатанному пути. Эти решения принимаются один раз и на всю жизнь проекта. Вместе с реализацией они определяют успех или неудачу продукта.
— Что ты посоветуешь программистам, которые разрабатывают средства тестирования?
Тед: Сосредоточьтесь на своих пользователях, поймите, что им нужно, и решите их проблемы. Не забывайте о невидимых фичах вроде удобства использования и скорости. Инженеры умеют решать свои проблемы как никто другой, так дайте им возможность использовать ваши инструменты так, как им удобно.
— Какой ты видишь следующую масштабную или просто интересную проблему, которую нужно решить в области тестовых инструментов и инфраструктуры?
Тед: В последнее время я все чаще думаю о том, что наши инструменты становятся более мощными и сложными. И следовательно, все более трудными для понимания и использования. Например, в нашей текущей инфраструктуре веб-тестирования инженер может одной командой запустить параллельное выполнение тысяч веб-тестов в разных браузерах. С одной стороны, очень хорошо, что мы не вязнем в деталях происходящего: где именно выполняются эти тесты, откуда берутся браузеры, как определяется конфигурация среды тестирования и т.д. С другой стороны, если тест не пройдет и инженер займется его отладкой, все эти подробности все равно понадобятся. У нас уже есть несколько наработок в этой области, однако можно и нужно сделать гораздо больше.
Интервью с создателем WebDriver Саймоном Стюартом
Саймон Стюарт — создатель WebDriver и гуру браузерной автоматизации в Google. WebDriver — это опенсорс-инструмент для тестирования веб-приложений, который популярен как в Google, так и за его пределами. Исторически WebDriver — это одна из самых горячих тем на конференции Google Test Automation Conference.
Авторы встретились с Саймоном, чтобы узнать, что он думает об автоматизации тестирования веб-приложений и о будущем WebDriver.
— Мне кажется, многие люди не совсем понимают, в чем отличие Selenium от WebDriver. Ты можешь объяснить разницу?
Саймон: Джейсон Хаггинс начал проект Selenium, когда работал в ThoughtWorks31. Джейсон писал веб-приложение и ориентировался преимущественно на браузер 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. И теперь знаю все их страшные тайны.