Опираясь на собственный опыт (годы работы в 2 крупнейших российских финтех компаниях, отечественной коммерческой разработки, опыт международной IT компании) я все больше и больше убеждаюсь, что профессия QA обесценена. В данной статье я не хочу описывать разницу между QA, QC и тестированием (на Хабре довольно много статей, где можно подробно найти всю информацию). Я лишь попытаюсь сформулировать свои мысли по поводу того, во что превратилась профессия QA и как работодатели сами обесценивают эту профессию. А выводы каждый сделает сам.
По долгу своей роли я вынужден проводить большое количество собеседовании на роль специалистов контроля качества. Этих собеседований было больше сотни. Кого я только не встречал? Ко мне приходили бывшие медработники и библиотекари, люди, получившие высшее образование и не учившиеся ни в одном вузе, люди с базовым пониманием процесса разработки и без него. Все эти люди утверждали что они готовые специалисты по управлению контролем, качества. Вопрос: может ли библиотекарь стать хорошим специалистом контроля качества? Точного ответа нет, возможно, со временем, получив большой опыт работы и очень многому поучившись, человек, даже не имеющий профильного образования, сможет стать специалистом QA, но для этого ему нужно будет пройти очень и очень большой путь и многому поучиться. Может ли данный человек заниматься тестированием? Наверное да, при наличии должной квалификации и наработанных навыков. Но дело то в том, что все эти люди откликались на вакансию «Специалист по QA», тем самым показывая, что они даже и не понимают, в чем заключается основа данной профессии.
Холиварная тема, которая время от времени поднимается в разных топиках: нужен ли в настоящий момент специалист по тестированию на проекте или нет или это может делать разработчик или аналитик? Все индивидуально и сильно зависит от проекта, но мой ответ такой: тестировщиков можно убрать с 50% проектов, где я работал, а вот настоящего QA специалиста заменить не сможет ни разработчик, ни аналитик. Таких людей не может быть много, их задачи тесно пересекаются с разработчиками, аналитиками, DevOps инженерами. И польза от их работы будет видна не мгновенно (это не протестированная фича), а чуть позже, когда приложение наберет объем и у него появится определенная история. Именно поэтому, такой специалист и не нужен во всех проектах. Где‑то вполне достаточно обычного QC. Но уж если мы решили, что в команде будет QA — давайте точно понимать, что это за роль, в чем его основные обязанности и как он будет помогать проекту становиться лучшею.
Понимая данную проблему, я задумался, кто же виноват в сложившейся ситуации, почему мы подменяем понятия, почему изначально нанимаем людей на роль, им не свойственную?
Вначале я был убежден, что виноваты претенденты, которые используют тестирование, как дырку в заборе, окружающем IT. Все знали это несколько лет назад, что тестирование — самый простой путь зайти в IT. К счастью, ситуация существенно изменилась и сейчас так думает только тот, кто не понимает реалий текущей ситуации.
Но со временем моя точка зрения изменилась!
На мой взгляд именно работодатели создали такую ситуацию, когда понятия оказались подменены и профессия QA начала обесцениваться. Одними из виновников данной ситуации стали люди, которые уже работали в компаниях в роли тестировщиков и были привлечены к найму новых сотрудников. При переходе к гибким методологиям разработки, в командах стали появляться разные роли: Developer, DevOps, QA. И всех, кто занимался тестированием, просто стали называть QA. При этом люди, зачастую, сами не понимали разницы QA\QC\Testing. Это были обычные тестировщики и никакого отношения к QA не имели. И эти люди стали участвовать в подборе новых кадров. Ну и нанимали себе подобных. Это не их вина, а их беда. Трудно требовать от человека, который не является экспертом в какой‑то области, нанять настоящего специалиста. Поэтому в команды стали приходить специалисты по тестированию, но с должностью QA.
Небольшое доказательство моих слов. Давайте посмотрим список вакансий на любом ресурсе (можно прямо на Хабре). Найдите вакансию QA специалиста и почитайте описание роли и основных задач. Вы убедитесь, что в большинстве (существенном большинстве) описаний вы увидите задачи обычного тестировщика, в крайнем случае, QC специалиста. т. е. работодатель, уже на этапе требований к роли вносит путаницу. А ведь это скажется для этого же работодателя чуть позже, когда специалист придет в команду, пройдет испытательный срок и будет выполнять обязанности тестировщика. Только проекту (не каждому, конечно) очень скоро потребуются все те мероприятия, которые относятся именно к QA. Но кто их будет внедрять? У данного сотрудника нет понимания, что это вообще и как это организовать. А роль уже занята. И хорошо, если он вдумчивый человек и начинает разбираться, как это сделать. В большинстве случаев этого не происходит, и мы имеет чистого «тестировщика» с ролью QA и отсутствием каких‑либо процессов по контролю качества.
Бывает, что проекту просто излишне роль QA. Возможно, это Startup, или команда, разрабатывающая некий сервис в ограниченном временном интервале с четкой и не меняющейся целью и ограниченным бюджетом. Не будет ничего плохого, если мы внедрим QA процессы и тут. Но и простого тестирования, возможно, будет достаточно. Решает команда и это нормально!
Но крупные проекты, рассчитанные на годы, с бюджетом и историей развития не могут позволить использовать только тестирование. И здесь роль QA очень важна.
Можно возразить: какая разница, как называть специалиста? Ну есть роль QA пусть так и называется. С одной стороны да, не важно, как вы называете роль у себя в команде. Но вот обязанности, выполняемые этим человеком — это ключевое! Чтобы стать хорошим специалистом QAнужно время, опыт и постоянное развитие.
Пройти путь от Тестировщика к QA специалисту можно, приложив усилия и потратив время. Но как это сделать, если ты толком не понимаешь, куда идти и что развивать. Ведь вокруг тебя тестировщики. А самое главное, работодатель не понимает, что это абсолютно разные роли. Даже цель у этих ролей разная (кому интересно — найдите и почитайте).
Вот и получается, что мы ищем QA специалистов, а нанимаем тестировщиков.
Ну и еще один фактор, который повлиял на текущую ситуацию с QA — это общий уровень специалистов, работающих в управлении качеством и всем, что с этим связано. Не хочу обижать всех. Есть действительно очень талантливые инженеры, которые действительно являются QAспециалистами. И работать с такими доставляет огромное удовольствие. Но до сих пор на рынке труда огромное количество претендентов с полным отсутствием навыков и понимания, что такое даже просто «Тестирование» (спасибо огромному количеству различных курсов). И это просто лавина, в которой HR службы пытаются отловить специалистов. (как работают HR службы, их уровень и как организован процесс найма — это отдельная тема, при том — печальная). И если процесс найма не налажен или выстроен не до конца правильно, то в команду приходят далеко непрофессионалы QA и даже не QC.
Как можно это исправить? Точного ответа у меня нет. Надежда на эволюцию процесса найма и общих процессов в командах.
Меня радуют возникающие, время от времени, дискуссии о необходимости тестировщиков в командах. Разумеется, все зависит от конкретного проекта, его зрелости, уровня развития, бюджета и т. п. Вероятно, мы можем столкнуться с такой ситуацией, что от тестировщиков будут кое‑где отказываться либо сокращать их количество. Ведь эффективные команды нуждаются в повышении (или контроле текущего) уровня качества, а не в отчетах о количестве багов, тест‑кейсов и статусе автотестов за ночь. Я надеюсь, что придет понимание, что QA — это не только про тестирование фич и багах на проде. Это больше про конечный результат, надёжность продуктов, выпускаемых данной компанией и в конечном счете — репутацию компании! И для тех проектов, кто это понимает уже сейчас — это будет просто процессом, понятным и необходимым. А для других, кто использует QAпросто как аббревиатуру, тождественную «тестированию» — это станет открытием и им придется менять свое отношение к данной профессии. Но они окажутся существенно позади первых.
Так что, как ни крути, но прежде всего компания должна понимать, что это за роль, кого мы нанимаем, какие задачи ставим и вообще, зачем она нужна в данном проекте и как применять данных специалистов.
