Эта статья будет интересна тем, кто так же как и мы столкнулся с проблемой подбора подходящего специалиста в области тестирования.

Как ни странно, но с увеличением количества ИТ-компаний в нашей республике увеличивается только число достойных программистов, но не тестировщиков. В эту профессию рвутся многие, но не многие понимают ее смысл.

Не могу сказать за все ИТ-компании, но мы за своими специалистами в области качества закрепили роль QA/QC. Они входят в состав команды разработчиков и участвуют на всех этапах разработки, начиная от исследования и заканчивая выпуском новой версии.

Тестировщик в команде, еще на этапе планирования должен обдумать все функциональные и нефункциональные требования к приемке пользовательской истории. Он должен не хуже программистов, а даже лучше, разбираться в эксплуатационных характеристиках продукта и помогать команде не принимать неверных решений еще на этапе планирования. Тестировщик должен иметь четкое представление о том, как реализуемая функциональность будет работать и какие подводные камни могут быть. Тест-планы и тест-кейсы наши тестировщики составляют сами, так же как и готовят все необходимые стенды для тестирования. Тестировать по готовой спецификации как monkey-кликер, не наш вариант. Работая внутри команды, он должен помочь выпустить достойный продукт и вовремя забить тревогу, если что-то пошло не так.

С чем мы столкнулись, когда искали тестировщиков

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

Далее, я расскажу какие шаги мы предпринимали и на какие грабли наступали, чтобы найти тех самых, долгожданных борцов за качество.

Как мы пытались исправить ситуацию

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

1. Пробовали применить ассессмент?практики для выявления среди уймы “уйтивайтишников”, тех самых, из кого сможем вырастить сильных специалистов.
   
   Группе потенциальных кандидатов, с приблизительно одинаковым уровнем знаний, мы предлагали выполнить задания. Наблюдая за их мыслительным процессом старались выделить самого перспективного кандидата.
   
   В том числе, мы придумали задания на проверку внимательности, понимания возможностей технологий и особенностях мультикультурности:
   
   
   
   
   
   
2. Проводили митапы для тестировщиков, чтобы расширить границы понимания профессии у существующего контингента.
   
   Расскажу немного о каждом из них.
   
   Ufa Software QA and Testing Meetup #1 — это наша первая попытка собрать неравнодушных к профессии и заодно понять интересно ли будет публике то, что мы хотим донести до них. В основном, наши доклады были о том, с чего лучше начинать, если уж ты решил стать тестировщиком. Помочь новичкам открыть глаза и взглянуть на тестирование «по-взрослому». Мы рассказывали о шагах, которые необходимо сделать начинающим тестировщикам, чтоб влиться в профессию. О том, что такое качество и как его добиться в реальных условиях. А также, что такое автоматическое тестирование и, где его целесообразнее применять.
   
   
   
   Далее, с интервалом в 1-2 месяца, мы провели еще два митапа. Участников уже было раза в два больше. На «Ufa Software QA and Testing Meetup #2» мы более глубже окунулись в предметную область. Рассказали про багтрекинговые системы, про тестирование UI/UX, затронули Docker, Ansible, а также рассказали о возможных конфликтах между разработчиком и тестировщиком и способах их разрешения.
   
   Наш третий митап «Ufa Software QA and Testing Meetup #3» косвенно касался работы тестировщиков, но был полезен для того, чтобы вовремя напомнить программистам об их техническо-организационном долге: нагрузочное тестирование, e2e тестирование, Selenium в автотестировании, уязвимости веб-приложений.
   
   Все это время мы учились делать нормальный свет и звук в вещаниях с наших мероприятий:
   
   > Первые шаги в тестировании – Ufa Software QA and Testing Meetup #1
   > Тестирование UI/UX – Ufa Software QA and Testing Meetup #2
   > Тестирование безопасности, нагрузочное тестирование и автотестирование – Ufa QA and Testing Meetup #3
3. И в конце решили попробовать провести хакатон для тестировщиков

Как готовились и проводили хакатон для тестировщиков

Для начала попытались понять, что это за «зверь» такой и как его обычно проводят. Как выяснилось, мероприятия подобного рода в РФ проводили не так много раз, и идей позаимствовать негде. Во?вторых, не хотелось сразу, в сомнительное на первый взгляд мероприятие, вкладывать много ресурсов. Поэтому, решили, что будем делать короткие мини хакатоны, не на весь цикл работы QA, а на отдельные этапы.

Основная наша головная боль — это недостаток у местных тестировщиков практики по формированию внятных карт тестирования. Не уделяют времени исследованиям на этапе до реализации пользовательских историй и созданию понятных для разработчиков критериев приемки по функциональным и нефункциональным требованиям, UI/UX, безопасности, рабочим и пиковым нагрузкам. Поэтому, мы решили, для первого раза, пройтись по самой интересной и творческой части их работы — анализ и формирование требований на предпроектном исследовании.

Прикинули потенциальное количество участников и решили, что нам нужно минимум 5 бэклогов на MVP-релизы, 5 продуктов и 5 человек, которые будут выполнять роль владельцев продуктов, расшифровывать бизнес-потребности и принимать решения по ограничениям.

Вот что у нас получилось: беклоги для хакатона.

Основная идея была придумать темы максимально далекие от всей повседневной работы участников и дать им простор для творческого полета фантазии.

Какие ошибки мы допустили и что можно сделать лучше

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

Вот митапы дело хорошее. Создается обширная база для проработки, повышается общий уровень участников. Компания становится все более узнаваемой на рынке. Но, трудоемкость таких начинаний не малая. Нужно четко понимать, что в год на проведение митапов будет уходить примерно 700-800 человеко-часов.

Что касается хакатона тестировщиков. Такого рода мероприятия еще не успели надоесть, так как в отличии от хакатонов для разработчиков, проводятся намного реже. Плюс этой затеи в том, чтобы в незанудной манере можно обменяться большим объем практических знаний и довольно точно определить уровень каждого участника.

Проанализировав итоги мероприятия, мы поняли, что ошибок допустили ворох:

1. Самой непростительной ошибкой было полагать, что нам хватит 4-5 часов. В итоге, только вводная и знакомство с бэклогами заняли почти 2 часа.
   Работа с владельцами продуктов на начальном этапе и время, чтобы погрузиться в предметную область, заняло еще столько же. Так что на всестороннюю проработку карт тестирования оставшегося время явно не хватило.
2. Времени и сил на детальный фидбек по каждой карте совсем не хватило, поскольку была уже ночь. Поэтому, эта часть явно нами была провалена, а изначально предполагалась как самая ценная в хакатоне.
3. Оценивать качество проработки мы решили простым голосованием всех участников, выделив на каждую команду по 3 голоса, которые они могли отдать за наиболее качественные работы. Возможно, лучше было бы организовать жюри.

Чего добились

Свою задачу мы частично решили и сейчас у нас работают 4 бравых красавца, прикрывающих тылы 4 команд разработки. Значительного пула потенциальных сильных кандидатов и ощутимых изменений в уровне QA-сообщества города пока не заметили. Но, некоторые подвижки есть и это не может не радовать.