Как тестируют в Google
QA
Как тестируют в 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».
— 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