Текст книги "Как тестируют в Google"
Автор книги: Джеймс Уиттакер
Соавторы: Джефф Каролло,Джейсон Арбон
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 8 (всего у книги 26 страниц)
Марк Стрибек – руководитель разработки Gmail. Нил Норвиц – разработчик, занимающийся инструментами ускорения разработки. Трэйси Бялик и Расс Руфер – разработчики в тестировании, одни из лучших инженеров Google. Эти четверо помогали запустить программу тест-сертификации.
Расскажите, с чего началась тест-сертификация? Какие проблемы команда пыталась решить при запуске? Совпадают ли они с теми, которые вы решаете сегодня?
Трэйси:Мы хотели изменить культуру разработчиков Google, чтобы тестирование стало ежедневной обязанностью каждого программиста. Вначале мы просто делились положительным опытом в тестировании и уговаривали команды писать тесты. Некоторые заинтересовались, но не могли решить, с чего начать. Другие включали совершенствование тестирования в список квартальных целей. Обычно это так и оставалось только на бумаге, как постоянные обещания себе похудеть в следующем году. Хорошая, достойная цель, но если ее формулировать абстрактно, не удивляйтесь, если она так и не сможет обрести плоть.
Программа тест-сертификации помогает спланировать совершенствование тестирования по шагам. На первом уровне мы формируем основу: настраиваем фреймворк для запуска автотестов и собираем данные о тестовом покрытии, выявляем недетерминированные тесты и создаем пакет смоук-тестов, если полный тестовый пакет выполняется долго.
Постепенно уровни усложняются, требуя все большей прокачки в тестировании. На втором уровне нужно определяться со стратегией и начинать улучшать инкрементальное покрытие. Третий уровень направлен на тестирование нового кода. На четвертом уровне тестируется старый код, который раньше не тестировался. Может быть, придется провести рефакторинг, чтобы код стал тестируемым. На пятом уровне уже нужно иметь хорошее общее покрытие, писать тесты для всех исправленных багов и использовать средства для статического и динамического анализа.
Теперь все сотрудники Google знают, что тестирование входит в обязанности разработчиков. Одной проблемой меньше. Но у нас остается задача помочь командам повысить навыки тестирования и научить их новым методам. Так что сейчас тест-сертификация направлена именно на это.
– Как оценивали разработчики тест-сертификацию на старте?
Нил: Они считали, что программа чересчур сложна, а наши цели завышены, ведь многим командам нужно было еще добраться даже до начальной стадии. Мы должны были настроить уровни так, чтобы на их достижение у людей было время. Кроме того, инструментарий Google тогда был недоработан и некоторые наши требования превосходили возможности. Людям было трудно влиться в процесс, поэтому нам пришлось подумать о том, как смягчить требования на старте и убедить команды в том, что они действительно продвигаются вперед.
Марк: Да, нам пришлось отступить на несколько шагов назад. Мы постарались стать более реалистичными и увеличить длину взлетной полосы. Тем не менее, каким бы длинным ни был разгон, все равно для взлета надо развить порядочную скорость. Так мы сформулировали первый шаг: настроить непрерывную сборку, доводить хотя бы некоторые сборки до состояния «зеленый свет», определить покрытие кода. Это и так было у многих команд. Когда мы оформили это в правила, команды смогли сразу перейти на первый уровень и уже хотели работать дальше по программе.
– А кто принял вашу идею с энтузиазмом?
Нил: У нас организовалась группа ребят, заинтересованных в тестировании. Мы регулярно собирались. Потом мы стали приглашать знакомых коллег. Приятным сюрпризом оказалось, что многим инженерам это интересно. Интерес к программе вырос, когда мы стали применять «тестирование в туалете» [25]25
«Тестирование в туалете» (Testing on The Toilet) упоминалось ранее в этой книге. О нем часто пишут в блоге Google Testing по адресу googletesting.blogspot.com
[Закрыть]и другие штуки, которые делали тестирование более прикольным: «починялки», [26]26
«Починялки» (fixits) – еще один элемент культуры Google: это мероприятие собирает людей для починки чего-то сломанного или работающего неправильно. Например, группа может устроить «починялки» для сокращения количества ошибок. Или для тестирования безопасности. Или для расширения использования #include в коде C или рефакторинга. Цель встречи не ограничивается технической областью, и «починялки» могут проводиться для улучшения качества блюд в кафе или схемы проведения собраний. По сути, это любое мероприятие, на котором люди собираются для решения общей проблемы.
[Закрыть]массовая рассылка электронной почты, плакаты, выступления на пятничных встречах «Thanks God It’s Friday» и пр.
Марк: Как только мы обратились к другим командам, а заинтересованных было немало, они поняли, что нужна серьезная работа, для которой у них просто нет нужного опыта. Начало было невеселым.
– Кто не хотел поддерживать ваше нововведение?
Нил: Большинство проектов. Как я уже сказал, всем казалось, что это слишком сложно. Мы должны были умерить свои начальные амбиции. По сути, в Google было два вида проектов: без тестов и с очень скверными тестами. Мы должны были показать тестирование как обычную рутину, с которой можно расправиться еще до обеда. И это было реально – с нашей помощью.
Марк: Кроме того, в то время в Google еще не было единого понимания ценности тестирования и автоматизации. Сегодня все по-другому. А тогда большинство команд полагало, что все эти идеи очень милые, но у них есть дела поважнее, а именно – писать код.
– Какие препятствия пришлось преодолеть, чтобы собрать единомышленников?
Нил: Инертность. Плохие тесты. Отсутствие тестов. Время. Тестирование рассматривалось как проблема кого-то другого – не важно, другого разработчика или тестировщика. Когда заниматься тестами, если нужно написать столько кода?
Марк: Пришлось искать команды, которые были бы достаточно заинтересованными и не имели особых проблем со старым кодом. В них должен был быть хотя бы один человек, который хотел заниматься тестированием и ориентировался в теме. Это были три основных препятствия, и мы последовательно преодолевали их, команда за командой.
– Как тест-сертификация стала популярной? Рост был вирусный или линейный?
Расс: Сначала мы прогнали пилотную версию на командах, которые дружили с тестированием, и на тех, кто помогал организовать программу. Мы тщательно выбирали свою аудиторию – привлекали команды с самыми высокими шансами на успех.
Когда мы объявили глобальный запуск тестовой сертификации в середине 2007 года, в Google уже было 15 пилотных команд, находящихся на разных уровнях. Перед запуском мы обклеили стены всех наших зданий в Маунтин-Вью плакатами «Что скрывает тест-сертификация». На плакатах были фотографии команд и внутренние названия проектов (Rubix, Bounty, Mondrian, Red Tape и т.д.). Мы сделали провокационные надписи типа «Будущее начинается сегодня» и «Это важно, не отставай» со ссылкой на программу. Мы получили огромное количество посещений от любопытствующих, которые хотели раскрыть тайну или подтвердить свои догадки. Мы задействовали «туалетное тестирование», чтобы прорекламировать программу и рассказать людям, где они могут узнать больше о проекте.
Мы объясняли, почему программа важна для команд и чем она им поможет. Мы подчеркивали, что команды получат наставника по тест-сертификации и доступ к сообществу экспертов тестирования. За участие в проекте команды получали два подарка. Первый – светящийся шар «статуса сборки», который показывал командам состояние тестов их непрерывных сборок в цвете: тесты прошли успешно – зеленый, не прошли – красный. Второй – комплект прикольных фигурок из «Звездных войн», который мы назвали «Дарт Тестер». Всего было три фигурки, и мы выдавали командам по одной по мере продвижения. Команды, на чьих столах появлялись такие шары и фигурки, вызывали любопытство и разговоры о программе.
Участники нашей ранней группы стали первыми наставниками и евангелистами проекта. Постепенно к нам присоединялись новые команды. В них находились свои инженеры-энтузиасты, которые помогали создать шумиху вокруг тест-сертификации и сами становились наставниками.
Чем больше новых команд присоединялось к программе, тем лучше мы учились находить подходящие аргументы для каждой. Для одних команд решающим было то, что пошаговый процесс и наличие наставников поможет им вырасти в данной области. Другие считали, что и сами смогут повысить свою квалификацию, но с официальными уровнями их работа скорее будет оценена по достоинству. Третьи команды уже серьезно использовали методы тестирования, но их можно было уговорить тем, что, присоединившись, они покажут всем, насколько серьезно относятся к тестированию.
Через несколько месяцев, когда в нашей программе уже участвовало порядка 50 команд, несколько смелых представителей от разработки записались в наставники. Это стало началом партнерства между инженерами из команд разработки продуктов и специалистами направления продуктивности.
Весь этот прогресс имел вирусную природу, мы шли снизу, по горизонтали, от сотрудника к сотруднику. Какие-то команды приходилось уговаривать, другие уже приходили к нам сами.
Примерно через год, когда с нами работало уже 100 команд, приток новых сторонников пошел на спад. Тогда Белла Казуэлл, которая занималась привлечением людей, разработала систему поощрений тест-сертификации. За написание новых тестов, привлечение новых команд в проект, совершенствование тестовых методов или достижение новых уровней тест-сертификации начислялись баллы. Появилась индивидуальная система наград. Филиалы по всему миру состязались друг с другом за количество очков. Мы смогли привлечь новых добровольцев, команды и наставников – началась вторая волна популярности программы.
У команд в программе всегда были четкие критерии оценки своего продвижения. К концу 2008 года некоторые руководители стали использовать их для оценки своих команд. Менеджеры из направления продуктивности разработки смотрели на прогресс команды в тест-сертификации, чтобы понять, насколько серьезно они относятся к тестированию и стоит ли им выделять тестировщиков из наших очень ограниченных ресурсов. В некоторых отделах достижение уровня в тест-сертификации стало требованием руководства и критерием для запуска продукта.
К моменту написания этой книги к нам продолжают присоединяться наставники, в программу вступают новые команды, и тест-сертификация прочно укрепилась в компании.
– Как изменилась программа тест-сертификации за первые несколько лет? Изменились ли требования уровней? Изменилась ли система наставничества? Какие изменения стали самыми полезными для участников?
Трэйси: Самым важным изменением стало увеличение числа уровней и пересмотр требований. Сначала у нас было четыре уровня. Перейти с нулевого уровня на первый было легче легкого, мы сделали это намеренно. А вот переход с первого уровня на второй вызывал у большинства трудности, особенно у команд с нетестируемым кодом, доставшимся по наследству. Такие команды быстро перегорали и подумывали бросить программу. Поэтому мы добавили новый уровень между первым и вторым для облегчения перехода. Мы хотели назвать его «Уровень 1,5», но потом решили просто вставить новый уровень и перенумеровать весь список.
Некоторые требования были слишком общими – предписываемое ими соотношение малых/средних/больших тестов не подходило всем командам. Добавив новый уровень, мы обновили эти критерии: удалили отношения размеров тестов, но включили показатели инкрементального покрытия.
Система наставничества все еще действует, правда, теперь у нас много самостоятельных команд. Так как культура тестирования сейчас на подъеме, многим командам уже не нужна активная поддержка. Они хотят только отслеживать свой прогресс. Таким командам мы не назначаем наставника, но отвечаем на их вопросы по почте и присматриваем со стороны за их продвижением по уровням.
Расс: Мы с самого начала помнили, что критерии тест-сертификации нужно применять разумно. Тестирование – это не работа по рецепту. Бывает, что команда не укладывается в общие рамки, на которые мы ориентировались, создавая критерии. Типичные инструменты анализа тестового покрытия или метрики могут не подходить конкретной команде. Каждый критерий имеет под собой обоснование, и мы готовы адаптировать их для команд, не укладывающихся в стереотипы.
– Что даст команде участие в программе тест-сертификации сегодня? Каковы затраты на участие?
Трэйси: Право похвастаться. Четко описанные шаги. Помощь со стороны. Классный светящийся шар. Но настоящая польза – это улучшение тестирования.
Затраты минимальны, если не считать усилий команды на повышение собственного уровня. У нас есть специальное приложение, в котором наставник наблюдает за прогрессом команды и отмечает выполненные шаги. На одной странице есть список всех команд, отсортированный по уровням, со всеми данными по их прогрессу. Можно посмотреть подробную информацию по конкретной команде.
– Есть ли на этих уровнях шаги, которые вызывают больше трудностей, чем другие?
Трэйси: Самый сложный шаг – «обязательные тесты для всех нетривиальных изменений». Когда проект создается с нуля, пишется сразу с расчетом на тестируемость – все просто. С унаследованными проектами, в которых тестирование не учитывалось, могут возникнуть сложности. Иногда нужно писать большой сквозной тест, пытаясь заставить систему пройти конкретные пути кода и отработать определенное поведение, а затем найти, как автоматически собрать результаты. Лучшее, но затратное по времени решение для улучшения тестируемости – рефакторинг кода. Командам, которые пишут код, не учитывая тестирование, потом трудно обеспечить тестовое покрытие, особенно при переходе от малых, узконаправленных юнит-тестов к более крупным тестам, затрагивающим группы классов, не говоря уже о сквозных тестах.
– Многие проекты в Google живут всего несколько недель или месяцев, а ваша тест-сертификация на плаву почти пять лет и, похоже, ко дну идти не собирается. Что помогает ей так долго жить? Какие испытания ждут ее впереди?
Расс: Система живет, потому что ее поддерживает не несколько человек, она изменила всю культуру компании. Спасибо группе первых энтузиастов, «туалетному тестированию», рассылкам, техническим докладам, изменениям в гайдлайнах по написанию кода и в требованиях вакансий, – теперь от всех инженеров компании ждут регулярного тестирования. Участвует команда в тест-сертификации или нет, она должна хорошо продумать стратегию автоматизированного тестирования – либо самостоятельно, либо с помощью экспертов.
Программа продолжает жить, потому что доказала свою эффективность. У нас осталось очень мало областей, в которых хотя бы малая часть тестирования выполняется вручную или передается подрядчикам. В этой битве тест-сертификация победила. Даже если программа когда-нибудь завершится, этот вклад не будет забыт.
– Дайте советы инженерам из других компаний, которые собираются запустить подобные программы у себя.
Трэйси: Начинайте с команд, которые уже хорошо настроены по отношению к тестированию. Вырастите ядро из команд, которым ваша программа быстро принесет практическую пользу. Не стесняйтесь пропагандировать программу и просить об этом других. Наставничество – важный элемент успеха программы тест-сертификации. Когда вы предлагаете команде попробовать что-то новое или усовершенствовать старое, дело пойдет быстрее, если вы выделите им человека, к которому можно обращаться за помощью. Инженеру или команде бывает неудобно задавать кажущиеся глупыми вопросы в общей рассылке, но они охотно обратятся с теми же вопросами к ментору.
Постарайтесь сделать процесс веселым. Попробуйте придумать более удачное название без слова «сертификация», чтобы не кормить бюрократов. Или сделайте как мы – используйте это слово как ложную мишень и постоянно напоминайте своей аудитории, что это неудачное название, ведь ваша программа как раз «не из таких». Опишите небольшие шаги, чтобы команды могли быстро увидеть и показать другим свой прогресс. Не пытайтесь создать идеальную систему с идеальными показателями. Идеала для всех не существует. Очень важно принять приемлемое решение и двигаться вперед, не зависая на попытках достижения несбыточного идеала. Будьте гибкими там, где требуется, но стойте на своем в принципиальных вопросах.
На этом глава, посвященная жизни разработчика в тестировании, подходит к концу. В оставшейся части мы собрали дополнительный материал о том, как Google проводит собеседования с разработчиками в тестировании, и интервью с Тедом Мао, который рассказывает о некоторых инструментах разработчиков в тестировании.
Как мы собеседуем на позицию разработчиков в тестировании
Хорошие разработчики в тестировании сильны во всем – они и достаточно сильные программисты, чтобы писать код, и достаточно опытные тестировщики, чтобы протестировать что угодно. Они могут сами организовать свою работу и подобрать инструменты. Крутой разработчик в тестировании может увидеть весь лес целиком и разглядеть в нем отдельное дерево. Ему достаточно взглянуть на прототип функции или API, и он представит, как этот код будет использоваться и что в нем может сломаться.
Весь код в Google находится в общем хранилище. Это значит, что любой код может использовать кто угодно и когда угодно. Значит, код должен быть надежным.
Разработчики в тестировании не только отлавливают баги, пропущенные программистами. Они создают инструменты и следят, чтобы использование кода или компонента было очевидным для других инженеров, и постоянно думают о том, что будет с этим кодом дальше. Google двигается быстро, поэтому код должен всегда оставаться чистым, последовательным и работать, даже если его создатель давно про него забыл.
Как мы строим собеседование, чтобы найти нужные навыки и особый тип мышления? Это непросто. Но мы уже нашли сотни подходящих инженеров. Мы ищем гибрид: разработчика с сильным интересом и способностями к тестированию. Простой и эффективный способ выявить перспективных разработчиков в тестировании – давать им те же задачи, что и разработчикам, и смотреть, как они подходят к обеспечению качества и тестированию. Получается, у разработчика в тестировании вдвое больше шансов провалить собеседование.
Самые простые вопросы лучше всего помогают понять, получится ли из кандидата хороший разработчик в тестировании. Мы не тратим время на хитроумные задачи программирования и не спорим об академической правильности – это потеря времени, которое можно потратить, чтобы проверить, как кандидат подходит к программированию и качеству. Всегда будут люди, которые нарушают привычный алгоритм решения задачи. И тут важно обратить внимание на то, как кандидат обдумываетрешение, а не на изящность самого решения.
На заметку
Собеседуя разработчиков в тестировании, обращайте внимание на то, как кандидат обдумывает решение, а не на изящность самого ответа.
Вот пример простой задачи для разработчиков в тестировании. Представьте, что сегодня ваш первый рабочий день и вас попросили реализовать функцию acount(void* s), которая возвращает число букв «A» в строке.
Кандидат, который с ходу бросается писать код, как будто говорит нам: здесь можно сделать только одно, и я это уже делаю. Все, на что он способен, – писать код. Разработчик в тестировании не должен так узко видеть мир. Мы хотим слышать его вопросы: для чего будет использоваться эта функция? зачем мы ее создаем? похож ли прототип функции на правду? Мы хотим видеть, что кандидата волнует правильность решения и проверка поведения. Задача заслуживает, чтобы ее решали с большим уважением.
Кандидат, который без особых раздумий бросается на программистскую задачу, сделает то же самое с задачей на тестирование. Если мы просим добавить тестовые варианты в модули, то кандидат не должен очертя голову выдавать все подряд тесты, он должен начинать с лучших.
У разработчика в тестировании обычно ограничено время. Мы хотим, чтобы кандидат остановился и нашел самый эффективный способ решения задачи или улучшил существующее решение. Хороший разработчик в тестировании найдет плохо определенные функции API и по ходу тестирования превратит их в нечто красивое.
Достойный кандидат потратит несколько минут на анализ спецификации, задавая вопросы и записывая утверждения.
– Какая кодировка используется во входной строке: ASCII, UTF-8 или что-то еще?
– Имя функции слабое. Не стоит ли использовать стиль CamelCase [27]27
CamelCase – стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово пишется с заглавной буквы. Стиль получил cвое название из-за того, что заглавные буквы внутри слова напоминают горбы верблюда.
[Закрыть]и сделать его более содержательным? Или здесь действуют другие стандарты выбора имен?
– Какой тип должна возвращать функция? Наверное, интервьюер забыл, поэтому я добавлю int в начало прототипа функции.
– Конструкция void* опасна. Лучше использовать подходящий тип, например char*, чтобы не пострадать от проверки типов при компиляции.
– Что понимается под буквой «A»? Нижний регистр тоже считается?
– Нет ли такой функции в стандартной библиотеке? (Тут мы ответим, что в интересах собеседования ему нужно представить, что он первым реализует эту функцию.)
Лучшие кандидаты пойдут еще дальше.
– Подумают о масштабе. Возможно, для возвращаемого значения лучше использовать int64, потому что Google часто имеет дело с большими объемами данных.
– Подумают о повторном использовании: почему эта функция подсчитывает только буквы «A»? Вероятно, ее стоит параметризовать, чтобы подсчитывать произвольные символы. Это лучше, чем определять разные функции для разных символов.
– Подумают о безопасности: эти указатели получены из надежного источника?
Наконец, самые лучшие кандидаты:
– Подумают о масштабе:
– Будет ли эта функция выполняться как часть вычислений MapReduce [28]28
MapReduce – технология распределенных вычислений, при которой вычислительная задача разбивается на небольшие части, которые затем собираются вместе. См. http://en.wikipedia.org/wiki/MapReduce.
[Закрыть]для сегментированных [29]29
Сегментация (sharding) – разновидность распределения базы данных. Горизонтальная сегментация позволяет проектировать базы данных: строки таблицы базы данных хранятся по отдельности (в отличие от вертикального разбиения по столбцам). См. http://en.wikipedia.org/wiki/Shard_(database_architecture)
[Закрыть]данных? Возможно, это самая частая форма вызова такой функции. Есть ли проблемы, которые стоит учитывать в этом сценарии? Надо продумать правильность и быстродействие этой функции при ее выполнении для каждой страницы в интернете.
– Если функция вызывается для каждого запроса 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, могут самостоятельно прийти к простым способам уменьшить задержки, обрабатывая большие строки параллельно.
– Записывают свои предположения в примечаниях или комментариях к коду.
– Используют много вариантов входных данных и исправляют все найденные баги. Если кандидат на роль разработчика в тестировании не ищет и не исправляет баги – это тревожный признак.
– Тестируют свои функции до того, как их попросят. Наши люди должны тестировать без напоминаний.
– Продолжают попытки оптимизировать свое решение до тех пор, пока их не попросят остановиться. Никто не может быть уверен, что его код идеален, через пару минут программирования и прогона нескольких тестовых вариантов входных данных. Кандидаты должны стремиться к тому, чтобы в итоге все работало правильно.
Дальше мы должны понять, сможет ли наш кандидат протестировать свой код. Запутанный или нелогичный тестовый код – это, наверное, самое худшее в мире. Уж лучше вообще без тестов. При отладке упавшего теста должно быть очевидно, что этот тест делал. Если это не так, разработчики могут отключить тест, пометить его как ненадежный или проигнорировать сбой – такое бывает. В том, что плохой тестовый код оказался в репозитории, виноваты все, кто писал и рецензировал код.
Разработчик в тестировании должен уметь тестировать и методом черного ящика, предполагая, что функцию написал кто-то другой, и методом белого ящика, зная, какие тест-кейсы не имеют смысла из-за особенностей реализации.
Подытожим. Признаки достойного кандидата:
– Действует методично и систематично. Выстраивает тестовые данные по определенной понятной схеме, например по размеру строки, а не просто выдает в виде случайного набора.
– Фокусируется на генерации реально полезных тестовых данных. Думает о том, как проводить большие тесты и где взять реальные тестовые данные.
Признаки лучшего кандидата:
– Пытается реализовать выполнение функции в параллельных потоках, чтобы выявить перекрестные помехи, дедлоки и утечку памяти.
– Создает тесты с большой продолжительностью выполнения. Например, запускает тесты в цикле while(true), чтобы убедиться, что они не падают со временем.
– Не перестает выдавать тестовые сценарии и предлагать новые подходы к тестированию, выбору данных, проверке и выполнению тестов.
