Модуль 1 · Основы · урок 1 из 13
Тестировщик и агент: что меняется в работе QA
Codex пишет код быстрее, чем люди успевают его проверять, и узким местом становится как раз проверка. Для тестировщика это не угроза, а смена фокуса: меньше ручного набора кода и чек-листов с нуля, больше решений о том, что и как проверять. В этом уроке — карта курса и главная мысль, к которой мы будем возвращаться.
Что агент делает хорошо
Агент читает требования, код и существующие тесты за минуты и предлагает черновик: список проверок, набор граничных значений, спек на Playwright, API-тест, фикстуру, баг-репорт по логам. В собственном гайде OpenAI о том, как инженеры компании используют Codex, отдельно отмечено, что агент хорошо находит граничные условия — пустой ввод, максимальную длину, необычные, но допустимые состояния (How OpenAI uses Codex).
Агент ещё и запускает то, что написал: прогоняет тесты, читает вывод, правит и повторяет. С браузером — встроенным в ChatGPT desktop app или подключённым через Playwright MCP — он открывает страницу, кликает, смотрит на результат. Это уже не «сгенерируй мне тест», а исследование вместе с исполнителем.
Что остаётся за вами
- Решение, что проверять. Агент не знает, какие сценарии критичны для бизнеса, какой баг стоил клиенту денег в прошлом релизе и где ломалось после каждого обновления CMS.
- Оценка результата. Тест, который агент написал и сам же прогнал, может проверять не то. Зелёный прогон — не доказательство.
- Граница рисков. Куда агенту можно ходить с браузером, какие данные ему видеть, что запускать без вопросов.
Главная мысль курса
Тесты, написанные агентом, надо проверять так же строго, как код, который они покрывают. Простой вопрос «упадёт ли этот тест, если фикса нет?» отсеивает удивительно много пустых проверок. Биргитта Бёкелер (Thoughtworks) в статье на сайте Мартина Фаулера называет проверку поведения «слоном в комнате» среди всех контролей вокруг агента: на практике тестам, сгенерированным AI, доверяют слишком много (Harness engineering for coding agent users). Этому посвящён урок «Как проверять тесты, написанные агентом», а приёмы из него встречаются по всему курсу.
Как устроен курс
- Основы: настройка Codex под тестирование, тест-дизайн по требованиям, юнит- и интеграционные тесты.
- Автоматизация: e2e на Playwright (TypeScript), браузер в руках агента, API-тесты, тестовые данные и фикстуры.
- Баги и регресс: воспроизведение и баг-репорты, нестабильные тесты, регресс в GitLab CI, проверка агентских тестов.
Курс рассчитан и на ручных тестировщиков, и на автоматизаторов. Ручным пригодятся тест-дизайн, браузер и баг-репорты; автоматизаторам — всё про Playwright, API и CI. Примеры — из работы агентства: сайт на OctoberCMS/Laravel с e2e-регрессом, мобильные приложения, задачи в Kaiten, MR в GitLab. Если вы ещё не работали с Codex, начните с курса «Codex с нуля».
Попробуйте сами
10–15 мин на рабочем месте- Выпишите три проверки, которые вы делаете руками в каждом релизе. Отметьте, какие из них агент мог бы подготовить, а какие требуют вашего знания продукта.
- Откройте любой автотест в своём проекте и задайте себе вопрос: что конкретно сломается в продукте, чтобы он упал? Если ответ неочевиден — это будущий материал для урока о проверке тестов.
Коротко
- Codex ускоряет подготовку проверок и сам их запускает; узким местом становится проверка результата.
- За QA остаются выбор сценариев, оценка рисков и приёмка того, что сделал агент.
- Зелёный тест, написанный агентом, ничего не доказывает, пока вы не убедились, что он падает без фикса.
- Курс ведёт от тест-дизайна и настройки к Playwright, API, баг-репортам и регрессу в CI.