«­Мы – небольшая продуктовая компания» – именно с этих слов я всегда начинаю рассказ, о текущем месте работы каждому кандидату пришедшему на собеседование. Только по одной этой фразе человек может сразу понять, с какими плюсами и минусами он столкнется, если решит связать свою судьбу с нами.

У небольшой продуктовой компании, в которой я тружусь, конечно же нет своего HR’а, а потребность в новых кадрах все-таки возникает. Я всего лишь программист, ни в коем случае не претендующий на звание TeamLead’а или PM’а (откуда им тут взяться), желающий работать с хорошими, адекватными и самое главное профессиональными людьми (насколько это возможно в рамках уже указанного контекста).

К счастью, искать мне довелось тестировщика, а не … например, продажника.

Как вы уже наверное поняли, этот пост о том, как рядовому прогеру найти не рядового тестера. На мой взгляд, опыт получился интересным, но обо всем по порядку.

Статья ни в коем случае не претендует на best practice. Мне лишь хотелось показать свой подход в данном вопросе.

Статей по поиску тестировщиков полно на Хабре

Да, не мало. Многие из них я прочитал, что-то полезное вынес и для себя, но есть существенное НО: все они написаны если не мастерами своего дела, то хотя бы людьми что-то понимающими в тестировании или хантинге + не забывайте про бюджет.

Почему именно я?

Просто, я оказался единственный из прогеров, кому интересно было пощупать эту область IT (оказаться по ту сторону баррикад) и чутка оторваться от рабочих задачек.

Мне не нравится, когда HR’ы тупо делают массовую рассылку, кидают предложения исходя из ключевых тегов, не вникая глубже и т.д.

Наверное, это и было моей самой большой мотивацией – подойти к процессу найма максимально ответственно и качественно (насколько это возможно), доказать/показать самому себе: «ну можно же нормально»

Требования

Поскольку, сам я в тестирование ни ногой, то и требования составлялись соответственно:

• аналитический склад ума;
• понимание задач в тестировании ПО;
• опыт работы тестировщиком и ИТ-образование будет преимуществом.

В прогерском (приземленном) представлении, тестировщик это тот, кто ищет баги и может детально описать процесс их воспроизведения.

Процесс просмотра резюме

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

1. Оформление резюме (наличие всевозможных ошибок) – зачем мне тестировщик, который не может протестировать даже свое резюме? (вроде кажется банально, но встречалось в ~20% случаях)
2. Мне абсолютно не важен возраст, пол, внешний вид, семейное положение и прочее (читал кучу историй про «девочек» HR’ов).
3. Наличие опыта работы тестировщиком – тут думаю, все понятно: хоть какой-то опыт лучше, чем никакой.
4. Наличие образования: самое главное, чтобы был не гуманитарий, все-таки в процессе работы придется делать последовательные, логические выводы, а не выдавать зазубренную информацию. (не стоит серьезно относиться к данному пункту)
5. Сопроводительное письмо/блок «­О себе» – здесь обычно все очень плохо: все как один пишут, что именно он тот самый единственный, кто нам нужен, что он лучше всех, что мы – это компания его мечты и т.д.
   
   Но бывают конечно и исключения из правил: например, когда кандидат указывает, что он обнаружил тот или иной дефект на каком-то известном сайте или в приложении и главное, зарепортил – это однозначно плюсик в карму.
6. Ключевые навыки – весьма интересный пункт, нас не интересуют все эти QA теги: Функциональное тестирование, составление Test Case’ов, тестирование UI и т.д., хотя лучше же конечно, чтобы они присутствовали.
   
   Отдельные плюсики заслуживают теги с указанием Selenium’а и прочих средств автоматизации тестирования.
   
   Самое важное: обращаем внимание на «­не тестерские» навыки, например: Python, Unity, PHP, Компас-3D, Sql и т.д. (чуть позже расскажу, зачем)
