вакансий: существует много смежных областей, требующих самого разного баланса навыков и ведущих к другим карьерным возможностям. Ведь самое важное — найти свое любимое дело, даже если на это потребуется много попыток.

На мой взгляд, Support направление проще для входа в ИТ, чем QA. Да и ваш карьерный путь может привести к тому, что вы станете Support, который пишет код. Но зарплаты в поддержке обычно меньше, чем в QA. Бизнес-аналитика по техническим навыкам проще на старте, но как минимум по навыкам общения заметно сложнее, чем QA.

Глобально вам нужно ориентироваться на свои способности, желания и возможности карьерного роста в выбранном направлении.

Быть QA инженером это скучно

Все зависит от вас и вашего места работы. В основном эта деятельность связана с рутиной у компьютера. Однако в мире принято все автоматизировать и работа QA инженера не исключение. Этому процессу как раз подвержены самые повторяющиеся рутинные задачи. Вы и сами будете их автоматизировать в том или ином ключе.

Если вам кажется, что в ходе всей своей работы вы будете только брать подготовленные аналитиками требования, писать по ним тестовые сценарии и проводить тестирование, то вы ошибаетесь. Вам предстоит тестировать требования и думать над различными ситуациями в приложении, ставить себя на место бизнеса, пользователя и злоумышленника. К тому же не всегда в компаниях вообще есть какая-либо документация и аналитики, а значит, вы будете с нуля выполнять большие объёмы работы, каждый раз сталкиваясь с чем — то новым.

Однако восприятие того, чем вы занимаетесь, это только ваше личное и в ваших силах его менять. Я не раз встречал людей, которые не просто более пяти лет работали в одной компании, но и занимали одну и ту же должность и каждый день, по большому счету, делали одно и то же. Это не у всех вызывает скуку. Есть немало людей, которым доставляет удовольствие делать свою работу и быть уверенными в себе и своих навыках.

Автоматизация скоро заменит тестировщиков

Нет, не заменит. Индустрия QA и нуждаемость в её представителях никуда не делась. Потребности в опытных ИТ специалистах во всем мире постоянно растут, новые кадры не успевают рождаться. ИТ индустрия глобально занимается автоматизациями всего, что только можно, в том числе и работы самих ИТ специалистов.

Automation QA очень бурно развивается и кажется, что все внедряют ее на своих проектах. Но этой работой занимаются в основном бывшие Manual QA, которые расширили набор навыков и приспособились к рынку. Автоматизация сокращает расходы компаний на тестирование, что позволяет им расти быстрее и открывать новые проекты, на которых снова нужны как Manual,так и Automation QA инженеры.

Нейросети тоже внесли свой вклад, и мы уже можем его оценить. О замене каких — либо специалистов в тестировании пока нет и речи. Однако нейросети помогают QA инженерам быстрее выполнять их работу.

QA инженеры будут не нужны, потому что их заменит ИИ

В этом вопросе очень сложно что — то прогнозировать. Мое мнение — не заменит, а запустит новый круг преобразований.

Много лет пророчили, что автоматизация заменит ручных тестировщиков. И такое мнение меня всегда поражало, потому что статистика международных HR агентств четко говорила, что в мире уже есть нехватка опытных ИТ специалистов и в будущем этот дефицит будет только увеличиваться. И сейчас мы видим, что действительно, низкоквалифицированные кадры рискуют быть уволенными раньше, чем они того сами хотели бы. Такое уже не раз произошло в некоторых ИТ гигантах США. Однако квалифицированные кадры все так же ценятся, количество проектов и конкуренция между ними растет. Это значит, что опытный специалист, регулярно развивающий свои навыки, всегда остается ценным. И здесь ИИ уже становится ему таким же незаменимым союзником, каким ранее стала автоматизация.

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

QA инженеры — это разработчики — неудачники. QA инженеры это “entry level” работа

Это все еще распространенные предрассудки. И в США хватает проектов, на которых вас будут считать entry level просто потому, что вы работаете QA инженером, и не важно, какой у вас опыт и что вы умеете. Я сам сталкивался и продолжаю сталкиваться с этим. На русскоязычном рынке ситуация получше и зарплата опытных QA инженеров бывает выше, чем у представителей некоторых областей разработки.

Постепенно рынок заставляет всех опытных QA инженеров знать основы кода, проектирования систем, осваивать средние навыки SQL и еще много чего. Опытный Senior QA Automation Engineer или Software Developer in Test на практике может иметь более глубокие познания кода/SQL/DevOps, чем Middle Developer и способен полностью выполнять работу разработчика.

Не важно, что думают другие, важно, что QA это действительно инженеры, и их зарплата постепенно растет, показывая то, насколько они важны для индустрии.

QA инженер во всем виноват

Это отчасти правда. На любом рынке вы найдете проекты, в которых адекватно понимают, что качество продукта — это коллективная ответственность. Но на каких — то проектах вы не встретите понимания коллег и руководства.

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

В любом случае выбор компании/проекта/команды за вами. Советую задавать наводящие вопросы еще на первых этапах собеседования, чтобы не ошибиться с выбором.

QA инженеры все ломают

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