Трек: тестировщик

Что меняется в роли

Тестирование всегда состояло из двух частей: придумать, что может сломаться, и методично это проверить. Агент (agent) забирает вторую часть (расписать кейсы по шаблону, набросать код автотеста, оформить баг-репорт) и тем самым делает первую часть главной. Ценность тестировщика окончательно смещается от «исполнить проверки» к «спроектировать проверки»: построить модель рисков продукта и решить, куда смотреть в первую очередь.

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

И как везде с агентами, ответственность остаётся на человеке. «Тесты зелёные» ничего не значит, пока вы не убедились, что тесты проверяют то, что нужно, и способны падать. Тестировщик, который проверяет работу агента так же въедливо, как продукт, становится ценнее; а тот, кто просто прогоняет сгенерированное, превращается в конвейер у конвейера.

Основные сценарии

1. Тест-кейсы и чек-листы по требованиям

Задача. По требованиям к фиче составить набор проверок, включая негативные и краевые.

Как поставить агенту:

Вот требования к форме восстановления пароля (ниже). Составь
тест-кейсы в формате «предусловие — шаги — ожидаемый результат»
по группам: позитивные, негативные, краевые. Обязательно покрой:
несуществующий email, истёкшую ссылку, повторное использование
ссылки, параллельные запросы на восстановление. Отдельным списком —
вопросы к требованиям: что не определено или противоречиво.

[требования]

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

2. Черновики автотестов по сценариям

Задача. Готовые ручные сценарии перевести в код автотестов.

Как поставить агенту:

Вот три ручных сценария по оформлению заказа (ниже). Напиши
черновики автотестов на Playwright в стиле наших существующих
тестов (посмотри tests/e2e/checkout). Используй наши
page objects, не создавай дубли. Каждый тест должен проверять
конечное состояние (заказ в базе, письмо отправлено), а не только
отсутствие ошибок на экране.

[сценарии]

Как проверить. Запустите тесты и убедитесь, что они проходят. Затем самое главное: сломайте проверяемое поведение (например, закомментируйте отправку письма) и убедитесь, что тест падает. Проверьте, нет ли в коде «мягких» проверок вроде ожидания элемента без утверждения о его содержимом.

3. Исследовательское тестирование с агентом в браузере

Задача. Быстро прощупать новую фичу на стенде: агент управляет браузером через Playwright MCP (Model Context Protocol), вы направляете исследование.

Как поставить агенту:

Открой стенд https://staging.example.com и исследуй новую форму
создания проекта. Твоя цель — сломать её: очень длинные названия,
эмодзи и HTML в полях, двойные отправки, кнопка «назад» посреди
процесса, повторное открытие формы в двух вкладках. Фиксируй
каждую аномалию: шаги, что увидел, скриншот. Не трогай ничего
за пределами раздела «Проекты».

Как проверить. Воспроизведите каждую найденную аномалию руками, прежде чем заводить баг: агент может неверно интерпретировать нормальное поведение как ошибку. И наоборот, просмотрите, где агент прошёл «гладко»: он мог не заметить визуальный дефект или кривую формулировку, очевидную человеку.

Осторожно

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

4. Улучшение баг-репортов

Задача. Из сырой заметки «на проде падает выгрузка» сделать репорт, по которому разработчик сразу начнёт работать.

Как поставить агенту:

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

[заметки и лог]

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

5. Анализ покрытия требований тестами

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

Как поставить агенту:

Вот требования к модулю подписок (ниже) и наши тест-кейсы
(файл subscriptions-cases.md). Построй таблицу трассировки:
требование — покрывающие его кейсы. Отдельно выведи:
требования без единого кейса; кейсы, не привязанные ни к одному
требованию; требования, покрытые только позитивными проверками.

[требования]

Как проверить. Выборочно проверьте несколько строк таблицы: действительно ли кейс проверяет то требование, к которому привязан, а не просто упоминает те же слова. Список «требований без кейсов» — рабочий план; список «кейсов без требований» обсудите с аналитиком: это либо лишние тесты, либо незадокументированные требования.

Чего остерегаться

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

Маршрут по сайту для тестировщика

1. Что такое агент и Инструменты: что агент умеет делать сам и как это устроено.
2. MCP: основа сценария с управлением браузером.
3. Промптинг: как формулировать задачи на генерацию проверок.
4. Проверка результатов, профильный для вас раздел: верификация — ядро роли.
5. Безопасность: правила для агента с доступом к стендам и данным.
6. Обзор харнесов: выбор инструмента для повседневной работы.

С чего начать на этой неделе

1. Возьмите требования к ближайшей фиче и сгенерируйте по ним тест-кейсы (сценарий 1). Сравните со своим чек-листом: что агент нашёл, а вы нет, и наоборот. Второй список важнее: это ваша модель рисков, которой нет у агента.
2. Отдайте агенту один сырой баг-репорт на доработку и прогоните полученные шаги воспроизведения буквально. Так вы за полчаса откалибруете, насколько ему можно доверять оформление.
3. Разверните Playwright MCP на тестовом стенде и проведите одну сессию исследовательского тестирования с агентом на некритичной фиче. Начните с узкой зоны и явного запрета выходить за её пределы.

Что дальше

• Проверка результатов: систематический подход к верификации работы агента.
• Типичные ошибки: что чаще всего идёт не так при работе с агентами.