7. Курсы/Сертификаты – весьма спорный/противоречивый пункт: если кандидат без опыта работы тестировщиком или без ИТ-образования, то наличие данного пункта приветствуется.
   
   Обычно, кандидаты прикладывают чек-листы, которые служили в качестве «­выпускной работы» – согласитесь, уже есть на что посмотреть.

Личная беседа

И так, на основе вышеуказанных «правил/рекомендаций» мы отобрали интересующих нас кандидатов, идем дальше – личное общение. Я специально не указал страшное слово «собеседование», поскольку я не собираюсь играть с кандидатом в плохого/хорошего полицейского и т.д. Я искренне хочу именно пообщаться, выстроить диалог, чтобы процесс происходил наиболее комфортно и интересно для всех сторон. По тем же причинам, я не задаю каких-то технических-специфических вопросов (ну и не забываем, что у меня нет знаний, чтобы задавать такие вопросы).

Ниже указан список тем/вопросов, на которые я бы хотел пообщаться, узнать ответы:

1. Предыдущее место работы (если есть) – тут все по стандарту:
   
   • чем конкретно занимались и как конкретно выполняли?
   • почему решили сменить?
   • какой был размер команды и какая вообще была команда на проекте?
   • какого рода были проекты, на которых Вы работали? (если конечно NDA разрешает такое)
   • какие методологии управления проектами у Вас использовались?
   • и т.д.
2. Образование – лично мне не важно его наличие или отсутствие, закончено оно или нет, очка это или заочка и т.д., меня интересует позиция моего собеседника по этому поводу, почему он принял для себя то или иное решение в данном вопросе.
3. Ключевые навыки (те самые, из резюме соискателя) – на этом этапе можно узнать много интересного и полезного. Немаловажно узнать, как именно он приобрел указанные навыки.
   
   
   Немного примеров

   • Встречается кандидат у которого ключевым навыком указан, например, – Unity, в ходе разговора выясняется, что человек в свободное от работы время пытается заниматься разработкой игр – т.е. сразу понятно, что есть интерес в IT сфере и что знаниям/умениям человека можно найти достойное применение;
   • Еще пример: если человек знает Sql или какие-то основы Php, которые, к слову, он постиг на прошлом месте работы ибо имел дело с горе прогерами, за которыми нужно было следить в оба и тыкать в конкретно неработающую строчку кода, то можно сделать вывод, что перед нами человек небестолковый;
   • Есть и отрицательные примеры: у кандидата в навыках был указан Python – звучит вроде бы круто, а в ходе разговора выясняется, что ЯП он конечно же не знает, книжек никаких не читал, а только наслышан, что питончик это круто и только поэтому указал. (WTF!?)
4. Вопросы про самые интересные/сложные баги с которыми приходилось сталкиваться – здесь, самое важное, обратить внимание на то, с какими эмоциями вам будут это преподносить: если в этот момент у человека горят глаза, буря эмоций, и т.д. – однозначно хороший знак, значит, человек болеет своим делом. Также, поинтересуйтесь, как именно человеку удалось отловить эти незабываемые/уникальные баги.
5. Тестирование в реальной жизни – в данном случае, я считаю, проф. деформация – это хорошо. Человека должно коробить от косяков софта, с которыми он встречается повсеместно. Порасспрашивайте собеседуемого про такой опыт, наверняка, ему есть, что вам рассказать (было грустно наблюдать, что в ~50% такой опыт отсутствовал).
6. Личная заинтересованность в проектах/направлении компании (не обязательно, но будет неплохим плюсиком).
   
   
   Пара примеров для понимания

   • Если вы разрабатываете ПО которое, скажем, строит оптимальный маршрут передвижений во время путешествий, то было бы неплохо, чтобы человек, которого вы ищите любил путешествовать и лично сталкивался с проблемами, которое ваше приложение решает;
   • Если вы разрабатываете игры, то тестировщику желательно любить играть в игры, следить за всеми выходящими новинками, и т.д.
