Заходит как-то тестировщик в бар, а бармена нет — он на курсах «Как стать тестировщиком программного обеспечения».
Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам, как мы нанимаем QA на наши проекты.
Наверняка многие из вас видели пестрящую везде рекламу разнообразных курсов на тему «Как войти в IT»: от «Получи самую востребованную работу сегодня» до «QA – профессия будущего». Однако, несмотря на такой ажиотаж вокруг этих загадочных букв «QA», найти хорошего quality assurance инженера все еще тяжело — даже если вы ищете людей с небольшим опытом. Почему так? Давайте разбираться.
Из-за того, что реклама различных курсов гласит, что самым простым способом «войти в айти» является тестирование, появился существенный разброс на рынке: например, сейчас можно встретить резюме джуниоров с опытом от полугода и мидлов с опытом двух лет работы с одинаковыми запросами по зарплате. Но если быть до конца честными, то годы опыта и глубина познания теории тестирования не могут показать настоящий уровень и потенциал кандидата. На наш взгляд, как опыт измеряется не временем работы, а её качеством, так и знание теории — умением ее использовать.
За годы своей работы я провела много собеседований на позиции, связанные с тестированием, поговорила с сотнями кандидатов различных уровней (от студентов старших курсов до лидов с большим опытом в сфере) и выработала стратегию того, как нанимать хороших специалистов. Все, что я опишу, не является конечной истиной, но такой подход в нашей компании позволяет сейчас свести ошибки найма QA к минимуму.
Немного цифр: за год мы прособеседовали 79 кандидатов, из которых 11 наняли. Из нанятых нами специалистов мы ошиблись только в одном, и то ошибка была в софт-, а не хард-скиллах, поскольку кандидат полностью отвечал нашим запросам по уровню подготовки, но продуктивной работы не сложилось.
В первую очередь нужно определиться с тем, какие задачи вы хотите решить. Например, если у вас никогда не было тестирования на проекте, и ваш запрос «хочу, чтобы не было багов и были тесты», то вряд ли вам подойдет кандидат с небольшим опытом. С другой стороны, если у вас очень маленький проект с ограниченным бюджетом, а запрос в том, чтобы кто-то кроме, условно, ПМ’а смотрел продукт - то вам может подойти и новичок (однако здесь надо учитывать риск, что такому кандидату наверняка будет интересен дальнейший рост, который самообучением трудно получить).
Вторая неочевидная вещь — хорошее знание теории не гарантирует хорошую работу. Поверьте, любой QA уже прочитал не один раз, что такое попарное тестирование и каковы критерии окончания тестирования. Выучить всю теорию — это несложная задача, с которой справится любой человек, сложнее уметь ее применять и понимать ее суть. Кандидат может сколько угодно говорить про технику граничных значений и эквивалентного разделения, но какой в этом толк, если при тестировании задачи он не проверит, что аватарку на сайт нельзя загрузить размером в 500 метров, или что логин с русскими буквами может сломаться.
Поэтому мы в Константе используем способ, который заменит сто вопросов по теории: даем кандидату на разбор какой-либо кейс. Как это сделать правильно?
Для этого нужно выбрать основную направленность своего проекта + платформу, на которой чаще придется работать + ошибку, которая может быть вызвана многими факторами. Возможно даже использовать реальный баг, который был на проекте и погрузить кандидата в эту ситуацию.
«Правила игры»:
кандидат может спрашивать/уточнять любые вопросы;
он должен рассказать, что будет делать, используя любые инструменты (даже те, которых у нас нет, но он с ними работал);
интервьюер вправе менять курс проблемы, чтобы посмотреть, куда пойдут раскопки дальше;
кейс не должен включать в себя какие-то особенности, о которых кандидат не может знать (например: какие-то нетипичные решения по функционалу, ведь кандидат о них даже не подозревает и поэтому не найдет ключ проблемы).
Ниже я приведу вам примеры кейсов и идеи, куда копать, чтобы было понятнее, о чем идет речь.
Пример первый
У вас мобильное клиент-серверное приложение, использующее систему подписок, которая приносит вам основной доход — можно дать кейс, который описывал бы какую-либо ошибку именно в этом месте, например:
У нас есть экран подписок в iOS-приложении, который позволяет купить премиум доступ на месяц. Предположим, мы нажимаем на кнопку «купить», нам вылезает окошко от Apple о подтверждении оплаты, мы подтверждаем, видим «покупка успешно прошла», но контент не разблокирован. Как искать баг, и что могло пойти не так?
Примерно тут и начинается все веселье и анализ кандидата, потому что причин для такой проблемы может быть масса: от выключенного интернета, из-за которого не обновился статус контента, до бага на сервере, из-за которого пользователи не получают премиум статус. Тут уже в зависимости от того, в какую сторону ведет кандидат и что он спрашивает/предлагает, вы можете вести разговор в любую сторону и проверять его на понимание того, о чем он говорит:
Например, если он говорит «я посмотрю логи» — спросите, какие логи, что он ожидает увидеть, как эти логи посмотреть (как он смотрит логи на своем текущем проекте).
Можно уточнить, в зависимости от ситуации, что бы можно было сделать, чтобы обезопасить себя от таких багов. Например, в кейсе выше кандидат может подумать, что премиум статуса нет из-за того, что запрос оплаты не прошел на наш сервер. В таком случае можно предложить, чтобы добавили повторную отправку запроса в случае ошибки или отображение инструкции по восстановлению покупки пользователю, который после оплаты пытается попасть в закрытый контент. Такими вопросами вы можете проверить то, как ваш кандидат видит работу с продуктом и понимает ли он, как можно улучшить «узкие» места, ведь в конце концов обеспечение качества — это не только про функциональность, это также и про использование и удобство.
Еще стоит обращать внимание на разнообразие ответов, ведь в мобильных приложениях также имеет смысл перепроверять разные версии ОС, девайсы и помнить о таких вещах, как jailbreak (или root-права в андроиде).
Пример второй
Ваш проект — это сайт, на котором можно купить какие-либо товары. Очевидно, что одна из важнейших функций такого сайта — показывать товары и давать возможность их приобрести. В таком случае можно дать такой кейс:
С главной страницы вы переходите в «товары для кухни» → «кастрюли». Список товаров на продажу пуст, но известно, что кастрюли в продаже есть. Как искать баг, и что могло пойти не так?
Тут также возможна масса вероятных багов: от некорректного запроса на сервер до проблем в БД, в которой кастрюли принадлежат товарам для спальни. Смотрите на ответы кандидата, ведите его в разные ситуации и не забывайте спрашивать, как именно он будет искать проблему. Если он говорит, что возможно запрос не отправляется на получение «кастрюль» — спросите, как он будет смотреть этот запрос и что ждать от него. Спросите, что делать дальше, если сервер вернул на запрос пустой массив объектов (товаров). Тут важно смотреть, что еще сделает человек — будет ли он пробовать напрямую отправлять запросы API, будет ли смотреть в БД и т.д.
Думаю, вы сможете придумать какой-либо кейс для вашего проекта, аналогичный примерам выше, или понять какой кейс из опыта можно было бы использовать на собеседовании.
Если вам покажется, что одного такого кейса мало, или он кажется слишком сложным (например, вы опрашиваете джуниора, и его ответ вам не до конца нравится), то можете сформулировать вопрос иначе.
Сначала снова: выберите основную направленность своего проекта + платформу, на которой чаще придется работать, + функциональность, которая у вас есть/похожа на вашу/планируется быть сделанной и попросите кандидата накидать чек-лист проверок.
На основе примеров выше, что можно спросить:
Разработчик iOS-приложения отдал вам на тест новый экран подписок. У вас есть дизайн, тестовые карты для покупок, 2 опции покупки (премиум на месяц за 100 рублей и год за 300 рублей). Что будешь тестировать?
Вы сделали новый функционал: теперь можно выбрать материал из которого сделана кастрюля и поменять диапазоны цены → в результате должно меняться отображение кастрюль в соответствии с выбранными фильтрами. Как протестировать эту фичу?
В целом вся прелесть подхода собеседования через различные ситуации в том, что вы можете испытать кандидата почти на практике и исключить вероятность, что к вам пришел кто-то, кто знает теорию, но не умеет работать. Конечно же, я не призываю вас убирать обычные вопросы по теории, их можно оставить, чтобы убедиться точно в правильности своего выбора. Лично я обычно строю собеседование по такому формату:
Вопросы о прошлом месте работы (чем занимался, что использовал, плюсы и минусы — тут будет примерно понятно что человек умеет).
Кейс с багом (тут уже в «бою» смотрим поведение человека).
Если на кейсе выше были проблемы или нет достаточной уверенности, то даю кейс на составление чек-листа на какой-либо функционал.
Типовые вопросы на знание технологий, которые мы используем (например: особенности мобилок, рассказать про REST, какие-либо вопросы про методы в автоматизации - если она есть, как подменить запрос в Charles Proxy и т.д, тут все зависит от вашего проекта).
Опрос по софтам.
Напоследок я хочу оставить вам несколько примеров вопросов, которые помогут проверить софт-скиллы: я не буду давать здесь что-то конкретное, а просто предложу вопросы, которые я лично задаю кандидатам. Возможно, они наведут вас на изобретение своих собственных вопросов. Сразу скажу — здесь нет правильного ответа, здесь важно то, как кандидат отвечает и подходит ли это именно вам.
Что делать, если задач на тестирование на данный момент нет? (Вопрос на самостоятельность)
У нас есть <описание 3 разных багов на ваш выбор>, в релиз можно включить фикс только одного из них, какой? (Вопрос на понимание приоритетов)
Ты спокойно работаешь, и к тебе приходит менеджер проекта, который сообщает о том, что у него произошла ошибка: <ошибка в очень неформальном и непонятном описании>. Что будешь делать? (Вопрос на «problem solving»)
На регрессе ты обнаруживаешь критический баг и понимаешь, что выпускать его в релиз нельзя. Релиз очень важный и должен выйти сегодня. Что делать? (Вопрос об ответственности)
Расскажи о каком-нибудь своем косяке (например, краш в проде или что-то подобное). Как это вышло и как вы разрулили последствия? (Вопрос на умение рефлексировать и учиться на ошибках)
Спасибо за внимание, надеюсь, данные примеры были полезны для вас, и, прочитав статью, вы сможете улучшить процесс найма QA (или вообще его выстроить, если до этого у вас его не было). Пока!
