AI в тестировании: что забирают нейросети и что остаётся человеку

Обе картинки правдивы, и AI в тестировании сейчас живёт ровно между ними.

Полезно разделить задачи на две группы. В первой модель экономит время: черновик тест-кейсов, заготовка баг-репорта, разбор длинного лога, перевод документации. Во второй она создаёт ложную уверенность: выдаёт аккуратный список проверок, в котором половина данных не соответствует названию кейса, и ничем не показывает, что сомневается. Тестировщик, который понимает эту границу, работает быстрее. Тот, кто не понимает, пропускает баги с отчётом о полном покрытии на руках. Почему модели пока помогают специалистам и не заменяют их, мы подробно разбирали в статье Почему AI пока не заменят разработчиков, но сильно им помогут.

Тест-кейсы по требованиям. На вход подаётся текст требования или пользовательской истории, на выходе получается таблица проверок с шагами и ожидаемым результатом. Позитивные сценарии модель покрывает хорошо, с форматом справляется лучше большинства джунов. Работа тестировщика сдвигается с набора текста на проверку: каждую строку нужно прочитать и сверить с требованием, а недостающие кейсы дописать. Что обычно приходится дописывать, видно на примере в следующем разделе.

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

Разбор логов. Лог падения на несколько тысяч строк модель читает быстрее человека: группирует повторяющиеся ошибки, находит первое исключение в цепочке, предлагает версию причины. Версию нужно проверять. Модель видит только тот фрагмент, который вы ей дали, и легко выдаёт следствие за причину, если начало проблемы осталось за пределами вставленного куска.

Локаторы и код автотестов. Автоматизатору модель подсказывает локатор по куску разметки страницы, пишет заготовку теста по описанию кейса, переводит тест с одного фреймворка на другой. Ассистенты в редакторе кода делают это прямо в проекте. Сгенерированный код компилируется чаще, чем работает правильно: типичная ошибка в том, что тест проходит, но проверяет не то, что нужно, или жёстко привязан к тексту на кнопке, который поменяется в следующем релизе.

Документация и перевод. Тест-план, описание тестового окружения, перевод требований с английского, вычитка своего текста на ошибки. Это самая безопасная зона: ошибку в формулировке заметит любой читатель, а цена её невысока. Какие сервисы для этого подходят, есть в нашей подборке Топ нейросетей для работы в IT-сфере.

Удобнее всего показать на живом примере. 7 октября 2026 года мы дали модели Claude Haiku 4.5 короткое требование и обычный запрос без подсказок, как это сделал бы тестировщик в рабочем чате.

Требование: поле Пароль на форме регистрации принимает от 8 до 20 символов, минимум одну цифру и минимум одну заглавную латинскую букву. Если пароль не подходит, под полем появляется сообщение об ошибке, а кнопка Зарегистрироваться неактивна.

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

Кейс Валидный пароль минимум использует строку Qwerty123, а в ней 9 символов, не 8. Кейс Валидный пароль максимум использует строку из 17 символов вместо 20. Получается, что обе границы, ради которых кейсы и писались, не проверены. Дальше хуже. Кейс Пароль длиннее 20 символов подаёт строку Qwerty12345678901234, в которой ровно 20 символов, и ждёт ошибку. Ещё одна строка подписана как 21 символ, хотя в ней 18. По требованию оба пароля правильные. Если прогнать такие кейсы, тестировщик заведёт баг на корректное поведение системы и потратит время разработчика на разбор несуществующей проблемы. Наконец, кейс QWERTY123 ждёт ошибку из-за отсутствия строчных букв, хотя такого правила в требовании нет. Модель дописала его от себя, потому что так часто бывает в похожих формах.

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

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

Тестировщики здесь не исключение. В опросе Stack Overflow Developer Survey 2025 года 84% участников используют AI-инструменты или собираются начать, но точности их ответов доверяют только 33%, а 46% не доверяют. Главная жалоба, которую назвали 66% опрошенных: ответы почти правильные, но не совсем. Для тестирования это самый неудобный вид ошибки, потому что его труднее всего заметить.

Рабочий порядок проще всего выстроить по ролям модели.

Модель идёт первой там, где нужен черновик, а проверка дешевле написания с нуля. Набор кейсов по новому требованию, тестовые данные, заготовка тест-плана, оформление баг-репорта из ваших заметок. Правило одно: всё, что модель выдала, вы читаете целиком, а цифры и строки пересчитываете. Пример с паролем показывает, что ошибки прячутся именно в данных.

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

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

Модель не пускают туда, где решение несёт ответственность. Финальный вердикт о готовности релиза, оценка риска для бизнеса, приоритет дефекта. И туда, куда нельзя передавать данные.

С данными правила такие. В бесплатных и личных тарифах переписка с моделью может использоваться для её дальнейшего обучения, если не отключить это в настройках. Например, Anthropic с осени 2025 года просит пользователей тарифов Claude Free, Pro и Max самим выбрать, разрешать ли обучение на их чатах, а корпоративные тарифы и доступ через API это правило не затрагивает. Похожие настройки есть у OpenAI. Для тестировщика вывод простой: рабочие данные отправляются только в те инструменты, которые разрешены в компании. Личные данные пользователей, пароли, токены, куски кода под NDA и логи с продакшена в личный чат с моделью не уходят. Если нужно разобрать такой лог, сначала уберите из него всё, по чему можно узнать человека или систему.

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