7. Встречные вопросы – я очень радуюсь, когда их задают, особенно, когда их очень много. Понятно, что кандидата интересует его рабочее место, график работы, стек технологий, команда и т.д. Но когда у кандидата неподдельный интерес к проектам, которые вы делаете – это дорого стоит! Вы не представляете, как приятно слышать, когда Вам говорят, что это было самое интересное/необычное собеседование в их жизни.

Тестовое задание

А вы что думали? Не все так просто!
Не поленитесь сделать тестовое задание! Обязательно, слышите! И конечно же оно должно быть не на листочке!

Специально, на коленке (в данном случае это только на руку), было реализовано простенькое приложение (CRUD с сущностью пользователь) с заведомо внедренными косяками, а также «ТЗ».

Косяки в логике работы программы:

• отсутствие валидации данных в текстовых полях;
• контрол календаря никак не ограничен при вводе даты рождения пользователя (можно указать дату рождения завтрашним днем и т.д.);
• неправильно указывается дата создания/сохранения пользователя (-1 день от правильной даты);
• неправильно рассчитывался возраст пользователя (без использования округления);
• при закрытии приложения данные не сохранялись;
• выключение программы через 5 мин. работы (на мой взгляд, самая забавная бага);
• при изменении данных уже существующего пользователя, поле отчества всегда оставалось неизменным в списке всех пользователей;
• поле возраста не обновлялось при изменении даты рождения (обновление только при переключении между пользователями).

Косяки по верстке:

• наличие орфографических ошибок;
• TextBlock дополнительной информации о пользователе съезжал при вводе большого набора данных;
• отсутствие адаптивной верстки (при стартовом размере окна все норм, при изменении – все едет);
• отсутствие локализации у одного из полей пользователя.

Косяки по производительности (которые никто практически не нашел):

• при добавлении записи неадекватно возрастает нагрузка на ЦП;
• при удалении записи неадекватно заполняется память.

При выдаче тестового задания специально не указывался стиль заведения багов – интересно было посмотреть на разные вариации, но в основном все было одинаково (табличка/список test case’ов), иногда радовало наличие скринов.

Также испытуемым предлагалось (по желанию) подумать над тем, что по их мнению можно было добавить/изменить/убрать в функциональной части тестируемого ПО.

Желательно конечно, чтобы тестовое было выдано/сделано до вашей беседы, чтобы в случае чего его можно было обсудить.

Интересное наблюдение: встречались кандидаты без опыта работы, которые справлялись с тестовым заданием лучше, чем те, кто имел опыт за плечами.

Почему именно он?

Прежде чем раскрыть все карты, приведу немного статистики: за 2 недели поиска, вакансию посмотрели 500+ раз, откликнулось 50+ кандидатов, из них было отобрано для личной беседы и тестового задания ~10, офер бы получили 3е. Также, меня поразило, что где-то треть из всех рассматриваемых кандидатов имела опыт работы тестировщиком в крупных компаниях, которые у всех на слуху.

Но результат превзошел все мои ожидания: девушка, модельной внешности (в профиле не было фото ибо «девочки» HR’ы сразу ее сливали с ее слов), с неоконченным высшим экономическим и опытом работы тестером в 2 компаниях (одна из которых очень крупная).

Взяли ее именно за нестандартное мышление: выполняя тестовое задание она «дизассемблировала» прожку, указав в конечном итоге все специально спрятанные баги вплоть до строчки кода.

По итогу, спустя более полугода работы, мы в ней души не чаем. В нашем тестере проснулся спрятанный прогер – а мы ей все в этом охотно помогаем.

Вместо заключения

Напоследок, хотелось бы оставить несколько очевидных советов, которые почему-то мало кто соблюдает:

Работодателю – в обязательном порядке давайте обратную связь, указывайте чего конкретно не хватило соискателю (не ленитесь!).

Соискателю – не стоит «входить в ИТ» ради денег; если нет опыта – набивайте руку (открываете любое приложение/сайт и вперед тестить).