Недавно стояла задача пополнить команду тестирования, и было открыто 2 позиции: Middle QA и Junior QA. Про middle напишу отдельно, сегодня разберу джунов.
Отбор состоял из 3х этапов:
- Задание при отклике на вакансию.
- Очная встреча — проверка hard skills.
- Третий этап ввели уже по ходу отбора — проверка soft skills.
Итак, вакансия предполагала кандидата с нулевым опытом, но хорошей теоретической базой. Знаю, что многие хотят получить первую работу хоть какую-нибудь ради опыта, не особо фильтруя проекты/компании, поэтому на этапе отклика была задача написать чек-лист для одной из веб-страниц продукта.
I этап — Чек-лист для проверки страницы
Изначально, когда продумывала это задание, вводила его с той целью, чтобы когда соискатели приходили на собеседование, уже было понимание о продукте, с которым придётся работать. Но по итогу получила больше, чем думала.
Из более 20 просмотренных откликов, выделила основные ошибки, несмотря на то, что они перекликаются между собой, вынесла их отдельно.
Ошибка 1. Делать больше, чем требуется.
Если стоит задача составить чек-лист, составляейте именно его:
- Никакого регрессионного набора, расписанного на 2 листа.
- Никаких кейсов с описанием “шаг” - результат”.
В данном случае “больше”, не значит “лучше”. Это показывает, что вы не ориентируетесь в терминах, и не можете решить самую базовую задачу. Соответственно, получаете отказ.
Ошибка 2. В чек-листе дописывать свои мысли о продукте.
Прекрасно понимаю, что позиция QA подразумевает улучшение качества продукта, но:
- Вы не видели ТЗ и не понимаете почему в каком-то функционале можно добавить 12 позиций, а не больше, как вам кажется было бы лучше.
- Опять-таки, не выполняете поставленную задачу. Если уж так хочется выделиться и дополнить свой ответ чем-то, что для вас важно отметить, сделаете отступ и напишите об этом отдельно. Не нужно всё мешать в кучу.
Ошибка 3. Находить баги.
Сама избегаю компаний, которые в качестве задания дают найти ошибки в их ПО — в таком случае вы не проходите этап отбора, вы уже работаете QA, только бесплатно и без каких-либо дальнейших гарантий.
Но вернёмся к разбору. Да, это может прозвучать странно, что находить баги для QA — это ошибка. Но в данном случае, этого не было в задании. Особенно писать баги, найденные в IE, это уже моветон.
Таким образом, отсеились даже те кандидаты, резюме которых мне понравились.
II этап — Очная встреча. Hard skills
Если раньше я скептически относилась к разным начальным курсам по тестированию, потому что считала, и до сих пор считаю, что нагуглить основные определения и разобраться в них, дело пары недель. То теперь, сертификат об окончании какого-либо из курсов в резюме, давал мне больше уверенности в том, что собеседуемый сможет рассказать про, например, уровни тестирования ПО (не все мидлы могли, но об этом позже).
Было всего 15 вопросов, и не было никаких таких, о которых нельзя было бы узнать загуглив “Вопросы на собеседовании на позицию тестировщика”. Но многие не смогли четко ответить даже на половину из них.
Топ-5 провальных вопросов:
- В каком случае тестирование может доказать отсутствие дефектов? — кто-то отвечал, что если всё-всё проверить, провести тщательно регресс, то тогда можно сказать что дефектов нет. Следующим вопросом я спрашивала про 7 принципов тестирования, не ожидая что ответят все 7, но хотя бы 3. В итоге, 2 человека из 8 смогли ответить верно.
- Критерии начала и завершения тестирования — вопрос, на который никто не ответил правильно. Следующий связанный с ним
- На основании чего следует принимать решение о завершении тестирования? — тоже почти для всех оказался сложным. Кто-то отвечал “пока всё не проверим / пока все кейсы не пройду прогон” и т.д., не вспоминая про такие внешние факторы как сроки и бюджет.
- Что представляет из себя клиент серверная архитектура приложения? — было забавно и одновременно грустно слышать ответы “клиент передаёт на сервер запросы”, а какие это запросы, для чего они нужны и вообще описать подробней данное взаимодействие — практически по нулям.
- Зачем нужно кросс-браузерное тестирование? — самый популярный ответ “чтобы убедиться, что во всех браузерах работает наш функционал”. На последующий вопрос “а почему он в каком-то из них может не работать?” внятный ответ обычно не следовал.
Также давала тест из 15 простых вопросов, взятых из подготовки в ISTQB, где при 8 правильных ответах, считала это задание успешно пройденным. Здесь было важно посмотреть собеседуемый ориентируется в остальной теоретической части, которую не включила в устный опрос.
По итогу этих двух этапов было 2 кандидата на вакансию. Один из них оказался очень подкован по техническим тонкостям, и второй собеседуемый именно на его фоне очень проигрывал. Но у меня закралось подозрение, что с ним будет не просто работать. Как показал опыт — с хорошими мозгами, но скверным характером работа будет идти медленно.
Поэтому решили ввести
III этап — Очная встреча. Soft skills
Перерыла кучу статей и пыталась найти какой-нибудь тест. Тест нашла, прошла его сама. Убедилась, что он достаточно близко отражает реальную картинку, но не была уверенна, что ответы будут даны честно. В итоге он был дан как вспомогательный инструмент.
Стала вcпомнинать собственный опыт конфликтных решений, которых за 4 года работы накопилось достаточно.
Составила 18 вопросов, даже скорее описание ситуаций, где по совокупности ответов, стало понятно насколько легко будет коммуницировать с человеком. Один из примеров:
Представьте, что у вас произошёл конфликт с одним из программистов, а на следующий день руководитель даёт тестировать фичу, которую как раз он и разрабатывал. Описанных требований недостаточно, за информацией нужно обращаться к нему. Как будете выходить из ситуации?
Так вот, собеседуемый с прекрасными hard skills, даже не попытался подойти к этому разработчику и не стал сообщать об этой проблеме своему руководителю. “Проверю, как посчитаю нужным” — ответил он, человек, который идёт на должность Junior QA.
В общем, перекос в soft skills между этими кандидатами был колосальным, и предпочтение отдала soft. И, уже спустя время, могу сказать, что не прогадала.
UPD: Когда в команду брали ещё одного джуна, решила отказаться от теста по мотивам ISTQB. Сделала вывод, что на этапе беседы становится понятен уровень, и тесты это подтверждают.
Зато добавила больше вопросов по софтам, чтобы не звать на повторное очное, а можно было бы сделать вывод сразу насколько подходит тот или иной кандидат.
Специально для тех, кто ужаснется описанному “экзамену” — в статье схематично перечислены основные моменты, на которые считаю стоит обратить внимание (не было цели подробно пересказывать интервью с каждым кандидатом).
