Заменит ли AI ручных тестировщиков

Еще несколько лет назад работа Manual QA выглядела довольно привычно: изучить требования, составить чек-лист, пройти сценарии руками, завести найденные баги и проверить исправления.

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

ChatGPT и другие LLM умеют составлять тест-кейсы, искать потенциальные граничные случаи, генерировать тестовые данные, помогать с SQL-запросами и API, улучшать описание багов и даже писать код автотестов.

Поэтому у начинающих тестировщиков возникает вполне логичный вопрос:

а нужен ли вообще Manual QA, если значительную часть его работы теперь может делать AI?

Короткий ответ — да, нужен. Но сама профессия меняется.

Современный ручной тестировщик постепенно превращается из человека, который просто выполняет готовые проверки, в специалиста, который понимает продукт, видит риски и умеет использовать AI как дополнительный инструмент.

По данным State of Testing 2026, AI-инструменты уже используются в тестировании очень широко. При этом отраслевые исследования продолжают подчеркивать необходимость человеческой проверки результатов, которые генерирует AI.

Разберемся, какие задачи AI действительно может забрать у ручного тестировщика, а где человек пока остается незаменимым.

Что AI уже умеет делать вместо тестировщика

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

Многие рутинные операции Manual QA действительно хорошо подходят для автоматизации с помощью AI.

1. Составлять тест-кейсы

Допустим, есть требование:

Пользователь может восстановить пароль через email.

Раньше тестировщик самостоятельно составлял список проверок:

• зарегистрированный email;
• незарегистрированный email;
• пустое поле;
• неправильный формат email;
• просроченная ссылка;
• повторное использование ссылки;
• отправка нескольких запросов подряд;
• проверка нового пароля;
• проверка старого пароля после изменения.

Сегодня достаточно передать описание функциональности AI и попросить:

«Составь позитивные, негативные и граничные тест-кейсы для формы восстановления пароля».

Через несколько секунд можно получить первоначальный список проверок.

Это не означает, что список будет идеальным. Но начинать работу с пустого документа тестировщику уже необязательно.

2. Генерировать тестовые данные

AI удобно использовать для подготовки данных:

• имен;
• email;
• адресов;
• различных форматов дат;
• длинных строк;
• нестандартных символов;
• JSON;
• XML;
• SQL-запросов;
• комбинаций входных параметров.

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

3. Помогать писать баг-репорты

Представим обычную ситуацию.

Тестировщик быстро записал:

При изменении пароля что-то не работает, если открыть вторую вкладку.

Для Jira такое описание практически бесполезно.

AI можно передать черновик, фактический результат и последовательность действий, после чего попросить привести баг-репорт к нормальной структуре:

• Title;
• Preconditions;
• Steps to reproduce;
• Actual result;
• Expected result;
• Environment.

В результате тестировщик тратит меньше времени на оформление и больше — непосредственно на исследование проблемы.

4. Помогать с API и SQL

Manual QA все чаще требуется работать не только с интерфейсом.

Нужно открыть DevTools, посмотреть запрос, отправить его через Postman, проверить JSON, выполнить SQL-запрос и понять, что произошло с данными.

AI заметно снижает порог входа в такие задачи.

Например, тестировщик может показать структуру таблиц и попросить помочь составить JOIN или дать пример запроса для поиска дубликатов.

Или передать API response и спросить, какие проверки имеет смысл выполнить.

Но здесь появляется важное правило:

AI может предложить решение, но тестировщик должен понимать, что именно он запускает и почему.

Слепое копирование SQL, JavaScript или API-запросов из ChatGPT — плохая стратегия.

5. Помогать с автоматизацией

Еще несколько лет назад переход от Manual QA к Automation QA требовал довольно серьезного погружения в программирование уже на самом старте.

AI частично упрощает этот путь.

Модель может:

• объяснить чужой автотест;
• написать простой пример;
• подсказать локатор;
• найти ошибку в коде;
• помочь переписать тест;
• объяснить Playwright, Selenium или Cypress;
• показать, как отправить API-запрос.

Это не отменяет необходимость изучать программирование.

Но начать автоматизировать небольшие сценарии стало значительно проще.

Значит ли это, что Manual QA исчезнет?

Скорее меняется само понимание слова manual.

Представим двух тестировщиков.

Первый получает задачу, проходит написанные кем-то тест-кейсы и ставит Passed или Failed.

Второй изучает задачу, задает вопросы аналитику, находит неоднозначности в требованиях, определяет зоны риска, проверяет интеграции, придумывает нестандартные сценарии и исследует поведение пользователя.

