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

QA

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

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

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

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

Итак, когда все вопросы прояснились, кандидаты начинают писать тест-кейсы.

    1. Пытаются ли они просто сломать программу или хотят еще проверить, что она работает?
    2. Они осознают, когда делают первое, а когда второе?
    3. Начинают ли они с очевидных и простых вещей, чтобы найти самые важные баги как можно быстрее?
    4. Могут ли они четко изложить свой тестовый план/данные?

Случайный порядок строк на доске не свидетельствует о ясности мысли, а тест-планы таких кандидатов, скорее всего, будут небрежными, если они вообще позаботятся о них. Типичный список может быть примерно такой:

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

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

Если кандидат замечает, что ограничение длины строки в 5 символов выглядит странно и, скорее всего, будет раздражать пользователей, это означает, что он подумал о пользователе. Если кандидат слепо принимает странное условие и идет дальше, то, вероятно, он сделает то же самое в ходе работы, и бессмысленное поведение успешно пройдет проверку.

Испочник: книга Как собеседуют в Google