Джеймс Уиттакер - Как тестируют в Google

— Учесть возможную реализацию и ее код. Возможно, в реализации используются счетчик для перебора символов строки и переменная-накопитель для хранения количества обнаруженных символов «A». Тогда интересно было бы менять как общее количество «A», так и длину строки в районе граничных значений.

— Задать вопросы: «Могут ли метод HTTP POST и параметры подвергнуться хакерской атаке? Нет ли здесь проблем с безопасностью?»

— Написать скрипт для генерации данных и проверки результатов, чтобы попробовать побольше интересных комбинаций свойств строки: длина, количество «A» и т.д.

Обратив внимание на длины строк, которые кандидат использует в своих тестах, можно понять, как он будет работать. Если он ограничивается понятием «длинная строка», а такое бывает часто, снова включается тревожная музыка. Продвинутые кандидаты обычно просят спецификацию строки, а затем прикидывают граничные тесты для нужных значений. Например, если максимальная длина строки 1000 символов, они попробуют 999, 1000 и 1001. Лучшие кандидаты возьмут еще и значение 2^32, и несколько промежуточных хитрых значений, например степени 2 и 10. Кандидаты должны понимать, какие значения важны для системы, а не просто брать случайные числа. Для этого им нужно хорошо разбираться в основных алгоритмах, языке, оборудовании и среде выполнения программ, потому что именно здесь водится большинство багов. Они попробуют варианты длины строки с учетом возможной реализации и подумают о возможности смещения счетчиков и указателей на единицу. Самые лучшие кандидаты понимают, что система может запоминать состояние и что в тестах нужно учесть значения, введенные раньше. Попробовать ввести одну и ту же строку несколько раз или проверить нулевую длину сразу после тысячи символов — важные сценарии, которые хорошо бы учесть.

Еще одно важное качество, которое мы ищем на собеседованиях, — это способность тестировщика управляться с неоднозначностью и замечать бессмысленную постановку задачи. Когда кандидаты задают уточняющие вопросы, мы часто меняем требования или описываем поведение, которое не имеет смысла. То, как кандидаты справляются с этим, показывает нам, как хорошо они будут работать. При нашей скорости выпусков спецификации часто открыты для интерпретаций и изменений. Если кандидат замечает, что ограничение длины строки в 5 символов выглядит странно и, скорее всего, будет раздражать пользователей, это означает, что он подумал о пользователе. Если кандидат слепо принимает странное условие и идет дальше, то, вероятно, он сделает то же самое в ходе работы, и бессмысленное поведение успешно пройдет проверку. Кандидаты, которые ставят под сомнение нелогичные условия, обычно творят на работе чудеса. Конечно, если им удается сделать это дипломатично.

В последней части собеседования на роль инженера по тестированию мы оцениваем его параметр «гугловости». Нам нужны особенные люди, которые влюблены в свою работу, любознательны, способные не просто выполнять, что им скажут, а исследовать все варианты. Мы хотим работать с теми, кто выходит за рамки обязанностей, экспериментирует. Нам нужны люди, открытые окружающему миру и тесно связанные с сообществом компьютерных технологий. Например, ребята, которые сообщают о багах в опенсорс-проектах, или те, кто выкладывает свою работу, чтобы другие люди могли повторно ее использовать, имеют высокий уровень «гугловости». Мы хотим нанимать людей, с которыми приятно работать, которые хорошо ладят с другими и привносят в нашу культуру что-то свое. Если вы можете нас чему-то научить — добро пожаловать к нам! Помните наш девиз? Он звучит: «Не делай зла». Нам нужен тот, кто укажет на зло, если увидит.

Мы отлично знаем, что интервью в крупных технологических компаниях вызывают мандраж. Мы помним, как сами переживали это. Многие не проходят собеседование с первого раза, но зато получают шанс подготовиться и набраться опыта к следующему. Давайте проясним: мы не хотим быть жесткими. Наша задача — отобрать людей, которые внесут свой вклад в компанию и, став инженерами по тестированию в Google, продолжат расти у нас. Результат должен быть хорошим и для компании, и для кандидата. Google, как и большинство компаний, которые, несмотря на большое число людей, хотят сохранить эффект маленькой уютной компании, предпочитает перестраховаться с наймом сотрудников. Мы хотим, чтобы Google оставался местом, в котором нам хотелось бы проработать еще много лет. А для этого нам нужна хорошая компания!

Мы иногда шутим, что умеем управлять только профессиональными, целеустремленными и самостоятельными инженерами. Если серьезно, то руководить тестировщиками в Google непросто. Как это делать правильно? Воодушевлять, нельзя командовать. Поддерживать слаженную работу. Давать людям свободу действий, вдохновлять на эксперименты, доверять им самим принимать решения. Очень легко написать — и очень сложно выполнить.

Управлять тестировщиками в Google — задача, очень сильно отличающаяся от управления обычным отделом тестирования. Причин тому несколько: у нас намного меньше тестировщиков, мы берем на работу только очень компетентных специалистов, ценим и поддерживаем разнообразие и самостоятельность в работе. В нашем понимании управление тестированием — это больше про «вдохновлять», чем про «руководить». Это больше про стратегию, чем про ежедневное руководство к действию. Наш подход делает управление тестированием более сложным и даже непредсказуемым, если сравнивать с нашими прошлыми местами работы. Чтобы управлять тестированием в Google, нужно уметь быть лидером и смотреть далеко вперед, уметь общаться и договариваться, быть подкованным технически, уметь проводить собеседования и разбираться в людях, нанимать людей и потом регулярно оценивать их работу.

Обычно в Google чрезмерная формализация управления вызывает напряженность. Перед директорами по тестированию, менеджерами и руководством Google стоит сложная задача — дать инженерам столько свободы, чтобы не ограничить их работу лишними условностями, но и не позволять им расслабляться и плевать в потолок. Google не жалеет ресурсов на крупномасштабные, стратегические решения. Наши менеджеры помогают избежать разработки дубликатов тестовых фреймворков и чрезмерных вложений в малые тесты, при этом они помогают собирать команды для масштабных проектов. Без такого присмотра внутренние проекты тестирования часто не выживают, если остаются всего лишь проектом одного инженера или не выходят за рамки «двадцатипроцентного» времени.

«Пиратский корабль» — метафора, которую мы используем, когда говорим про управление командами тестирования в Google. Наше тестирование — это мир, в котором инженеры по природе своей постоянно задают вопросы, требуют убедительных данных и постоянно оценивают решения своего руководства. Помните, что мы набираем в свою команду самостоятельных и инициативных людей, которые сами могут позаботиться и о себе, и о своей работе. Но и ими же нужно и управлять.