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

— Вы мечтаете поработать над продуктом, который сильно повлияет на жизнь людей и будет у всех на слуху.

— Вам становится плохо при виде пользовательских интерфейсов некоторых веб-сайтов. Вы не понимаете, как с ними вообще кто-то работает.

— Визуализация данных вызывает у вас радостное возбуждение.

— Вы ловите себя на желании пообщаться с людьми из реального мира.

— Вы не понимаете, почему вам нужно ввести «i», чтобы набрать текст в одном известном текстовом редакторе.[45]

— Успех для вас — помочь реализоваться идеям других инженеров, а потом испытать эти идеи в боевых условиях.

— Когда вас спрашивают, готов ли продукт к выпуску, вы можете сказать: «Я думаю, да».

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

Обе роли очень важны, чтобы создать великолепный продукт.

Собеседование с инженерами по тестированию

Ура, мы обнаружили необходимую комбинацию навыков и немедленно зовем кандидата на интервью. Нас часто спрашивают, как мы собеседуем инженеров по тестированию, причем это самый частый вопрос, который нам задают буквально везде. Полный список вопросов мы приводить не будем, но покажем несколько примеров, чтобы проиллюстрировать наш подход. Учтите, что после публикации эти вопросы уже неактуальны!

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

Мы даем тестовую задачу, зависящую от многих входных факторов и условий среды, а потом просим кандидата перечислить самые интересные из них. Например, мы просим кандидата протестировать веб-страницу (рис. 3.26) с одним полем ввода и кнопкой, при нажатии которой подсчитывается количество букв «A» в текстовой строке. Вопрос: составьте список входных строк, которые вы хотите протестировать.

Рис. 3.26. Простой пользовательский интерфейс для тестового вопроса

Некоторые кандидаты бросаются с места в карьер и начинают строчить тест-кейсы. (Звучит тревожная музыка.) Скорее всего, они недостаточно подумали над задачей. Мы воспринимаем стремление к количеству, а не к качеству, как знак опасности. Мы пришли к этому с опытом. О кандидате можно многое узнать еще до того, как он справится с задачей, просто посмотрев на то, как он ее решает.

Лучший кандидат — тот, который начинает задавать уточняющие вопросы: прописные или строчные буквы? А только ли английские? А текст стирается после вычисления ответа? Как насчет повторного нажатия кнопок? И так далее.

Итак, когда все вопросы прояснились, кандидаты начинают писать тест-кейсы. Важно понять, есть ли в их безумии своя система. Пытаются ли они просто сломать программу или хотят еще проверить, что она работает? Они осознают, когда делают первое, а когда второе? Начинают ли они с очевидных и простых вещей, чтобы найти самые важные баги как можно быстрее? Могут ли они четко изложить свой тестовый план/данные? Случайный порядок строк на доске не свидетельствует о ясности мысли, а тест-планы таких кандидатов, скорее всего, будут небрежными, если они вообще позаботятся о них. Типичный список может быть примерно такой:

— «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. Кандидаты должны понимать, какие значения важны для системы, а не просто брать случайные числа. Для этого им нужно хорошо разбираться в основных алгоритмах, языке, оборудовании и среде выполнения программ, потому что именно здесь водится большинство багов. Они попробуют варианты длины строки с учетом возможной реализации и подумают о возможности смещения счетчиков и указателей на единицу. Самые лучшие кандидаты понимают, что система может запоминать состояние и что в тестах нужно учесть значения, введенные раньше. Попробовать ввести одну и ту же строку несколько раз или проверить нулевую длину сразу после тысячи символов — важные сценарии, которые хорошо бы учесть.