- Лид: доктор наук
- Мидл: клиентоориентированный программист-аналитик и нагрузочник
- Джун с опытом руководства командой
- Что делать:
- Минутка ностальгии. 2016
«За последние 5 лет у меня выработалась привычка регулярно просматривать объявления о вакансиях QA. Это помогает оценить тенденции и понять, насколько моя карьера соответствует рынку. В последнее время, особенно за последние шесть месяцев, я заметила тенденцию: требования к соискателям становятся все более фантастическими.
Лид с PhD
Даже не знаю, кто придумывает эти требования. Может, это самодеятельность HR-ов? Может, это веяния со стороны высшего менеджмента? Или это уставшие техдиры пытаются отсеять толпы претендентов? Честно говоря, не имею ни малейшего понятия. Но когда читаю, например, описание вакансии, в которой от QA Lead требуется следующее:
- Опыт разработки на одном или нескольких языках программирования.
- Профильное высшее образование.
- Опыт работы со структурами данных и алгоритмами в академической или промышленной сфере.
- Диплом магистра или PhD в области компьютерных наук или смежной технической области.
- Опыт автоматизации веб- и мобильных тестов.
- Опыт тестирования производительности, нагрузки и доступности.
- Опыт разработки технологий, доступных для людей с ограниченными возможностями.
Здесь можно возразить, что такие требования вполне адекватны для должности QA Lead, и я отчасти соглашусь. Но, для того чтобы быть экспертом или, по крайней мере, квалифицированным (и дипломированным) специалистом одновременно в области структур данных, нескольких языков программирования, в веб-автоматизации и мобильной автоматизации, тестирования производительности и юзабельности — потребуются многие годы опыта и изучение множества очень разных технологий.
В тестировании те же закономерности, что и в разработке: очень редко бывает, что хороший веб-разработчик является также и хорошим мобильным разработчиком. Как правило, везде существуют отдельные роли backend-разработчиков, frontend-разработчиков, iOS-разработчиков, Android-разработчиков и так далее. Конечно, есть фулстек-разработчики, но и у них свои ограничения. Так же и тестировщики: невозможно быть специалистом абсолютно во всех сферах QA, даже если это Lead.
Помимо всего прочего, в этой компании от QA-лида ожидают знания DevOps-процессов, а еще навыки тестирования API, UX, и опыт в подобных проектах.
Миддл — клиентоориентированный программист-аналитик и немножко нагрузочник
Посмотрим еще пример, на этот раз вакансию Middle Test Engineer:
- Опыт мобильного и веб-тестирования, знание методов автоматизации тестирования на протяжении всего цикла разработки.
- Опыт с фреймворками TestNG, Appium, Selenium, Cucumber.
- Сильные скиллы объектно-ориентированного программирования и большой опыт написания и отладки кода.
- Знание Java и/или Python на профессиональном уровне.
- Выраженная клиентоориентированность, превосходные навыки решения проблем, и аналитические способности.
- Умение работать в различных операционных системах, таких как Windows и Linux.
Хотя это описание вакансии тоже на первый взгляд кажется более-менее реалистичным, но здесь совмещают автоматизацию мобильного и веб-тестирования, лично мне это кажется неправильным. Мне приходилось заниматься автоматизированным тестированием как веб-, так и мобильных платформ, и скажу вам, что мобильная автоматизация требует значительно больше времени и усилий, чем веб-автоматизация. Здесь настораживает уже то, что быть экспертом в обеих областях подается как стандартное требование.
Разумеется, сильные технические скиллы и клиентоориентированный подход важны для QA, но, как мне кажется, эйчары должны понять, что достижение профессионального уровня, соответствующего таким требованиям, требует значительного времени и самоотдачи. И эта самоотдача должна вознаграждаться соответствующим образом.
Когда я вижу такие требования, у меня возникает вопрос, как можно быть идеально клиентоориентированным, одновременно исполняя такие обязанности, как создание автотестов мобильных и веб-приложений, их поддержка в дальнейшем, управление пайплайном, создание и изменение стратегий тестирования в соответствии с изменениями требований и запросами клиентов, участие в agile-митингах и подобные утомительные «административные» активности.
Итог будет таков: если на эту позицию найдут человека, то завышенные, нереалистичные требования приведут к перегрузке и выгоранию, из-за несоответствия должностных обязанностей и формальных ролей, и в итоге это скажется на качестве продукта.
Джун с опытом руководства командой
Рассмотрим еще одну вакансию Test Engineer, на этот раз Junior:
- Опыт валидации критериев приемки и использования поведенческой разработки (Behavioral Driven Development) или аналогичных методик.
- Опыт планирования, создания и поддержки автотестов UI и API.
- Опыт нефункционального тестирования.
- Владение лучшими практиками программирования.
- Опыт руководства одной или несколькими командами на протяжении жизненного цикла тестирования (включая внедрение «сдвига влево» и контроль CI/CD).
- Способность исследовать и осваивать новые инструменты и техники тестирования.
- Отличные коммуникативные навыки.
- Стремление к саморазвитию и наставничеству.
Ок, это нормальный набор требований — но только не для рядового тестировщика, а для более высокой должности. Разумеется, Senior или тем более Lead QA должен иметь опыт тестирования UI и API, конечно же иметь обширный опыт автоматизации, владеть пайплайн-инструментами, также может менторить других членов команды. Как попали такие требования в вакансию уровня Junior? Что касается нефункционального тестирования в требованиях к рядовой должности Test Engineer, то это тоже перебор. В специфической сфере нагрузочного тестирования как правило работают опытные тестировщики с солидными хард-скиллами, освоившие непростые инструменты НТ.
Что делать
Теперь, когда мы обсудили кринж-вакансии, и оценили масштаб проблемы, давайте подумаем, что делать. Осмелюсь предложить практические рекомендации как для тестировщиков, так и для QA-менеджеров и рекрутеров.
Для тестировщиков:
- Непрерывное обучение: В создавшейся ситуации нет иного выхода, кроме постоянного повышения квалификации. Старайтесь изучать новые технологии, инструменты и лучшие практики. Как? Как обычно, с помощью онлайн-курсов, воркшопов и профессиональных сертификаций. Понятно, что экспертом во всех сферах тестирования быть невозможно — поэтому сосредоточьтесь на одной основной области; будь то мобильные, веб- или десктопные системы и т.д., и в своей области поднимайтесь к уровню эксперта.
- Нужно, необходимо быть активным участником QA-комьюнити.
- Желательно время от времени поддерживать связь со знакомыми QA-менеджерами и эйчарами, узнавая об изменениях в технологическом стеке в интересующих компаниях. И вообще нетворкинг — надежный и (все еще) работающий способ трудоустроиться на таком напряженном рынке.
- Давайте хотя бы пытаться «сдвигать» требования к более адекватным: Наша общая цель — реалистичные требования в вакансиях QA. Давайте, может быть, коллективно высказывать эйчарам свое недоумение по поводу сложившейся аномальной ситуации и призывать уделять первостепенное внимание действительно важным для QA навыкам, и практическому опыту на реальных проектах. Ведь практический опыт важнее, чем шаблонное резюме, переполненное названиями технологий и аббревиатурами, смысла которых скорее всего не знает ни рекрутер, ни соискатель.
Для рекрутеров:
- Нормальное, а не формальное общение с QA-менеджерами: Поддерживайте полноценное, а не формальное сотрудничество с QA-отделом и их менеджером, чтобы требования в вакансии четче отражали навыки и опыт, необходимые для данной роли.
- Требования должны быть реалистичными (а не завышенными фактически на два уровня).
- В вакансии должны быть описаны технологии и инструменты, используемые в компании, а не «стандартные для должности».
- Фидбек от уже принятых QA: После того как ваш кандидат будет все-таки принят и отработает 3-6 месяцев, спрашивайте их, насколько описание должности соответствовало реальной роли, и в дальнейшем корректируйте описания в вакансиях, ориентируясь на реальную ситуацию на рынке.
Минутка ностальгии. Что изменилось в QA с 2016 года
В заключение хочу сказать, что только сейчас я поняла, как изменилась роль QA за 8 лет, и, кажется, не в лучшую сторону. Нынешняя тенденция фантастических требований к соискателям настораживает.
Когда я собеседовалась восемь лет назад, то все, что мне нужно было знать чтобы меня взяли — Testrail, веб-тестирование, как написать тест-план, как оформить репорт, и, кажется, что такое регрессионное тестирование.
По мере того как архитектура стандартных приложений становилась сложнее, роль QA требовала освоения дополнительных скиллов. Чтобы удержаться в профессии, мне пришлось изучить: HTML, основы бэкенда и фронтенда, SQL, тестирование API, автоматизацию тестирования UI, практики CI/CD и некоторые другие вещи.
Это ОК, но сейчас, спустя восемь лет, я вижу, что те навыки, которые раньше считались как бы «бонусными», гарантирующими трудоустройство при любых условиях, теперь стали считаться чуть ли не «базовыми», и их указание в резюме уже, кажется, ничего не гарантирует.
Я люблю IT за то, что эта сфера непрерывно развивается, заставляя всех, кто в ней работает, адаптироваться и расти. Но сейчас мне кажется, что процесс трудоустройства в QA-отдел практически любой IT-компании становится похож на попытку попасть в какой-то безбашенный стартап. Кому-то, наверное, такое нравится, есть такие люди, которые считают, что любые трудности делают нас сильнее.
Мой совет тестировщикам, еще раз: продолжайте учиться, потому что, как видите, чтобы удержаться в этой профессии, вам нужно стать реальным профессионалом. А рекрутерам еще раз посоветую: не усложняйте ваши процессы искусственными барьерами, будьте более реалистичны в описаниях ролей QA и требований. Уточняйте у QA-менеджеров и лидов, кто им нужен и в какой роли, и точнее прописывайте в вакансиях стек. Это поможет соискателям лучше понять, кого вы ищете. Таким образом, соискатели и работодатели быстрее найдут друг друга.»
О причинах сложившейся ситуации:
