С лёгкой подачи многочисленных образовательных ресурсов за последние несколько лет широко распространилось поверье, что в ИТ попасть легко и что чуть ли не самой простой дорожкой для этого “войти в найти” является именно QA. Не стану кривить душой, и сам лет 7 назад был грешен и частично поспособствовал этому тренду, хотя в изначальном своем посыле я все-таки всегда настаивал на необходимости обучиться и обучаться профессии QA-инженера.
Тем не менее, хочется выразить собственную позицию по этому вопросу с поправкой на актуальные требования и наблюдения за тем, как изменился рынок и его ожидания от специалистов в этой области. Знание и понимание текущих потребностей поможет более трезво взглянуть на профессию как самим кандидатам, так и коллегам, с которыми они работают, а также HR’ам и непрофильным нанимающим менеджерам, которые делают свои первые шаги в поиске QA-инженеров к себе в команду.
Для большего понимания сути вопроса хочется сделать короткую историческую ретроспективу, отталкиваясь в том числе от собственного опыта в профессии.
Начало-середина нулевых
В начале-середине нулевых еще не было устойчивого тренда на “хочу в IT” и эта сфера деятельности была интересна скорее гикам, задротам и энтузиастам своего дела. Таковым был и я, когда в 2005 году попал в ИТ через геймдев. В то время рынок был непритязателен, и для устройства во многие компании тех лет было достаточно желания работать как такового, базовых знаний и навыков на уровне “уверенный пользователь ПК”, “опыт работы с MS Office” и умения решать задачи сродни “Почему канализационный люк круглый?” и “Как протестировать карандаш?”.
Согласитесь, и правда, не самый высокий порог для входа. Да и после в работе еще достаточно продолжительное время никто не ожидал от специалиста владения специфической терминологией, навыков работы с инструментами, а как таковой “опыт работы” был понятием весьма условным. По сути от тестировщика требовалось проводить испытания, зачастую не очень сильно формализованные с весьма пространными результатами тестирования. Не было необходимости работать на упреждение дефектов и глубоко анализировать причины их возникновения, равно как и стараться качественно увеличивать эффективность собственной работы за счёт оптимизации процессов, автоматизации тестирования и подобных изменений.
Не хочу никого обидеть, сам был таким, но тестировщики тех лет зачастую были классическими monkey-тестерами и до современных QA-инженеров многим было, как до Луны. Для понимания контекста тех лет, свой первый чек-лист на тестирование я написал через год работы и даже не очень понимал, что это был чек-лист:) До выхода библии тестирования тех лет, “Тестирования.com”, была еще пара лет, про многочисленные конференции и митапы речи и не шло в принципе (первое летописное упоминание о SQA Days датируется 2007 годом, когда на конференцию пришло 40 участников). Отчасти именно поэтому запросы к специалистам в сфере QA были такими невысокими, просто неоткуда было взять высококвалифицированные кадры. Безусловно они были, но их было очень и очень немного.
Начало-середина десятых
Спустя 7-10 лет, в начале-середине десятых, рынок стал меняться. Огромное количество компаний, которые стали появляться как грибы после дождя, породили колоссальный спрос на специалистов данной области. А вместе с тем существенно увеличились и требования к специалистам. Теперь уже на собеседование могли на полном серьезе спрашивать про виды тестирования (пусть порой на примере все того же “тестирования карандаша”), могли проверить навыки тест-дизайна через задачку “протестируйте форму авторизации”. Могли даже поковырять щупабельно за техническую часть, например, devtools, selenium, работа с БД и прочим, что требовалось иногда не столько для реального использования, сколько для “фейс-контроля” кандидатов тех лет. Требование уровня “знание SQL на уровне простых запросов” даже до сих пор живо в ряде описаний вакансий, хотя по факту и сейчас может быть неиспользуемым в реальной работе. В тот момент уже недостаточно было простого желания, нужна была первичная подготовка к профессии, хотя бы на уровне прочтения пары книг и возможно просмотра какого-то курса по тестированию. Среди прочих, к слову, был и мой курс, что читал для студентов ВМК МГУ, и судя по многочисленным откликам его слушателей в офлайне/онлайне, он стал хорошим подспорьем для старта карьеры тех лет.
Реальный диалог тех лет от знакомых: Кандидат: проходил какой-то курс по тестированию на Youtube, автора уже не помню Нанимающий менеджер: лектор был в костюме adidas? Кандидат: ...эм, да:) Нанимающий менеджер: знаем мы этого лектора, годный курс:)
С инженеров тех лет все чаще требовалось не просто провести тестирование, но и расставить по всему жизненному циклу разработки ПО Quality Gate там, где этого требовал процесс и была видна очевидная потеря качества. Именно тогда стал набирать обороты и популярность пресловутый shift-left testing (хотя номинально одно из первых упоминаний о нём датируется еще 2001 годом). По сути от тестирования перешли к полновесному QC и местами даже QA. Соответственно задачей специалистов было уже не столько оценить качество продукта, сколько существенно повлиять непосредственно на его обеспечение как такового.
Уже тогда можно было констатировать в QA, стало не так уж просто. Да в ИТ в целом, не стоит думать, что сфера качества развивалась особняком от остальной индустрии. Именно тогда стали появляться многочисленные курсы и программы обучения для начинающих специалистов, которые собственно и триггернули историю с “войти в найти”, и как отметил выше, по-своему, и я не был исключением.
Наши дни
Давайте теперь перенесемся в наши дни, начало двадцатых. Рынок разросся до неимоверных размеров, стал по-настоящему глобальным, сотни и тысячи специалистов в области обеспечения качества трудятся не только в РФ, но и имеют возможность работать удаленно и за пределами страны (благодаря COVID-ограничениям и макрополитическим событиям). Огромное количество курсов и учебных программ всех мастей, начиная от крупных ИТ-гигантов и заканчивая частными тренерами, конференции собирают сотни специалистов и десятки именитых экспертов, тематические митапы внутри компаний могут запросто превышать численность конференций начала нулевых, огромное количество профильных сообществ и блогов, на полках магазинов стало проще найти книги по тестированию. О книгах, честно, я пока не осилил самостоятельно написание книги (но работаю над этим), но могу среди прочих порекомендовать третье издание “Тестирование программного обеспечения. Базовый курс” Святослава Куликова и книгу моей хорошей знакомой Ольги Назиной “Что такое тестирование. Курс молодого бойца”.
Соответственно и уровень ожиданий от специалистов в области обеспечения качества кратно вырос. Мне, как нанимающему менеджеру с “налётом” проведенных собеседований 1000+, как и многим на рынке, уже недостаточно одного желания работать, прочитанной книги или даже пройденного курса. Да и навыками тестирования карандаша сегодня уже никого не удивишь:) К начинающим специалистам закономерно за два десятилетия кратно выросли и требования. Тут тебе и теория тестирования, и техники тест-дизайна, и навыки работы со специализированными ПО (и речь не только про пресловутый devtools или что-то базовое вроде JIRA), тут тебе и ожидания по азам работы с Postman, Charles, серьезной TMS, вроде qase.io, а еще до кучи было бы неплохо иметь базовые представления об автоматизации тестирования, а местами и что-то узкоспециализированное под соответствующий профиль (для мобильного тестирования Xcode/Android studio, для бэкенда bash и консольные утилиты). А в силу высокого спроса на T-shape среди QA могут запросто появиться и отголоски спроса на базовые знания/навыки работы из смежных областей таких как разработка, DevOps, продуктовая аналитика и т.д. А, ну и классика жанра – замкнутый круг “для получения работы нужен опыт работы, получить который можно только уже имея опыт работы”:) И это на старте!
С учётом модной "продуктовой парадигмы" многие компании отказались от сервисной модели обеспечения качества, перейдя от структуры с QA-отделами к так называемым гильдиям, члены которой распределены в продуктовых командах. На фоне этой трансформации возросли ожидания от современных QA-специалистов еще и в области soft-skills, ведь теперь они и внедренцы best practice, и переговорщики/фасилитаторы встреч, еще и команду (от продакта до разработчика) обучают азам обеспечения качества ПО, да после QA продакшн, отступать некуда.
Более подробно о современных ожиданиях от QA-инженеров можно прочитать, например, тут или посмотреть/послушать тут.
Ну и вишенка на торте, как думаю стало понятно из хронологического экскурса, индустрия не стоит на месте, а это значит, что мета-ожиданием от всех ИТ-специалистов, и QA в том числе, является способность к обучению и самообучению в частности. Так как в ИТ достаточно моргнуть, чтобы в миг забронзоветь и оказаться на обочине истории с неактуальными навыками и компетенциями. Именно поэтому так важно не останавливаться в собственном развитии, как специалиста.
Думаю теперь понятно, что QA сейчас это уже не так и просто, как было в середине прошлого десятилетия, когда начался крестовый поход "войти в айти". Что за прошедшее десятилетие требования индустрии поэтапно выросли от тестирования к контролю качества, а затем и к обеспечению качества. Но это не значит, что эта дорога закрыта или является уделом избранных. В следующих постах я расскажу о возможностях и трудностях, к которым нужно быть готовым, собираясь пойти по этому пути в айти. Материал будет актуальным не только для QA, но и в целом для тех, кто задумывается о том, чтобы сменить профиль или повысить уровень компетенций в других дисциплинах ИТ.
Stay tuned!