2007-й год не вернуть: профессия QA-инженера, которая ещё недавно была престижной и высоко ценилась, сегодня стремительно теряет влияние, превращая опытного эксперта в «универсального бойца», которому можно спихнуть любую работу. Эта статья — моя личная история, в которой я разбираю, почему профессия больше не ценится и что сделать, чтобы она не попала в красную книгу как исчезнувший вид.
За моим плечами — двенадцатилетний опыт работы в QA, который я начал с должности рядового тестировщика, трансформировавшись по ходу роста компетенции до руководящего QA-лида. Под моим начинанием работала не одна команда, я выстраивал автоматизацию и релизные процессы, улучшая десятки цифровых продуктов как в России, так и в международных компаниях. В какой-то момент мой доход превысил миллион рублей в год, и казалось, что я наконец стал востребованным экспертом. Но, увы, реальность готовила мне не слишком приятный сюрприз.
Даже при наличии опыта, глубокого понимания процессов и бизнес-контекста, квалифицированные QA-инженеры уже не так востребованы, как раньше. Компании по-прежнему нанимают людей на эту должность, но не понимают, зачем она им нужна. Роль QA размыта до предела — теперь это что-то между тестировщиком, аналитиком, DevOps-инженером и ещё бог знает кем.
Последний год поиска работы стал для меня настоящим шоком. Я увидел, как QA-индустрия мутировала в нечто неопределённое: требования нереалистичны, зарплаты мизерные, а доверие к профессии почти исчезло. Это заставило меня переосмыслить свой путь и сделать трудное, но необходимое решение — уйти из QA.
Эта статья — не просто исповедь. Это наблюдение за тем, как меняется индустрия, и попытка понять, что пошло не так. Она будет полезна не только тестировщикам, но и разработчикам, менеджерам и всем, кого интересует, почему хороших QA стало трудно найти и зачем вообще их нужно искать.
QAк развивался мой путь
Я не мечтал стать QA-инженером в детстве и не планировал быть им в юности, хотя ещё в школе увлёкся ИТ всерьёз и твёрдо решил — это моё. После техникума, где нас учили разработке на C++ и сетевым технологиям, я понял, что без переезда в большой город ни о каком росте не может быть и речи. А потому отправился в Екатеринбург и поступил в крупный университет на программную инженерию.
Путь в ИТ был непростым. Это сейчас можно без труда отыскать практически любую стажировку, а тогда, в 2013 году, их можно было пересчитать по пальцам. Вакансий для джунов почти не существовало, и сделать карьеру на этом поприще было не легче, чем стать джедаем. Поэтому мне пришлось идти на завод.
Нет, я не пахал у станка по две смены, а занимался инженерной документацией, писал на Qt и участвовал в тестировании. Это был нужный опыт, но далекий от того ИТ, который я себе представлял. Позже я осознанно выбрал направление тестирования, рассчитывая перейти в разработку через год, ведь уже тогда на собеседованиях требовали лайфкодинг, SQL, сети, и задавали тестовые задания на дом. Чтобы соответствовать ожиданиям, мне нужно было развиваться. Я много готовился, прокачивал навыки, изучил всё, что только мог, и в итоге получил оффер в ИТ-компанию.
Здесь я получил реальный рост: автоматизировал тесты на Groovy, C#, Java, проводил митапы, обучал новичков. Совмещал всё это с учёбой, и могу точно сказать — профильное образование мне тогда было очень на руку. Не жизнь, а сказка, правда? Увы, нет. Проработав два года, я понял, что текущая зарплата и процессы не соответствуют моим ожиданиям. После анализа компаний и выступлений на конференциях, я составил список компаний, где хотел бы работать — и попал в крупный российский банк.
Увы, ожидания не оправдались. Снова. Я оказался в среде, где процессы были устаревшими, а команда — случайной. Зато я быстро понял, чего хочу на самом деле — работать там, где ценят мои навыки и знают, зачем я нужен. Следующим этапом стала работа над B2B-продуктом, где я показал себя как QA Lead, нанимая команду, выстраивая процессы и постоянно получая реальный опыт управления. Поэтому я неплохо подготовился к работе в международной компании, куда меня взяли по приезду в Санкт-Петербург.
Я был приятно удивлен тем, насколько выше ценят труд QA в крупных городах. Некоторое время проработав в Питере, я получил привлекательный (и выгодный) оффер в московский банк, который означал очередной рост зарплаты и множество интересных вызовов. В разгар удаленной работы я координировал релизы между десятками команд, но выгорел от менеджерской нагрузки. Чтобы отвлечься, я решил сделать шаг в сторону — принять оффер SDET в международной компании с российскими корнями. Онлайн-встреч почти не было, автоматизация работала на высоком уровне. Компания базировалась в ОАЭ, и я прожил несколько отличных лет за рубежом. Но грянула волна сокращений, и я оказался не у дел.
Поиски новой работы открыли мне глаза: рынок уже не тот. Зарплаты упали, требования выросли, а спрос на опытных QA-инженеров таял буквально на глазах. Передо мной встал вопрос, волновавший Чернышевского ещё два столетия тому назад: что делать?
Рынок QA сегодня: здесь нужны опытные инженеры, сэр!
Сегодня от QA-специалистов требуют больше, чем когда-либо (спойлер: и платят меньше, чем когда-либо), но всё реже понимают, как эффективно использовать их экспертизу. Формально роль осталась прежней, но фактически это далеко от реальности. Инженер по качеству всё чаще превращается в «ручного тестировщика с знаниями DevOps, аналитики, релиз-менеджмента и саппорта». Эти знания от него требуют не системно, а «на всякий случай» — чтобы не привлекать профильных специалистов. QA становится затычкой для процессов, которых попросту нет.
От QA теперь ждут универсальности: он должен не только писать автотесты, но и самостоятельно разворачивать окружения, настраивать CI/CD, подключать фреймворки, собирать контейнеры в Kubernetes, подключать алерты и отлаживать деплой. Просить помощи у других специалистов он не может — считается, что «должен справляться сам». Фактически QA в свободное от ручного тестирования время вынужден подменять DevOps-инженеров, разработчиков и релиз-менеджеров. Это не про инженерную культуру — это про выживание в условиях неэффективного управления и нехватки кадров.
Параллельно QA остаётся универсальным солдатом ручного тестирования: фронтенд, бэкенд, мобильные приложения — и всё вручную. На одного специалиста может приходиться объём задач от целой команды. Работу никто не планирует, поддержку не предоставляет. При этом QA как правило не участвует в архитектурных решениях, не влияет на процессы и не выбирает инструменты. Он получает задачи от всех — тимлидов, продуктовых менеджеров, аналитиков, разработчиков — и выступает исполнителем, а не инициатором изменений.
Зона ответственности QA раздута до абсурда: от него ждут и тестирования, и DevOps-задач, и документирования, и поддержки пользователей, и анализа инцидентов, и координации релизов. Всё это — без команды, без помощников, без поддержки. И хотя пашет QA за весь отдел, работа его оплачивается как у младшего специалиста. Возникает вопрос: а стоит ли оно таких мучений?
Невероятно, но факт: на фоне растущих требований компенсации почти не меняются. Зарплаты QA не растут годами и часто уступают даже начальным грейдам разработчиков. На собеседованиях прямо говорят: «QA не может зарабатывать больше, чем разработчик». Карьерный рост существует формально: чаще всего речь идёт о переходе в автоматизацию, а если повезёт — в разработку. Развитие специалиста почти не поддерживается: нет ни наставников, ни времени, ни плана. Некоторые компании действительно инвестируют в QA и ценят его вклад, но это скорее исключение, чем правило.
Собеседования давно оторваны от реальности. QA задают вопросы по архитектурным паттернам, DevOps-инструментам, сетевым протоколам, проектированию автотестов на уровне system design. SQL, оконные функции, RCA, Scrum и Agile — спрашивается всё, но почти всегда без учёта контекста работы. При этом игнорируется уровень кандидата: опытным QA-лидов задают вопросы, достойные джунов: о видах тестирования и технике белого ящика. Попытки привести реальные примеры или объяснить, что подход зависит от проекта, часто воспринимаются как неправильный ответ.
Такой подход игнорирует главное — реальный опыт. Улучшение релизного цикла, сокращение ручного труда, внедрение процессов — всё это никого не интересует. В результате рынок сам провоцирует раздувание резюме: QA становится инженером широкого профиля, но на собеседовании должен отвечать как теоретик по всем дисциплинам, а в работе выполнять рутинные ручные задачи.
Сами процессы в компаниях зачастую часто отстают на годы: канареечные релизы не используются, а дашбордов и системы алертов нет от слова «совсем». Доступ в прод открыт. CI/CD небезопасен и непрозрачен. В таких условиях от QA требуют уровня DevOps-инженера, архитектора, релиз-менеджера и саппорта — но не дают полномочий, карьерного роста и справедливой компенсации.
Так роль QA теряет свою суть. Это уже инженер не по качеству, а по всему — временная заплатка, которой затыкают любые дыры. Обязанности постепенно уходят к DevOps, SRE, разработке и менеджменту, а сам QA остаётся — без инструментов, без влияния и без ответа на главный вопрос: зачем он вообще нужен?
Так ли всё плохо и почему да?
Как всегда, рыба гниёт с головы: всё чаще в ИТ-компаниях ключевые решения принимают не технические менеджеры, а «эффективные управленцы», пришедшие из смежных сфер. И если раньше основу ИТ-индустрии составляли люди, увлечённые технологиями, архитектурами и качеством продукта, то с приходом больших денег началась миграция менеджеров из маркетинга, консалтинга и других направлений, которые быстро заняли руководящие позиции, не вникая в техническую суть процессов.
Эти управленцы не понимают, как устроена инженерная работа, не видят ценности в ролях разработчика, аналитика или QA, и при этом стремятся «оптимизировать» и «настроить управление». Их подход — управлять показателями, а не улучшать продукт. Вместо реального вклада они подменяют работу отчётностью, заменяют гибкие процессы формальными рамками и игнорируют специфику разработки. Они не интересуются техническим долгом, не понимают различия между стабильностью и скоростью, и верят, что любую проблему можно решить презентацией.
Следом за ними приходят QA-менеджеры: Head, Lead, Director — зачастую с теми же установками. Они устраивают видимость бурной активности: бесконечно внедряют метрики, которые ничего не измеряют, навязывают процессы, работающие только в их предыдущем опыте, проводят десятки встреч, на которых не принимается ни одного технического решения. В таких условиях QA превращается в статиста: вокруг него кипит имитация движения, но всё остаётся на месте. И всё это — в компаниях, где до сих пор нет канареечных релизов, нет надёжного CI/CD, а каждое обновление требует недельного фриза.
Факт: на позицию Senior QA компания параллельно рассматривает кандидатов с 10-15 годами и с 1-3 года опыта. И хотя руководство будет гореть желанием взять опытного кандидата, должность наверняка отдадут тому кто запросит меньшую зарплату: такой подход давно стал общепринятой нормой.
Хуже того: многие QA-специалисты приходят в профессию после 3—6 месяцев онлайн-курсов, не имея ни технического образования, ни понимания основ инженерной культуры. Через полгода они уже сами преподают те же курсы, клонируя ошибки своих сенсеев и закрепляя за падаванами поверхностные знания. Получается замкнутый цикл: некомпетентные специалисты порождают себе подобных, не делая различий между настоящим опытом и теоретическими выкладками на краткосрочном переобучении.
Представьте: вы вкладываете восемь лет в образование, двенадцать лет в практику, неоднократно решаете реальные инженерные задачи, а вас ставят в один ряд с бывшими аниматорами, официантами и инструкторами по лыжам, которые за пару месяцев «переквалифицировались» в QA. И когда вы называете ожидаемую зарплату, вам говорят: «У QA таких зарплат не бывает». Да, ещё остались компании, которые готовы платить адекватные деньги и требуют наличие профильного образования и доказанного опыта. В них уважение к профессии ещё не разрушено — но с каждым днём таких мест становится всё меньше.
Описание вакансии в компании, которые маскируют за названием QA Engineer роль тестировщика
Ещё на этапе чтения вакансии можно понять, что под видом QA-инженера на самом деле ищут универсального ручного тестировщика, который будет выполнять задачи за троих. Если в названии фигурируют формулировки вроде Manual QA или Automation QA, а не просто QA Engineer, это уже сигнал: скорее всего, в компании не различают роли и не выстраивают системный подход к качеству. Часто в требованиях указаны инструменты вроде Postman, Charles, Fiddler — то есть от человека ожидают, что он будет вручную проверять API и трафик. Могут также требовать опыт нагрузочного или безопасности тестирования — при этом не предлагая поддержки со стороны специализированных команд. Всё это отдельные направления, и если они не вынесены в отдельные роли, значит, их возложат на одного человека.
Иногда в описании появляются противоречивые требования: «управлять командой из пяти человек» и при этом «писать автотесты на Python, знать Kafka, CI/CD, очереди и внутренние фреймворки». Очевидно, что на управление и стратегию времени не останется — придётся затыкать дыры на всех уровнях, от саппорта до написания кода. Фразы «отвечать за регрессы» или «проводить функциональное и автоматизированное тестирование, включая анализ требований» на практике означают ручное тестирование задач и составление чек-листов — то есть задачи тестировщика, а не инженера по качеству.
Все эти признаки — не стопроцентный маркер: в каких-то компаниях действительно может быть иначе. Но когда такие формулировки сочетаются с отсутствием упоминания архитектуры качества, стратегии, процесса принятия решений или зоны влияния, велика вероятность, что на самом деле ищут не инженера, а исполнителя. И рассчитывать в подобной среде на влияние и развитие не приходится.
К чему всё это приводит?
Инженеры по качеству вымирают. Вместо эксперта, способного влиять на архитектуру продукта и процессы, компании ищут подмастерьев, которым не нужны полномочия, вектор развития и не полагается достойная оплата. Такой подход приводит к выгоранию, оттоку профессионалов, росту текучки и цинизму внутри команд.
Страдают не только инженеры по качеству, но и само качество. Только бизнес этого не замечает: продукт работает? Значит, всё в порядке! Ошибки на проде? Не беда, если пользователи продолжают им пользоваться. Проблемы решаются легко: если кто-то потерял деньги — дадут промокод. Если компания что-то потеряла — спишут убытки или пойдут в суд. До тех пор, пока баги не бьют напрямую по выручке, они считаются допустимыми. Качество больше не в приоритете и как системная категория оно больше не существует.
В таких условиях исчезает возможность дальнейшего роста. Новички учатся у таких же новичков, потому что опытные специалисты уходят в смежные роли или вообще покидают индустрию. На рынке остаются только те QA, которым уже неинтересно развиваться, и это не может не сказаться на качестве их работы.
Роль QA обрастает иллюзиями. Вместо изменений процессов, которые могли бы обеспечить улучшение процессов, специалисты без полномочий и влияния лишь адаптируют их в пределах личного комфорта. Тестирование, оформление задач в трекер, шаблон баг-репорта — вот и всё, что они могут «улучшить».
Когда инженер не может влиять на архитектуру и процессы, он переключается на то, что ему доступно. Начинает считать баги, фиксировать количество пройденных тестов, строить графики покрытия автотестами. Эти метрики по сути ничего не значат — они не отражают ни надёжность продукта, ни ценность работы. Но такие цифры любят менеджеры: они позволяют показать «работу» и демонстрировать «контроль». Руководство тоже согласно: раз есть отчёты, значит всё под контролем. Иллюзия эффективности становится удобным фоном для стагнации.
Хотя вру: кое-какие улучшения всё же внедряются. «Если нельзя оптимизировать продукт, оптимизируй найм!» - с таким подходом управленцы вводят новые этапы собеседований, грейды, шаблоны, оценивающие чек-листы. Меняют вопросы, добавляют техзадания, создавая иллюзию развития, за которой скрывается печальная реальность: в продукте по-прежнему нет unit-тестов, отсутствует культура CI/CD, а инженерный подход к качеству так и не прижился.
Так система продолжает вращаться вхолостую. Без стратегии, без роста, без инженерной сути. Старое правило «Работает? Не трогай!» снова побеждает.
QA Head/Lead/Director без власти
Во многих компаниях роль QA-лидера существует формально, но лишена реального содержания. Он совершенно не участвует в принятии технических решений, и вместо него всё определяют разработчики, продукт-менеджеры или архитекторы. QA-лидер не имеет доступа к бюджету, чтобы инвестировать в обучение команды, улучшение инфраструктуры или внедрение новых инструментов. Он не включён в стратегическое планирование архитектуры или релизов, не может инициировать изменения в CI/CD и не имеет полномочий даже приостановить релиз, если найдены критические проблемы.
Фокус такого QA-лидера смещается в сторону отчётности: вместо создания качества он создаёт метрики, графики, трекинг задач, решает вопросы найма и внутренних процессов. Встречи проходят исключительно внутри QA-команды, без участия тимлидов, архитекторов или руководства. Влияние ограничивается ручным тестированием и регрессом. Он не может требовать покрытие юнит-тестами или интеграционными сценариями, его предложения по улучшению процессов либо «принимаются к сведению», либо вовсе игнорируются и саботируются.
Если вы узнаёте в этом описание свою компанию, это повод задуматься. Когда QA-лидер ограничен в правах и возможностях, он не может отвечать за качество. А если при этом в компании никто другой эту зону ответственности на себя не берёт, то качество становится ничьей проблемой. И это уже системная ошибка.
Почему я ушел в разработку?
После двенадцати лет в QA и года поисков новой работы я неожиданно обнаружил, что пройти собеседование на позицию разработчика значительно проще, чем на QA. Это было не просто удивление — это стало поворотной точкой, которая окончательно подтвердила, что индустрия тестирования больше не предлагает прозрачного и честного пути развития.
Собеседования в разработку оказались легче и честнее. Мне задавали конкретные и прикладные вопросы без абстрактных рассуждений из серии «а вдруг вы будете настраивать всё подряд». Интервью касались того, что действительно нужно в работе: структур данных, алгоритмов, знания языка программирования, понимания баз данных и сетевых принципов. Лайвкодинг — по классическим задачам с LeetCode, а не с фантазиями о построении идеального фреймворка или угадыванием чужой архитектуры. Часто даже давали выбор языка, а не отказывали с формулировкой «у нас всё на Python, а ты пишешь на Java — значит, нам не подходишь».
То же казалось и самой работы. Вместо размытых задач а-ля «протестируй меня полностью» выдавалась конкретная задача с конкретным результатом. При этом без перекоса ответственности: я отвечал за конкретный кусок функциональности, а не за весь релиз и чужие решения. А главное, при более разумных требованиях зарплата тоже оказалась выше: от меня не ждали, что я буду и DevOps-инженером, и аналитиком, и саппортом, но при этом платили разумные деньги.
Карьерный рост? Да, и вполне понятный и измеримый. Трек чёткий и понятный: Junior → Middle → Senior → Staff → Architect. Есть менторы, код-ревью, практика наставничества. Есть задачи «на вырост», есть отслеживание прогресса, развитие. Компании заинтересованы в росте специалистов и готовы в него инвестировать — причём не на словах, а на деле.
Но главное в том, что разработка — это профессия с будущим. Она востребована во всём мире. В ней есть множество направлений: backend, frontend, архитектура, DevOps, машинное обучение, безопасность. Всегда существует возможность работать в международных командах даже без переезда. Это не просто смена роли — это выбор среды, в которой можно расти, влиять и чувствовать уважение к своей работе. В отличие от QA, это сфера, где твой вклад по-прежнему ценится.
Как спасти сферу QA?
Всё останется по-прежнему, если не признать: инженер по качеству и тестировщик — это не одно и то же. Это две разные роли с иными целями, зонами ответственности и подходами к работе.
Тестировщик, будь то ручной или автоматизатор, выполняет конкретные задачи: проверяет фичи, баги, реализует сценарии, покрывает продукт автотестами. Это важная и нужная инженерная функция, но она работает на уровне конкретных задач, а не процессов.
В свою очередь, QA-инженер — это системный специалист, который проектирует подход к качеству на уровне всей компании. Он влияет на архитектуру процессов, определяет стратегию тестирования и обеспечивает устойчивость разработки.
Когда эти роли смешивают, страдают обе стороны: тестировщик не может углубиться в свою экспертизу, QA не получает времени и ресурсов, чтобы заниматься системной работой.
Ключевая ошибка многих компаний — пытаться встроить QA в каждую команду в рамках спринта. На самом деле инженер по качеству должен быть ближе не к командному циклу, а к архитектуре и стратегическому уровню. Его работа должна происходить на пересечении технического лидерства: с архитекторами, CTO, DevOps-отделом и project-менеджерами. Именно на этом уровне рождаются системные решения, которые влияют на стабильность, надёжность и скорость релизов. Если у QA нет к нему доступа, он не сможет ни собрать нужных людей, ни внедрить изменения. Иногда лучше вовсе отказаться от роли QA-руководителя, чем держать формальную фигуру без влияния — тогда ответственность за культуру качества должен взять на себя СТО.
Запомните: QA — не просто исполнитель. Он предлагает архитектурные решения и инициирует кросс-функциональные изменения (например, внедрение единого инструмента интеграции между микросервисами или развитие мониторинга). Он не обязан писать автотесты сам, а лишь должен понимать, какие автотесты нужны, где узкие места релизов, и что мешает стабильности продукта. Его зона ответственности — не ручные кейсы, а управляемость всей системы через процессы, инструменты и коммуникации.
Культура качества не может держаться на одном QA. Она должна быть встроена в саму систему разработки — так же, как это устроено, например, в авиации. Безопасность рейса обеспечивает не один человек, а десятки специалистов. Пилоты следуют строгим регламентам, диспетчеры координируют пространство, бортпроводники отвечают за обслуживание, механики следят за техникой. Никто не требует от стюардессы заправить самолёт, а от диспетчера — налить кофе во время полета. В ИТ должно быть так же: каждый участник процесса: разработчик, DevOps, аналитик, менеджер — все они в равной, но в разной степени вовлечены в обеспечение качества без перекладывания ответственности на одного человека.
Текущая ситуация отчасти напоминает кризис, который уже происходил в ИТ. В нулевые системных администраторов просили и настраивать сервера, и заправлять принтеры, и много чего другого. Потом появились DevOps и SRE — и системная инженерия начала развиваться. Сейчас то же самое происходит с QA: название «инженер по качеству» уже давно не отражает суть профессии, которую воспринимают как исполнителя «муж на час» - универсальную и без полномочий. Возможно, резонным шагом станет переосмысление его роли в сторону SRE, quality enablement-инженера или даже новой дисциплины, которую ещё только предстоит сформировать.
Если компании действительно хотят, чтобы QA приносил пользу, нужен системный подход. Нельзя смешивать роли тестировщика и инженера по качеству: первый отвечает за реализацию, второй — за процессы. QA-инженеру нужно дать полномочия влиять на архитектурные, продуктовые и организационные решения, иначе он остаётся просто декорацией. При этом важно не только дать ответственность, но и создать условия для роста: менторство, обучение, задачи с перспективой. Инженер без развития — это специалист, который либо уйдёт, либо потеряет мотивацию. А это не нужно ни ему, ни компании.
Наконец, стоит отказаться от показухи. Метрики ради отчётности, фреймворки ради отчёта, найм ради плана — всё это ведёт в тупик. Ставка должна быть на результат: на стабильные релизы, предсказуемые процессы и на улучшения, которые действительно работают. Качество — это не роль и не человек. Это — системная ответственность. И начинаться она должна с тех, кто принимает решения: CTO, Head of Engineering, архитекторов.
Вывод
QA-индустрия сегодня стоит на распутье. Вряд ли она исчезнет — как не исчезли заправляющие принтер сисадмины — но она наверняка не останется прежней. Вопрос лишь в том, во что именно она превратится. К сожалению, специалистов, которые действительно понимают, что такое качество и как выстраивать его системно, становится всё меньше. И всё меньше компаний готовы инвестировать в культуру качества, предпочитая просто перекладывать задачи, не изменяя саму основу.
Я не жалею, что ушёл из этой сферы. Перейдя в разработку, я снова почувствовал рост. Передо мной стоят ясные цели, прозрачные метрики, и я вижу, как мой вклад влияет на продукт. Здесь я не просто проверяю результат решений — я участвую в их создании. Это даёт ощущение причастности, смысла и уважения к профессии.
Но дело не только в QA. Всё, что случилось с этой профессией, может произойти с любой другой ролью в ИТ, если мы продолжим делать одни и те же ошибки. Если снижать планку входа и требовать лишь механического выполнения инструкций. Если не развивать специалистов, а заменять их новичками с онлайн-курсов. И если не платить за экспертизу, но при этом ожидать всё и сразу, не давая ни инструментов, ни полномочий. Так можно любого превратить в кого угодно: разработчика в тестировщика, аналитика в саппорт, а инженера — в универсального исполнителя, который всё делает, но ни на что не влияет. Универсального, дешёвого — и очень быстро выгорающего.
Наверное, именно поэтому сегодня многие всерьёз задумываются о том, чтобы заменить таких специалистов на ИИ. Потому что если человек не может принимать решения и влиять на результат, то зачем он, в сущности, нужен?
Когда старая модель умирает, всегда появляется новая. Хочется верить, что на этот раз её будут строить те, кто помнит, как было, и знает, как может быть по-настоящему хорошо. А иначе нас ждёт будущее, в котором на ИИ заменят не только QA-инженеров, но и всех остальных, кто не хочет не может выполнять чужую работу, едва получая оплату за свою собственную.