Оба формально могут называться Manual QA.

Но автоматизировать работу первого значительно проще.

Именно поэтому основной риск AI создает не для профессии тестировщика как таковой, а для чисто механического тестирования.

Современные материалы по QA описывают похожий сдвиг: AI особенно эффективен там, где ожидаемый результат можно четко определить, тогда как exploratory testing, оценка пользовательского опыта, работа с неоднозначными требованиями и принятие решений на основе рисков по-прежнему требуют человеческого контекста.

Что AI пока делает плохо

У AI есть одна фундаментальная проблема.

Он очень убедительно отвечает даже тогда, когда ошибается.

В тестировании это особенно опасно.

Понимание реального пользователя

Тестировщик может посмотреть на интерфейс и сказать:

«Технически все работает, но нормальный пользователь здесь вообще не поймет, что от него хотят».

Автоматическая проверка может увидеть:

• кнопка отображается;
• кнопка активна;
• API возвращает 200;
• данные сохраняются.

Но продукт при этом может оставаться неудобным.

Работа с неоднозначными требованиями

Представим требование:

Система должна быстро показывать результаты поиска.

Что такое «быстро»?

100 миллисекунд?

1 секунда?

3 секунды?

Нужно ли одинаковое время для 10 и 10 миллионов записей?

Опытный QA заметит проблему еще до начала тестирования и пойдет уточнять требования.

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

Exploratory testing

В исследовательском тестировании специалист постоянно меняет направление проверки в зависимости от того, что обнаружил несколько минут назад.

Например:

1. обнаружил странное поведение фильтра;
2. проверил соседний фильтр;
3. заметил зависимость от сортировки;
4. открыл DevTools;
5. увидел дополнительный API-запрос;
6. изменил параметр вручную;
7. нашел уже серьезную ошибку на backend.

Такое тестирование сложно свести к заранее созданному набору сценариев.

Оценка бизнес-риска

Не все баги одинаково важны.

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

Но их значение для бизнеса совершенно разное.

Тестировщик должен понимать контекст продукта и уметь определять, где ошибка действительно критична.

Парадокс: AI создает дополнительную работу для QA

Есть еще одна интересная сторона происходящего.

AI не только помогает тестировать.

Сам AI теперь приходится тестировать.

Все больше продуктов добавляют:

• AI-ассистентов;
• чат-ботов;
• генерацию текста;
• поиск на основе LLM;
• автоматическую классификацию;
• AI-рекомендации;
• суммаризацию документов;
• AI-агентов.

И у таких систем появляется новый класс проблем.

Например:

• галлюцинации;
• фактически неправильные ответы;
• разные ответы на одинаковые запросы;
• некорректная обработка контекста;
• prompt injection;
• утечка системных инструкций;
• небезопасные ответы;
• ошибки при работе с инструментами;
• неожиданное поведение на другом языке.

В исследовании Applause 2026 среди разработчиков и QA отдельно отмечались проблемы с галлюцинациями, неверным пониманием запросов и ненадежными результатами AI-приложений.

Получается довольно забавная ситуация:

AI забирает часть старых задач тестировщика и одновременно создает совершенно новые задачи для тестирования.

Каким должен быть Manual QA в 2026 году

Необязательно срочно становиться Senior Automation Engineer.

Но ограничиваться умением нажимать кнопки в интерфейсе становится все рискованнее.

Хорошей базой для Manual QA сейчас выглядит следующий набор навыков.

Основы тестирования

Никуда не исчезли:

• техники тест-дизайна;
• классы эквивалентности;
• граничные значения;
• exploratory testing;
• regression testing;
• smoke testing;
• понимание жизненного цикла бага;
• умение писать тестовую документацию.

API

Хотя бы базовое понимание:

• HTTP;
• REST;
• методов GET, POST, PUT, PATCH, DELETE;
• status codes;
• headers;
• JSON;
• Postman.

SQL

Необязательно знать сложную оптимизацию баз данных.

Но SELECT, WHERE, ORDER BY, GROUP BY и JOIN для QA чрезвычайно полезны.

DevTools

Тестировщик должен уметь посмотреть:

• Network;
• Console;
• запросы;
• ответы;
• cookies;
• local storage.

Git

Хотя бы базовые операции и понимание того, зачем система контроля версий используется в команде разработки.

Основы автоматизации

Даже если вы пока не пишете полноценные автотесты, полезно понимать:

• что именно стоит автоматизировать;
• как устроен автотест;
• что такое locator;
• assertion;
• test runner;
• CI/CD.

