У команд в программе всегда были четкие критерии оценки своего продвижения. К концу 2008 года некоторые руководители стали использовать их для оценки своих команд. Менеджеры из направления продуктивности разработки смотрели на прогресс команды в тест-сертификации, чтобы понять, насколько серьезно они относятся к тестированию и стоит ли им выделять тестировщиков из наших очень ограниченных ресурсов. В некоторых отделах достижение уровня в тест-сертификации стало требованием руководства и критерием для запуска продукта.
К моменту написания этой книги к нам продолжают присоединяться наставники, в программу вступают новые команды, и тест-сертификация прочно укрепилась в компании.
- Как изменилась программа тест-сертификации за первые несколько лет? Изменились ли требования уровней? Изменилась ли система наставничества? Какие изменения стали самыми полезными для участников?
Трэйси: Самым важным изменением стало увеличение числа уровней и пересмотр требований. Сначала у нас было четыре уровня. Перейти с нулевого уровня на первый было легче легкого, мы сделали это намеренно. А вот переход с первого уровня на второй вызывал у большинства трудности, особенно у команд с нетестируемым кодом, доставшимся по наследству. Такие команды быстро перегорали и подумывали бросить программу. Поэтому мы добавили новый уровень между первым и вторым для облегчения перехода. Мы хотели назвать его "Уровень 1,5", но потом решили просто вставить новый уровень и перенумеровать весь список.
Некоторые требования были слишком общими - предписываемое ими соотношение малых/средних/больших тестов не подходило всем командам. Добавив новый уровень, мы обновили эти критерии: удалили отношения размеров тестов, но включили показатели инкрементального покрытия.
Система наставничества все еще действует, правда, теперь у нас много самостоятельных команд. Так как культура тестирования сейчас на подъеме, многим командам уже не нужна активная поддержка. Они хотят только отслеживать свой прогресс. Таким командам мы не назначаем наставника, но отвечаем на их вопросы по почте и присматриваем со стороны за их продвижением по уровням.
Расс: Мы с самого начала помнили, что критерии тест-сертификации нужно применять разумно. Тестирование - это не работа по рецепту. Бывает, что команда не укладывается в общие рамки, на которые мы ориентировались, создавая критерии. Типичные инструменты анализа тестового покрытия или метрики могут не подходить конкретной команде. Каждый критерий имеет под собой обоснование, и мы готовы адаптировать их для команд, не укладывающихся в стереотипы.
- Что даст команде участие в программе тест-сертификации сегодня? Каковы затраты на участие?
Трэйси: Право похвастаться. Четко описанные шаги. Помощь со стороны. Классный светящийся шар. Но настоящая польза - это улучшение тестирования.
Затраты минимальны, если не считать усилий команды на повышение собственного уровня. У нас есть специальное приложение, в котором наставник наблюдает за прогрессом команды и отмечает выполненные шаги. На одной странице есть список всех команд, отсортированный по уровням, со всеми данными по их прогрессу. Можно посмотреть подробную информацию по конкретной команде.
- Есть ли на этих уровнях шаги, которые вызывают больше трудностей, чем другие?
Трэйси: Самый сложный шаг - "обязательные тесты для всех нетривиальных изменений". Когда проект создается с нуля, пишется сразу с расчетом на тестируемость - все просто. С унаследованными проектами, в которых тестирование не учитывалось, могут возникнуть сложности. Иногда нужно писать большой сквозной тест, пытаясь заставить систему пройти конкретные пути кода и отработать определенное поведение, а затем найти, как автоматически собрать результаты. Лучшее, но затратное по времени решение для улучшения тестируемости - рефакторинг кода. Командам, которые пишут код, не учитывая тестирование, потом трудно обеспечить тестовое покрытие, особенно при переходе от малых, узконаправленных юнит-тестов к более крупным тестам, затрагивающим группы классов, не говоря уже о сквозных тестах.
- Многие проекты в Google живут всего несколько недель или месяцев, а ваша тест-сертификация на плаву почти пять лет и, похоже, ко дну идти не собирается. Что помогает ей так долго жить? Какие испытания ждут ее впереди?
Расс: Система живет, потому что ее поддерживает не несколько человек, она изменила всю культуру компании. Спасибо группе первых энтузиастов, "туалетному тестированию", рассылкам, техническим докладам, изменениям в гайдлайнах по написанию кода и в требованиях вакансий, - теперь от всех инженеров компании ждут регулярного тестирования. Участвует команда в тест-сертификации или нет, она должна хорошо продумать стратегию автоматизированного тестирования - либо самостоятельно, либо с помощью экспертов.
Программа продолжает жить, потому что доказала свою эффективность. У нас осталось очень мало областей, в которых хотя бы малая часть тестирования выполняется вручную или передается подрядчикам. В этой битве тест-сертификация победила. Даже если программа когда-нибудь завершится, этот вклад не будет забыт.
- Дайте советы инженерам из других компаний, которые собираются запустить подобные программы у себя.
Трэйси: Начинайте с команд, которые уже хорошо настроены по отношению к тестированию. Вырастите ядро из команд, которым ваша программа быстро принесет практическую пользу. Не стесняйтесь пропагандировать программу и просить об этом других. Наставничество - важный элемент успеха программы тест-сертификации. Когда вы предлагаете команде попробовать что-то новое или усовершенствовать старое, дело пойдет быстрее, если вы выделите им человека, к которому можно обращаться за помощью. Инженеру или команде бывает неудобно задавать кажущиеся глупыми вопросы в общей рассылке, но они охотно обратятся с теми же вопросами к ментору.
Постарайтесь сделать процесс веселым. Попробуйте придумать более удачное название без слова "сертификация", чтобы не кормить бюрократов. Или сделайте как мы - используйте это слово как ложную мишень и постоянно напоминайте своей аудитории, что это неудачное название, ведь ваша программа как раз "не из таких". Опишите небольшие шаги, чтобы команды могли быстро увидеть и показать другим свой прогресс. Не пытайтесь создать идеальную систему с идеальными показателями. Идеала для всех не существует. Очень важно принять приемлемое решение и двигаться вперед, не зависая на попытках достижения несбыточного идеала. Будьте гибкими там, где требуется, но стойте на своем в принципиальных вопросах.
На этом глава, посвященная жизни разработчика в тестировании, подходит к концу. В оставшейся части мы собрали дополнительный материал о том, как Google проводит собеседования с разработчиками в тестировании, и интервью с Тедом Мао, который рассказывает о некоторых инструментах разработчиков в тестировании.
Как мы собеседуем на позицию разработчиков в тестировании
Хорошие разработчики в тестировании сильны во всем - они и достаточно сильные программисты, чтобы писать код, и достаточно опытные тестировщики, чтобы протестировать что угодно. Они могут сами организовать свою работу и подобрать инструменты. Крутой разработчик в тестировании может увидеть весь лес целиком и разглядеть в нем отдельное дерево. Ему достаточно взглянуть на прототип функции или API, и он представит, как этот код будет использоваться и что в нем может сломаться.
Весь код в Google находится в общем хранилище. Это значит, что любой код может использовать кто угодно и когда угодно. Значит, код должен быть надежным.
Разработчики в тестировании не только отлавливают баги, пропущенные программистами. Они создают инструменты и следят, чтобы использование кода или компонента было очевидным для других инженеров, и постоянно думают о том, что будет с этим кодом дальше. Google двигается быстро, поэтому код должен всегда оставаться чистым, последовательным и работать, даже если его создатель давно про него забыл.
Как мы строим собеседование, чтобы найти нужные навыки и особый тип мышления? Это непросто. Но мы уже нашли сотни подходящих инженеров. Мы ищем гибрид: разработчика с сильным интересом и способностями к тестированию. Простой и эффективный способ выявить перспективных разработчиков в тестировании - давать им те же задачи, что и разработчикам, и смотреть, как они подходят к обеспечению качества и тестированию. Получается, у разработчика в тестировании вдвое больше шансов провалить собеседование.
Самые простые вопросы лучше всего помогают понять, получится ли из кандидата хороший разработчик в тестировании. Мы не тратим время на хитроумные задачи программирования и не спорим об академической правильности - это потеря времени, которое можно потратить, чтобы проверить, как кандидат подходит к программированию и качеству. Всегда будут люди, которые нарушают привычный алгоритм решения задачи. И тут важно обратить внимание на то, как кандидат обдумывает решение, а не на изящность самого решения.
На заметку
Собеседуя разработчиков в тестировании, обращайте внимание на то, как кандидат обдумывает решение, а не на изящность самого ответа.
Вот пример простой задачи для разработчиков в тестировании. Представьте, что сегодня ваш первый рабочий день и вас попросили реализовать функцию acount(void* s), которая возвращает число букв "A" в строке.
Кандидат, который с ходу бросается писать код, как будто говорит нам: здесь можно сделать только одно, и я это уже делаю. Все, на что он способен, - писать код. Разработчик в тестировании не должен так узко видеть мир. Мы хотим слышать его вопросы: для чего будет использоваться эта функция? зачем мы ее создаем? похож ли прототип функции на правду? Мы хотим видеть, что кандидата волнует правильность решения и проверка поведения. Задача заслуживает, чтобы ее решали с большим уважением.
Кандидат, который без особых раздумий бросается на программистскую задачу, сделает то же самое с задачей на тестирование. Если мы просим добавить тестовые варианты в модули, то кандидат не должен очертя голову выдавать все подряд тесты, он должен начинать с лучших.
У разработчика в тестировании обычно ограничено время. Мы хотим, чтобы кандидат остановился и нашел самый эффективный способ решения задачи или улучшил существующее решение. Хороший разработчик в тестировании найдет плохо определенные функции API и по ходу тестирования превратит их в нечто красивое.
Достойный кандидат потратит несколько минут на анализ спецификации, задавая вопросы и записывая утверждения.
- Какая кодировка используется во входной строке: ASCII, UTF-8 или что-то еще?
- Имя функции слабое. Не стоит ли использовать стиль CamelCase и сделать его более содержательным? Или здесь действуют другие стандарты выбора имен?
- Какой тип должна возвращать функция? Наверное, интервьюер забыл, поэтому я добавлю int в начало прототипа функции.
- Конструкция void* опасна. Лучше использовать подходящий тип, например char*, чтобы не пострадать от проверки типов при компиляции.
- Что понимается под буквой "A"? Нижний регистр тоже считается?
- Нет ли такой функции в стандартной библиотеке? (Тут мы ответим, что в интересах собеседования ему нужно представить, что он первым реализует эту функцию.)
Лучшие кандидаты пойдут еще дальше.
- Подумают о масштабе. Возможно, для возвращаемого значения лучше использовать int64, потому что Google часто имеет дело с большими объемами данных.
- Подумают о повторном использовании: почему эта функция подсчитывает только буквы "A"? Вероятно, ее стоит параметризовать, чтобы подсчитывать произвольные символы. Это лучше, чем определять разные функции для разных символов.
- Подумают о безопасности: эти указатели получены из надежного источника?
Наконец, самые лучшие кандидаты:
- Подумают о масштабе:
- Будет ли эта функция выполняться как часть вычислений MapReduce для сегментированных данных? Возможно, это самая частая форма вызова такой функции. Есть ли проблемы, которые стоит учитывать в этом сценарии? Надо продумать правильность и быстродействие этой функции при ее выполнении для каждой страницы в интернете.
- Если функция вызывается для каждого запроса Google и только с безопасными указателями, потому что указатели уже проверяются уровнем выше, возможно, следует перестать каждый раз проверять на null. Это сэкономит нам сотни миллионов циклов работы процессора и немного уменьшит задержку на пользовательской стороне. Как минимум, нужно вспомнить о возможных последствиях полной проверки параметров.
- Подумают об оптимизациях, основанных на инвариантах:
- Можно ли предполагать, что входные данные уже отсортированы? Если так, то функция может прекратить свою работу, обнаружив первую букву "B".
- Какую структуру имеют входные данные? Что чаще приходит: только одни буквы "A", сочетание любых символов или только "A" с пробелами? В зависимости от структуры можно будет оптимизировать операции сравнения. При работе с большими данными даже мелкие изменения могут сильно повлиять на задержки при выполнении кода.
- Подумают о безопасности:
- Если эта функция является частью кода, чувствительного к безопасности, то, может быть, стоит проверить не только ненулевые указатели в общем виде. В некоторых системах единица тоже является недействительным значением для указателя.
- Если учитывать параметр длины строки, можно убедиться, что код не выходит за конец строки. Хорошо бы проверить значение параметра длины для надежности. Строки, завершаемые 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, могут самостоятельно прийти к простым способам уменьшить задержки, обрабатывая большие строки параллельно.
- Записывают свои предположения в примечаниях или комментариях к коду.
- Используют много вариантов входных данных и исправляют все найденные баги. Если кандидат на роль разработчика в тестировании не ищет и не исправляет баги - это тревожный признак.
- Тестируют свои функции до того, как их попросят. Наши люди должны тестировать без напоминаний.