Mirantis

Часто провожу собеседования с кандидатами в QA, и практически постоянно они задают вопрос: «Почему у вас требования к потенциальному сотруднику существенно жестче, чем в других компаниях? Зачем их делать настолько высокими, какой в этом смысл?»
Ответить парой фраз тут не получится. Думаю, всё станет более понятно, если расскажу об особенностях будничной работы QA-инженеров в наших исследовательских проектах.

Харьковский филиал компании начал свое активное развитие больше полутора лет назад. И с проблемой поиска сотрудников мы столкнулись, по сути, с самого начала. Основной конёк компании — cloud-решения, применимость которых в реальных разработках очень широка: от распараллеливания сложных вычислительных алгоритмов до применения в высоконадежных распределенных системах в самых разнообразных сферах технологического бизнеса.

Практически каждый новый проект является, во многом, исследовательским и, часто, инновационным, требующим решения большого объема R&D-задач и выработки нестандартных подходов. Многообразие и различная бизнес-направленность заказных разработок не дают нам возможности поставить проекты на поток и выполнять их в режиме конвейера. В отличие от аутсоурсингового «завода» со стандартными процессами, циклами девелопмента и тестирования и прочей атрибутикой, мы создаем процессы и формируем состав команды под каждый проект индивидуально.
И если поиск опытного девелопера оказывается чуть более простой задачей, где учитывается знание определенной технологии и инструментальных средств, то с QA-ями все осложнее.

В силу специфики и архитектуры cloud-приложений, сколь-нибудь серьезное тестирование таких систем без применения автоматизации становится невозможным. Организация и отслеживание мультипоточности, загрузка данных, управление поднятыми в «облаке» узлами, мониторинг состояния разнесенной в пространстве системы в реальном времени и определение динамики её производительности становятся «неподъемными» задачами, решить которые в ручном режиме просто нереально.

Если к этому прибавить разнообразие видов бизнеса и его целей, жесткость требований и агрессивность, с которой молодые компании-заказчики штурмуют рынок, становится понятно, что классический «джентльменский набор» знаний и умений типичного QA-я нас уже не устроит. Таким образом, оказываемся перед необходимостью найти специалиста, который:

• обладает широкой технической экспертизой для эффективного выявления проблем работы различных систем, конфигураций, режимов использования (public- и private-clouds, коммуникационные библиотеки, особенности сетевых топологий и объединения разнородных компонентов, вопросы безопасности при обеспечении глобального доступа)
• демонстрирует глубокие знания процессов разработки и тестирования, необходимые для учета особенностей и выработки цикла разработки, наиболее подходящего под конкретного заказчика, проект и условия (с возможностью его постоянной «настройки» на текущие нужды и цели для команд, состоящих из инженеров в территориально удаленных офисах)
• имеет хорошие коммуникативные навыки для работы в мультиязычном коллективе и в условиях ограничений по срокам
• способен к самоорганизации и принимает ответственность за свой масштабный участок работы.
  

Еще одна критичная характеристика профессионального QA-инженера в R&D-проекте — способность к быстрому изучению новых подходов, инструментов, областей знаний. В силу разнообразия прикладных применений наших решений заранее определить спектр видов бизнеса, используемых архитектур, библиотек, технологий возможно далеко не всегда. В таких условиях наиболее оправданный подход к подбору инженеров — на основании их способностей к освоению и применению новых технологий. То есть мы не требуем от кандидатов энциклопедических знаний каких-то тем или областей — гораздо больше интересуют скорость обучения, сообразительность, логика рассуждений, умение решать практические задачи и делать правильные выводы из набора исходных фактов или условий.

Именно такой подход к выбору инженеров характерен для высокотехнологичных компаний Silicon Valley, с которыми мы продуктивно сотрудничаем. Более того, нам приходится учитывать их высокие требования к специалистам, принимающим участие в долгосрочных ODC-проектах, ведь эти сотрудники становятся полноправными членами команд разработчиков в таких известных компаниях как Cisco, Symantec, Agilent, ST Microelectronics и т.д.

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