Уиттакер . - Как тестируют в Google

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

— «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».

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