Умение работать с AI

Причем речь не только о фразе:

«ChatGPT, напиши мне тест-кейсы».

Гораздо ценнее способность дать модели контекст, проверить ее результат, заметить пропущенные сценарии и улучшить ответ.

AI должен быть помощником тестировщика, а не заменой мышления.

А что будет с Junior QA?

Именно для новичков изменения могут быть наиболее заметными.

Раньше работодателю мог быть полезен начинающий специалист, который выполнял большое количество относительно простой ручной работы.

Теперь часть этой рутины можно ускорить автоматизацией и AI.

Поэтому Junior QA приходится быстрее выходить за пределы теории.

Одного знания определений вроде «что такое smoke testing» или «чем severity отличается от priority» недостаточно.

Гораздо полезнее уметь показать:

• как вы протестируете реальный сайт;
• какие проверки предложите для API;
• как найдете данные через SQL;
• как оформите баг;
• как будете действовать, если требования неполные;
• как используете AI и как проверяете его ответы.

Нужно ли теперь писать про AI в резюме QA?

Если вы действительно используете AI в работе — да.

Но формулировка:

«Умею пользоваться ChatGPT»

практически ничего не говорит работодателю.

Лучше описывать конкретное применение.

Например:

Использую AI-инструменты для генерации первоначальных наборов тест-кейсов и тестовых данных с последующей ручной валидацией.

Или:

Использовал LLM для анализа требований, поиска дополнительных edge cases и подготовки черновиков тестовой документации.

Еще лучше, когда навык связан с конкретным результатом или проектом.

При этом нет смысла добавлять AI в каждую вторую строку резюме только потому, что тема сейчас популярна.

Резюме должно в первую очередь быстро показывать работодателю, какие задачи QA вы умеете решать.

Нативная интеграция

Рынок тестирования меняется, а резюме многих QA остается таким же, каким было несколько лет назад.

Человек уже работает с Postman, SQL, DevTools, API или AI-инструментами, но из резюме это практически невозможно понять. В результате полезные навыки есть, а на этапе первичного просмотра они просто не замечаются.

updatecv.me позволяет загрузить резюме и посмотреть, насколько хорошо в нем представлены навыки, опыт и сильные стороны кандидата, а также какие места стоит улучшить перед следующими откликами.

Какие задачи Manual QA AI заберет в первую очередь

Если упростить ситуацию, наиболее уязвимы задачи, которые:

• постоянно повторяются;
• имеют четкие входные данные;
• имеют однозначный ожидаемый результат;
• легко формализуются;
• не требуют понимания бизнес-контекста.

Например, прогон одного и того же regression checklist вручную после каждого релиза — очевидный кандидат на автоматизацию.

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

Стоит ли Manual QA переходить в Automation?

Необязательно выбирать между двумя крайностями:

«Я только Manual QA»

и

«Теперь срочно становлюсь разработчиком автотестов».

Гораздо практичнее двигаться постепенно:

Manual QA → API → SQL → Git → основы программирования → простые автотесты → более сложная автоматизация.

AI здесь как раз может выступать в роли помощника.

Например, можно взять хорошо знакомый вам ручной сценарий и попробовать автоматизировать его с помощью Playwright, одновременно попросив AI объяснять каждую строку кода.

Так обучение будет значительно полезнее, чем простое копирование готового решения.

Так заменит ли AI ручных тестировщиков?

Полностью — в обозримой перспективе это выглядит маловероятно.

А вот изменить профессию он уже успел.

AI хорошо справляется с генерацией, преобразованием и обработкой информации. Он может быстрее тестировщика создать двадцать вариантов тест-кейсов или написать черновик автоматизированного теста.

Но количество тест-кейсов само по себе никогда не было главным показателем хорошего QA.

Ценность тестировщика заключается в другом:

понять, где продукт может сломаться, почему это важно и что команда могла не предусмотреть.

Поэтому наиболее перспективной выглядит не борьба «AI против Manual QA», а связка:

QA + AI.

Тестировщик, который понимает продукт, умеет исследовать систему, знает API и SQL и при этом использует AI для ускорения рутины, становится продуктивнее специалиста, который принципиально игнорирует новые инструменты.

И, возможно, главный вопрос в 2026 году звучит уже не:

«Заменит ли AI тестировщика?»

А:

«Какие задачи будет решать тестировщик, когда AI возьмет на себя большую часть рутины?»

А если ищете работу и хотите проверить свое резюме и найти и исправить ошибки — заходите на updatecv.me: