Ручное тестирование с ИИ: как создавать тест-кейсы и не терять качество

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

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

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

Что остаётся ручным в тестировании с ИИ

Ручное тестирование — работа, в которой человек выполняет проверки, наблюдает поведение продукта и оценивает результат. Инструменты при этом не запрещены: тестировщик пользуется API-клиентом, журналами событий, генератором данных или системой управления тестированием — TMS, test management system. Помощь ИИ при подготовке сценария не превращает его последующее ручное выполнение в автотест.

До выполнения нужно определить, что проверять и зачем. Анализ требований выявляет условия и неопределённости; тест-дизайн превращает их в проверки с данными и ожидаемыми результатами. После выполнения инженер сопоставляет ожидание с фактом и разбирает расхождения. Эти задачи связаны, но результат одной не заменяет другую; разделение анализа, проектирования и выполнения входит в основы процесса тестирования ISTQB CTFL.

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

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

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

Если модель предлагает «ссылка действует 24 часа», нужно выяснить, откуда взялось число. Оно может следовать из спецификации, а может быть правдоподобной догадкой. Во втором случае полезен вопрос к команде, но не тест с уже утверждённым сроком.

Когда ИИ помогает создавать тест-кейсы, а когда лучше сменить задачу

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

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

Типовой интерфейс не означает низкого риска. Форма восстановления пароля выглядит проще платёжного экрана, но ошибка в ней может открыть доступ к чужому аккаунту. И наоборот, для нескольких понятных проверок подготовка контекста и разбор ответа иногда дороже самостоятельного написания. Выбор «без ИИ» — нормальный результат оценки задачи.

Как использовать ChatGPT, Claude и DeepSeek без потери контекста

В этой статье ChatGPT, Claude и DeepSeek — примеры ИИ-сервисов, через которые можно готовить тестовые материалы. Сервис, используемая языковая модель и её конкретная версия — не одно и то же. Поэтому сравнивать стоит одинаковые задачи в зафиксированных условиях, а не названия продуктов или красоту одного ответа.

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

Что передать на вход

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

У каждого источника желательно оставить идентификатор и редакцию. Тогда предложение можно связать с конкретным пунктом, а при изменении требования — найти зависимые проверки. Подготовка такого QA-контекста для ИИ важнее длинного описания роли «опытного тестировщика».

Короткая рабочая инструкция может выглядеть так:

Сначала найди неоднозначности и противоречия в переданных требованиях. Отдели заданные правила от предположений. Затем предложи тестовые условия и черновики сценариев: цель, предусловия, данные, действия, наблюдаемый ожидаемый результат и основание в источнике. Не придумывай сроки, лимиты и поведение, которых нет в материалах. Неопределённые ожидания вынеси в вопросы. Сопоставь предложения с существующими кейсами; возможные дубли объясни, но ничего не удаляй и не утверждай автоматически.

Это ограничивает задачу, но не доказывает точность ответа. Ссылку на требование тоже нужно открыть: модель может указать существующий пункт, который не подтверждает её вывод.

Какие данные нельзя передавать по умолчанию

Допустимость передачи требований, логов и учётных данных определяется правилами компании и условиями выбранного сервиса. У OpenAI различаются режимы использования данных для индивидуальных и бизнес-продуктов; у Anthropic условия коммерческих продуктов описаны отдельно. Для DeepSeek нужно учитывать политику соответствующего сервиса, а не переносить на него настройки другого провайдера.

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

Пример: как разобрать тест-кейсы для восстановления пароля

Ниже — учебная ситуация, а не результат замера конкретной модели и не описание функции ТестОпс. Исходное требование намеренно неполное:

Зарегистрированный пользователь может запросить восстановление пароля по электронной почте. Система отправляет письмо со ссылкой для установки нового пароля. После успешного изменения пользователь может войти с новым паролем.

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

Что делать с правдоподобными, но неподтверждёнными ожиданиями

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

Здесь важно не смешать продуктовую неопределённость с риском безопасности. OWASP Forgot Password Cheat Sheet рекомендует одинаковый ответ для существующих и несуществующих аккаунтов, защиту от массовых запросов, одноразовые токены и ограниченный срок их действия. При этом руководство не назначает универсальный срок в 24 часа и не устанавливает для любого продукта правило «работает только последняя ссылка».

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

Как выглядит оформленная ручная проверка

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

Название: вход с новым паролем после восстановления доступа.

Основание: критерий приёмки о входе после успешной смены пароля.

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

1. Открыть форму восстановления, указать адрес тестовой учётной записи и отправить запрос.
2. В тестовом почтовом ящике открыть письмо, относящееся к этому запросу.
3. Перейти по ссылке и задать подготовленный новый пароль.
4. Открыть форму входа в отдельной неавторизованной сессии.
5. Ввести адрес учётной записи и новый пароль.

Ожидаемый результат: вход успешен; открыта именно тестовая учётная запись, для которой выполнялось восстановление. Успех подтверждается доступом к ней, а не только сообщением «Пароль изменён».

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

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

Как проверить тест-дизайн и принять сгенерированный набор

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

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

Как перепроверить классы, границы и состояния

Модель может предложить любую из техник тест-дизайна. Задача инженера — проверить, к каким правилам она применена и не подменяет ли анализ перечислением примеров.

Классы эквивалентности. Пустое поле, некорректный адрес и корректный адрес незарегистрированного пользователя могут обрабатываться разными правилами. Это не автоматически один класс «невалидный email». Два кейса считают дублями по одинаковому условию и ожиданию, а не по похожим шагам или названию.

Граничные значения. Сначала подтверждают срок действия токена и точный момент, с которого он отсчитывается. Затем проверяют состояние до границы, на ней и после неё — с учётом заданной точности времени и правила равенства. Без этого набор «14, 15 и 16 минут» лишь создаёт видимость точного тест-дизайна.

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

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

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

Какие решения принимать по каждому черновику

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

В карточке или комментарии полезно сохранять причину решения. «Отклонено как дубль TC-12» сообщает больше, чем исчезнувшая строка. «Ожидает уточнения срока жизни токена» позволяет вернуться к вопросу после ответа аналитика.

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

Как увидеть то, чего в наборе нет

Для проверки набора полезна карта «правило или риск → тестовое условие → тест-кейс». У каждого условия остаётся понятный статус: есть принятая проверка, есть только гипотеза, требуется ответ команды или проверка сознательно отложена с объяснением причины.

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

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

Как AI Ассистент и MCP ТестОпс помогают работать с ручными кейсами

Без подключённых инструментов чат получает выбранные пользователем фрагменты, а ответ остаётся текстом, который ещё нужно проверить и перенести. Интеграция меняет способ получения данных и выполнения операций, но не критерии приёмки кейса. В ТестОпс важно различать встроенного Ассистента и два направления работы через MCP.

Встроенный Ассистент: повторяемые задачи внутри проекта

AI Ассистент ТестОпс работает внутри продукта; его навыки, или конфигурируемые агенты, задают повторяемую задачу, инструкцию и доступные инструменты. В документации прямо предусмотрен сценарий генерации тест-кейсов по описанию задачи. Это предметная возможность, а не просто чат рядом с тестовой базой.

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

По состоянию на 23 октября 2026 года документация описывает Ассистента как отдельно лицензируемую бета-функцию. Для работы нужны доступ к ИИ, настройка провайдера и подходящая версия ТестОпс. Этот статус нельзя автоматически переносить на все остальные функции TMS.

MCP: доступ к данным, а не автоматическое подтверждение качества

Model Context Protocol — протокол взаимодействия ИИ-приложений с внешними источниками и инструментами. Он задаёт способ обмена, но не определяет, достаточно ли контекста, правильно ли модель его поняла и следует ли принимать предложенную правку.

Внешняя ИИ-среда → MCP-сервер ТестОпс. Подключённая среда, например Claude Desktop, получает доступ к инструментам TMS. Действия выполняются от имени владельца API-токена и в пределах его проектных прав. Среди документированных инструментов есть поиск, создание и изменение тест-кейсов, добавление комментариев и получение деталей требований из настроенных внешних интеграций.

AI Ассистент ТестОпс → внешний MCP-сервер. Это обратное направление: подключение внешней системы даёт Ассистенту её данные и инструменты. Такое подключение не равнозначно открытию всей тестовой базы внешнему чат-боту.

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

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

Как не смешать черновик, активный кейс и результат проверки

В воркфлоу ручных тест-кейсов предусмотрены статусы «Черновик», «Ревью», «Активный» и «Устаревший». Их можно использовать для работы с предложениями ИИ: держать неподтверждённые сценарии отдельно, передавать на ревью и включать в рабочий набор после проверки. Сам статус не доказывает качество и не означает автоматически, что черновик невозможно запустить: состав запусков и правила отбора контролируются отдельно.

Когда требование хранится в поддерживаемой внешней системе, его можно связать с ручным тест-кейсом. Доступность зависит от интеграции; в документации отдельно оговорены ограничения вариантов Data Center. Связь помогает находить нужные проверки и результаты, но не подтверждает достаточность покрытия.

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

Завершает путь не сохранение карточки, а ручное выполнение на тестируемом продукте. В TMS фиксируют фактический результат и свидетельства; сообщение модели «сценарий проверен» без выполнения этого не заменяет.

Как понять, что ИИ экономит время, а не переносит работу на ревью

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

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

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

Качественный результат пилота — не «модель выдала 40 кейсов за минуту», а объяснение, какая часть работы сократилась и что осталось непроверенным. Если подготовка контекста и исправление догадок заняли весь выигрыш, следующую похожую задачу разумнее решить вручную либо изменить сам способ применения ИИ.

Что сохранять вместе с принятыми тест-кейсами

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

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

Хороший результат работы с ИИ — набор, по которому понятно, что проверяется, почему ожидается именно такое поведение и какие вопросы ещё открыты. Иногда модель ускоряет подготовку. Иногда её самое полезное действие — вовремя показать, что писать готовый тест-кейс пока рано.