Итак, когда все вопросы прояснились, кандидаты начинают писать тест-кейсы. Важно понять, есть ли в их безумии своя система. Пытаются ли они просто сломать программу или хотят еще проверить, что она работает? Они осознают, когда делают первое, а когда второе? Начинают ли они с очевидных и простых вещей, чтобы найти самые важные баги как можно быстрее? Могут ли они четко изложить свой тестовый план/данные? Случайный порядок строк на доске не свидетельствует о ясности мысли, а тест-планы таких кандидатов, скорее всего, будут небрежными, если они вообще позаботятся о них. Типичный список может быть примерно такой:
— «banana»: 3 (реально существующее слово)
— «A» и «a»: 1 (простой допустимый случай с положительным результатом).
— «»: 0 (простой допустимый случай с нулевым результатом).
— null: 0 (простой ошибочный случай).
— «AA» и «aa»: 2 (случай, в котором количество символов > 1, а строка состоит из одних «A»).
— «b»: 0 (простой непустой допустимый случай с негативным результатом).
— «aba»: 2 (искомый символ в начале и конце строки для выявления багов смещения на 1 в цикле).
— «bab»: 1 (искомый символ в середине строки).
— пробелы/табуляции/и т.д.: N (символы-пропуски чередуются с N символов «A»).
— длинная строка без «A»: 0
— длинная строка с «A»: N, где N равно количеству «A».
— XnX в строке: N, где N равно количеству «A» (символы форматирования).
— {java/C/HTML/JavaScript}: N, где N равно количеству «A» (символы исполняемого кода, бага или случайная интерпретация кода).
Если кандидат пропускает какие-то из перечисленных тестов, снова звучит тревожная музыка.
Лучшие кандидаты не ограничиваются конкретным выбором входных данных задачи и переходят на более глубокие уровни тестирования. Они могут:
— Исследовать оформление, цветовую палитру и контрастность: соответствуют ли они оформлению других взаимосвязанных приложений? Доступны ли они для пользователей с дефектами зрения и т.д.?
— Побеспокоиться о том, что текстовое поле слишком короткое, и предложить увеличить его, чтобы стало удобнее вводить длинные строки.
— Поинтересоваться возможностью запуска нескольких экземпляров этого приложения на одном сервере. Нет ли опасности пересечения данных разных пользователей?
— Спросить, сохраняются ли данные? В них могут быть адреса или другая личная информация.
— Предложить автоматизировать тест с реальными данными, например загрузить страницы из словаря или фрагменты текста из книги.
— Спросить, достаточно ли быстро это работает? А как будет работать под нагрузкой?
— Уточнить, как пользователь будет попадать на эту страницу и легко ли ее найти?
— Ввести код HTML и JavaScript. Не сломает ли это отображение страницы?
— Спросить, должны учитываться символы «A» только верхнего или только нижнего регистра либо обоих?
— Попробовать копировать и вставлять строки.
А некоторые кандидаты идут еще дальше, их не удержать рамками поставленной задачи. Вот они — опытные и ценные инженерные кадры. Они могут:
— Понять, что если данные передаются серверу в HTTP GET-запросе с URL-кодированием, строка может быть обрезана в процессе передачи по интернету. Поэтому нет никакой гарантии, что поддерживается любая длина URL-адресов.
— Предложить параметризацию приложения. Почему мы считаем только «A»?
— Подумать о возможности подсчета «A» из других языков (например, со знаками ангстрема или умляута).
— Подумать о возможности интернационализации этого приложения.
— Подумать о написании скриптов или вручную составить выборку строк определенной длины (допустим, степеней двойки), чтобы найти предел длины строки и убедиться в том, что значения внутри пределов обрабатываются правильно.
— Учесть возможную реализацию и ее код. Возможно, в реализации используются счетчик для перебора символов строки и переменная-накопитель для хранения количества обнаруженных символов «A». Тогда интересно было бы менять как общее количество «A», так и длину строки в районе граничных значений.
— Задать вопросы: «Могут ли метод HTTP POST и параметры подвергнуться хакерской атаке? Нет ли здесь проблем с безопасностью?»
— Написать скрипт для генерации данных и проверки результатов, чтобы попробовать побольше интересных комбинаций свойств строки: длина, количество «A» и т.д.
Обратив внимание на длины строк, которые кандидат использует в своих тестах, можно понять, как он будет работать. Если он ограничивается понятием «длинная строка», а такое бывает часто, снова включается тревожная музыка. Продвинутые кандидаты обычно просят спецификацию строки, а затем прикидывают граничные тесты для нужных значений. Например, если максимальная длина строки 1000 символов, они попробуют 999, 1000 и 1001. Лучшие кандидаты возьмут еще и значение 2^32, и несколько промежуточных хитрых значений, например степени 2 и 10. Кандидаты должны понимать, какие значения важны для системы, а не просто брать случайные числа. Для этого им нужно хорошо разбираться в основных алгоритмах, языке, оборудовании и среде выполнения программ, потому что именно здесь водится большинство багов. Они попробуют варианты длины строки с учетом возможной реализации и подумают о возможности смещения счетчиков и указателей на единицу. Самые лучшие кандидаты понимают, что система может запоминать состояние и что в тестах нужно учесть значения, введенные раньше. Попробовать ввести одну и ту же строку несколько раз или проверить нулевую длину сразу после тысячи символов — важные сценарии, которые хорошо бы учесть.
Еще одно важное качество, которое мы ищем на собеседованиях, — это способность тестировщика управляться с неоднозначностью и замечать бессмысленную постановку задачи. Когда кандидаты задают уточняющие вопросы, мы часто меняем требования или описываем поведение, которое не имеет смысла. То, как кандидаты справляются с этим, показывает нам, как хорошо они будут работать. При нашей скорости выпусков спецификации часто открыты для интерпретаций и изменений. Если кандидат замечает, что ограничение длины строки в 5 символов выглядит странно и, скорее всего, будет раздражать пользователей, это означает, что он подумал о пользователе. Если кандидат слепо принимает странное условие и идет дальше, то, вероятно, он сделает то же самое в ходе работы, и бессмысленное поведение успешно пройдет проверку. Кандидаты, которые ставят под сомнение нелогичные условия, обычно творят на работе чудеса. Конечно, если им удается сделать это дипломатично.
В последней части собеседования на роль инженера по тестированию мы оцениваем его параметр «гугловости». Нам нужны особенные люди, которые влюблены в свою работу, любознательны, способные не просто выполнять, что им скажут, а исследовать все варианты. Мы хотим работать с теми, кто выходит за рамки обязанностей, экспериментирует. Нам нужны люди, открытые окружающему миру и тесно связанные с сообществом компьютерных технологий. Например, ребята, которые сообщают о багах в опенсорс-проектах, или те, кто выкладывает свою работу, чтобы другие люди могли повторно ее использовать, имеют высокий уровень «гугловости». Мы хотим нанимать людей, с которыми приятно работать, которые хорошо ладят с другими и привносят в нашу культуру что-то свое. Если вы можете нас чему-то научить — добро пожаловать к нам! Помните наш девиз? Он звучит: «Не делай зла». Нам нужен тот, кто укажет на зло, если увидит.
Мы отлично знаем, что интервью в крупных технологических компаниях вызывают мандраж. Мы помним, как сами переживали это. Многие не проходят собеседование с первого раза, но зато получают шанс подготовиться и набраться опыта к следующему. Давайте проясним: мы не хотим быть жесткими. Наша задача — отобрать людей, которые внесут свой вклад в компанию и, став инженерами по тестированию в Google, продолжат расти у нас. Результат должен быть хорошим и для компании, и для кандидата. Google, как и большинство компаний, которые, несмотря на большое число людей, хотят сохранить эффект маленькой уютной компании, предпочитает перестраховаться с наймом сотрудников. Мы хотим, чтобы Google оставался местом, в котором нам хотелось бы проработать еще много лет. А для этого нам нужна хорошая компания!
Управление тестированием в Google
Мы иногда шутим, что умеем управлять только профессиональными, целеустремленными и самостоятельными инженерами. Если серьезно, то руководить тестировщиками в Google непросто. Как это делать правильно? Воодушевлять, нельзя командовать. Поддерживать слаженную работу. Давать людям свободу действий, вдохновлять на эксперименты, доверять им самим принимать решения. Очень легко написать — и очень сложно выполнить.
Управлять тестировщиками в Google — задача, очень сильно отличающаяся от управления обычным отделом тестирования. Причин тому несколько: у нас намного меньше тестировщиков, мы берем на работу только очень компетентных специалистов, ценим и поддерживаем разнообразие и самостоятельность в работе. В нашем понимании управление тестированием — это больше про «вдохновлять», чем про «руководить». Это больше про стратегию, чем про ежедневное руководство к действию. Наш подход делает управление тестированием более сложным и даже непредсказуемым, если сравнивать с нашими прошлыми местами работы. Чтобы управлять тестированием в Google, нужно уметь быть лидером и смотреть далеко вперед, уметь общаться и договариваться, быть подкованным технически, уметь проводить собеседования и разбираться в людях, нанимать людей и потом регулярно оценивать их работу.