Порядок работы мало зависит от того, ручной вы тестировщик или автоматизатор: меняются только задачи, которые отдаются модели. Если вы ещё выбираете направление, начните со статьи Выбираем автоматизированное или ручное тестирование. А системно выстроить такую работу, от промптов до собственных QA-ассистентов, помогает курс Тестирование с AI.

Вопрос, заменят ли нейросети программистов и тестировщиков, обычно задают так, будто профессия состоит из набора текста. Тест-кейсы и баг-репорты действительно можно генерировать. Но до кейсов тестировщик задаёт вопросы к требованию: что будет, если пользователь вставит пароль из менеджера паролей, что делать с паролем, который подходил по старым правилам. Модель такие вопросы не задаёт, она отвечает на заданные. Тестировщик оценивает, какой дефект опаснее для бизнеса, договаривается с разработкой, когда исправление важнее срока, и в итоге говорит, можно ли выпускать релиз. За это решение отвечает человек.

Посмотрим, чего ждут работодатели. 7 октября 2026 года на rabota.by по Беларуси была открыта 71 вакансия тестировщика. Мы прочитали все вакансии, где встречаются ChatGPT, Claude, Copilot, нейросети, LLM, AI или ИИ, и разделили упоминания по смыслу.

В 19 вакансиях из 71, это 27%, работа с AI-инструментами записана в требования, обязанности или стек команды. Из них в 15 это обязательное требование или прямая обязанность: использовать ассистентов для тест-кейсов, анализа требований, подготовки тестовых данных. В двух это будет плюсом, ещё в двух инструменты перечислены в стеке. Ещё в одной вакансии нужно тестировать AI-функции самого продукта, а в четырёх AI встречается только в рассказе о компании. Формулировка почти везде одинаковая: нужен практический опыт использования в рабочих задачах. В одной вакансии отдельно прописано правило, что код и документы под NDA не уходят в AI-сервисы, кроме разрешённых в компании.

То есть навык работы с моделями становится частью базового набора тестировщика. При этом ни одна из 71 вакансии не предлагает модели заменить тестировщика: везде модель стоит рядом с человеком, который отвечает за результат.

Появляется и новая работа. В одной из вакансий того же среза нужно тестировать функции продукта, построенные на языковой модели: проверять качество и полноту её ответов. Это отдельное направление со своими приёмами. Тестировщик собирает эталонный набор вопросов с правильными ответами, проверяет, как модель ведёт себя на провокационных запросах, не выдаёт ли она данные, которых пользователь видеть не должен, и стабилен ли ответ на один и тот же вопрос. Классические техники тест-дизайна здесь работают, просто ожидаемый результат описывается критериями, по которым ответ считается приемлемым, вместо одного точного значения. Таких вакансий пока единицы, но именно сюда со временем уходит часть тестировщиков, которые уже уверенно работают с моделями как пользователи.

Возьмите короткое требование: поле Возраст в анкете принимает целые числа от 18 до 65 включительно, при другом значении под полем появляется ошибка и анкету нельзя отправить.

Попросите любую доступную вам модель составить тест-кейсы для этого поля. Не подсказывайте ей ничего сверх требования. Затем проверьте результат по списку.

1. Есть ли значения на обеих границах: 18 и 65 как допустимые, 17 и 66 как недопустимые.
2. Есть ли значение из середины допустимого диапазона.
3. Проверены ли дробное число, отрицательное число и ноль.
4. Проверены ли буквы, спецсимволы и пустое поле.
5. Что происходит с пробелами до и после числа и с ведущим нулём, например 018.
6. Есть ли очень большое число, которое может не поместиться в тип данных.
7. Проверен ли текст сообщения об ошибке: что именно в нём написано и понятно ли пользователю, что исправить.
8. Совпадают ли значения в каждом кейсе с тем, что написано в его названии. Пересчитайте их сами.
9. Нет ли кейсов с правилами, которых в требовании нет.

Если модель закрыла семь пунктов и больше, у вас хороший черновик, который нужно только вычитать. Если меньше пяти, обратите внимание, какие классы она пропустила: обычно это пункты 3, 5 и 6. Именно их придётся дописывать руками в рабочих задачах, и именно на них стоит проверять любой сгенерированный набор.

Если хочется разобрать такие задания с наставником и собрать свой набор промптов под рабочие задачи, на курсе Тестирование с AI это делают на практике с ментором уровня QA Lead.

Заменят ли нейросети тестировщиков?
Пока нет. Модели забирают черновую часть работы, но не задают вопросы к требованиям и не отвечают за релиз. В вакансиях на rabota.by в октябре 2026 года работа с AI указана как навык тестировщика, который отвечает за результат.

Можно ли загружать в модель рабочие данные?
Только в те инструменты, которые разрешены в компании. В личных тарифах переписка может использоваться для обучения модели. Персональные данные пользователей, пароли, токены и код под NDA в личный чат с моделью не отправляют.

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

Берут ли на работу за умение работать с AI?
Само по себе нет. Работодатели ищут тестировщика, который знает техники тест-дизайна и умеет ускорять работу ассистентами. Без базы тестирования навык промптов не поможет заметить ошибку модели.

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