Меня недавно спросили, был ли у меня чеклист или какое-то тестовое задание, когда я нанимал тестировщиков. Решил оформить ответ в виде поста.

При найме QA любого уровня я помимо стандартных HR-вопросов часто задавал лишь один – протестировать самую банальную форму авторизации с нуля, с двумя полями (логин и пароль) и кнопкой “Войти”. Если искал тестировщика мобильных приложений, то говорил, что форма в мобильном приложении, иначе – на сайте.

Когда я только начинал собеседовать, было ещё несколько вопросов, потому что думал, что одного такого простого будет недостаточно. Я ошибся – мало кто отвечал на него даже на уровне “нормально”.

Сама по себе форма авторизации, несмотря на простоту, является формой с двумя совершенно разными полями, с каким-то грузом в виде окружения. А форма – это проверки на валидацию, граничные значения, условия по ТЗ (например, длина пароля), всевозможные type=“email” для распознавания браузерами и автодополнения.

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

Чем это лучше в сравнении с тестированием лифтом и карандашей? Это реальный сценарий. Не такой сложный, чтобы потратить на него день, как некоторые тестовые задания. Не такой лёгкий, чтобы ответить за минуту. Это реальный рабочий кейс, с таким может столкнуться каждый тестировщик. Он не заставляет мыслить нестандартно, потому что бизнесу не нужны сценарии про полнолуние и пролитую кровь девственниц. Бизнесу нужны проверки реальных кейсов.

Я не говорю, что нестандартное мышление для тестировщика – это плохо, наоборот. Но в первую очередь надо понять, что он умеет проверять работоспособность.

По ответу на вопрос сразу видно много вещей:

• Понимает ли человек, что такое тестирование и в чём его главная цель. Это определяется по тому, начинает он сначала ломать форму, вводить невалидные данные или проверит, что через неё можно войти с правильным логином/паролем.
• Как человек привык работать. По готовым тест-кейсам, документации или просто опираясь на здравый смысл (самый распространённый вариант, agile-way).
• Как человек мыслит. Совершает проверки вразнобой или идёт по какому-то внутреннему плану (некоторые кандидаты прямо записывали чеклист во время собеседования).
• Как человек объясняет. Рисует форму на бумаге, просит открыть на ноутбуке какой-нибудь сайт с формой и показывает всё на ней или тестирует абстрактно, в голове. Если что, все варианты приемлемы.
• Задаёт ли человек вопросы. Например, какого типа значения предусмотрены в поле логина. Или как он может зарегистрировать пользователя – через базу, в админке приложения или есть соседняя форма регистрации.
• Насколько дотошно он тестирует. Поверхностно или перечисляет конкретные кейсы, например, обозначает граничные значения полей.
• Знает ли человек о нефункциональных типах тестирования. Например, тестирование UX и безопаности (тут иногда требуется наводящий вопрос). Тут часто вспоминают галку “Запомнить меня”, в этой ветке разговора можно узнать про понимание cookies и сессий.
• Какие инструменты использует. Тут могут всплыть devtools, снифферы и всевозможные плагины.
• Насколько серьёзно человек относится к собеседованию. Некоторые отвечали настолько на отвали, что не понимали даже намёков, что я бы хотел услышать ответ поподробнее.

Кандидата не нужно останавливать, только направлять. Давать время на подумать – это всё же собеседование, а не обычная рабочая ситуация, где он в расслабленном режиме может подумать и прикинуть план. Что-то может вылететь из головы, и это нормально.

Пока человек говорит, можно оценить и софт-скиллы – как он разговаривает и объясняет, как реагирует на небольшую критику (“вот тут мало кейсов учтено”).

Стоит учитывать специфику прошлой работы человека – была это аутсорс или продуктовая разработка, т.к. стиль тестирования сильно разнится. Если нанимаем в продукт, то к человеку из аутсорса надо отнестись с пониманием (он привык работать по-другому), но проверить, подойдёт ли ему новый стиль работы.

Обычно бывает четыре сценария:

1. Человек идёт структурно и хорошо, но производит не все проверки – всё равно хорошо. Задаём направляющие вопросы, получаем ещё много годных проверок. Если джун говорит структурно и не прыгает от одной проверки к другой - жирный плюс, что можно брать. Технику нарастить проще, чем изменить мышление.
2. Человек начинает сразу ломать, прыгает от одной возможной уязвимости к другой – тут стоит задуматься и смотреть на качество самих проверок. Если позиция джуна и проверки хорошие, то можно поставить плюс в зачёт. Главное потом – пояснить, что же всё-таки такое тестирование и какой результат в первую очередь хочет бизнес и разработчик.
3. Человек производит кучу проверок, говорит про нефункциональное тестирование (не обязательно использует все виды). Иногда прыгает, но проверяет большую часть позитивных и негативных сценариев – тут отлично (жаль, что редко).
4. Человек считает, что это не главная проверка, слишком легко для тестового задания. Проходится по верхам, без уточнений, когда просишь конкретные проверки. Тут встаёт вопрос, а сработается ли вообще такой человек и не будет ли он и всё остальное тестировать вот так.

Что ещё можно проверить?

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

• заголовок – в идеале лаконичный, без мусора и по существу (не “Форма авторизации не работает”, а “Поле “Пароль” в форме авторизации регистронезависимо”);
• использование шаблон для описания – стандартный “Шаги воспроизведения / Ожидаемый результат / Фактический результат” (формулировки могут отличаться);
• грамотность;
• понятность и точность описания.

Можно поспрашивать по теории (виды тестирования), базе данных и работе с API, если для вас это актуально.

Можно усложнить задачу, добавив форму регистрации, но учтите, что пересекающихся кейсов будет много.

Идеально, если человек, проводящий собеседование, хорошо и давно тестирует. Он будет правильнее интерпретировать ответы, задавать хорошие наводящие вопросы.

И всегда помните – научить человека можно, изменить характер и мышление – очень сложно.