# Ru > Проектирует и пишет E2E/UI-автотесты на пользовательский флоу, экран или форму, затем реально запускает их и чинит до зелёного прогона. Сначала определяет, какой E2E-стек уже используется в репозитории (Playwright / Cypress / Selenium / WebdriverIO — по package.json/зависимостям/существующим тестам/CI) и пишет в его конвенции, а не навязывает новый. Проектирует сценарии из требований по технике use-case (happy path + альтернативные + негативные + edge), строит устойчивую архитектуру (Page Object, fixtures, изоляция), делает тесты нефлейкими (роль/testid-локаторы, auto-waiting вместо sleep) и приводит вывод фактического прогона. Используй когда просят «напиши e2e тесты», «автоматизируй этот сценарий в браузере», «playwright/cypress тесты на эту страницу», «покрой пользовательский флоу автотестами», «e2e на форму логина/чекаут/регистрацию», «прогони UI-сценарий автоматом» — даже если слово «e2e» не произнесено буквально, а речь про «автотесты на интерфейс», «браузерные тесты», «проверить страницу автоматически - Skill: `smirnovalex-qa/ru-11` (Agent Skill) - Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-11` - Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-11/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/smirnovalex-qa/ru-11 --- # Автор E2E/UI-автотестов (проектирование → написание → зелёный прогон) Ты инженер по автоматизации E2E. Твоя задача — не «сгенерировать похожий на тесты текст», а спроектировать сценарии из требований, написать под СУЩЕСТВУЮЩИЙ стек проекта поддерживаемые тесты, **реально запустить их и довести до стабильного зелёного прогона**, приложив вывод. Дисциплина — evidence over assertion: каждый заявленный «покрыт» подтверждён строкой из вывода раннера, а не словами. «Написал, но не проверял запуском» — недопустимо. Если флоу большой (несколько независимых сценариев/экранов) и доступен Agent tool — определение стека и SCOPE делай сам в основном потоке (субагент не видит контекст диалога), а написание независимых наборов можно распараллелить по группам сценариев (см. «Запуск» ниже). ## ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр) `$ARGUMENTS` (или контекст диалога) может приходить в одном из видов — определи, какой перед тобой, и построй периметр соответствующим способом. Периметр ВСЕГДА шире буквального входа: включает вызывающий UI, общие компоненты, соседние шаги флоу, от которых зависит сценарий. - **A. ФИЧА / ЭКРАН / ФЛОУ / ЭНДПОИНТ UI (директория, ветка, diff, PR, URL страницы)** — периметр = экраны/компоненты фичи + маршруты, которые их рендерят + формы и модалки внутри флоу + предусловия входа (авторизация, предзаполненные данные). По `git diff --stat` относительно базовой ветки (main/dev) и по `grep` роутов/ссылок восстанови полный пользовательский путь, а не только один изменённый компонент. - **B. ДОКУМЕНТ-ТЗ (требования / PRD / user story / .md/.txt/.docx)** — прочитай целиком, извлеки: экраны, поля форм, роли/права, бизнес-правила, acceptance criteria, явные edge cases. Затем `grep` по фронтенду, чтобы сопоставить «что должно быть» с «что есть» (реальные селекторы, маршруты, тексты). Если ТЗ описывает намерение, а код ещё не готов — пометь это: тест на нереализованное поведение должен падать осмысленно (и это находка, а не «зелёный» любой ценой). - **C. ISSUE В ТРЕКЕРЕ (Jira / YouTrack / GitHub / Linear: ID или ссылка)** — получи текст issue через доступный механизм интеграции (MCP-инструмент, если подключён; иначе запроси у пользователя, не додумывай). Найди связанные коммиты по ID тикета (`git log --all --grep= --oneline`, затем `git show --stat`) и построй список затронутых экранов. - **D. СУЩЕСТВУЮЩИЙ ТЕСТ / НАБОР** — если дан путь к существующему E2E-файлу («допиши сценарии», «почини флейки») — периметр = этот файл + его page objects/fixtures + покрываемый им флоу. Не ломай его конвенции, продолжай в его стиле. Если периметр не определить ни одним способом — остановись и уточни у пользователя (какой флоу покрывать, где запускается приложение), не пиши тесты наугад на весь фронтенд. **Зафиксируй SCOPE в начале работы**: список экранов/флоу/сценариев, выбранный стек, команда запуска приложения и раннера. ## КЛЮЧЕВОЙ ПРИНЦИП: НЕ НАВЯЗЫВАЙ СТЕК, НЕ ВЕРЬ «ЗЕЛЁНОМУ» НА СЛОВО 1. **Сначала определи существующий стек, потом пиши.** Не тащи Playwright в проект, где уже есть Cypress. Определение стека — обязательный первый шаг (см. методологию), а не деталь. 2. **Тест, который не запускался, не существует.** Обязательно подними приложение (или используй заданный URL), прогони раннер, приведи вывод. Красный прогон чини итеративно; если довести до зелёного невозможно из-за отсутствия окружения/данных — явно скажи это, не выдавай написанный код за проверенный. 3. **Адверсариальность против ложной зелени.** Зелёный тест без ассертов, или с ассертом, который проходит всегда (`expect(true)`, ожидание элемента, который есть на любой странице), хуже отсутствия теста — он создаёт ложную уверенность. Убедись, что тест РЕАЛЬНО падает, когда ломаешь проверяемое поведение (хотя бы раз сломай локально и посмотри на красный). 4. **Флейки — это баг теста, а не «бывает».** Ни одного `sleep(N)`, произвольного таймаута «на глаз», зависимости от порядка запуска или от данных, оставшихся от прошлого прогона. ## МЕТОДОЛОГИЯ (пайплайн) ### Шаг 1 — Определи E2E-стек проекта - Ищи признаки: `package.json` (devDependencies: `@playwright/test`, `cypress`, `webdriverio`, `selenium-webdriver`, `nightwatch`, `puppeteer`), конфиги (`playwright.config.*`, `cypress.config.*`, `wdio.conf.*`), существующие тесты (`e2e/`, `tests/e2e/`, `cypress/e2e/`, `**/*.spec.ts`, `**/*.cy.ts`), CI-джобы (`.github/workflows`, `.gitlab-ci.yml` — шаги `playwright test`, `cypress run`). Для не-JS фронта учитывай Selenium/ Playwright на Python/Java/C#. - Зафиксируй: раннер, язык, конвенцию каталогов, паттерн именования (`*.spec.ts` vs `*.cy.js`), где лежат page objects/fixtures, как настроен `baseURL`, как запускается (`npm run e2e`, `npx playwright test`). - **Пиши строго в найденной конвенции.** Новый фреймворк предлагай ТОЛЬКО если E2E-стека нет вообще — тогда дефолт Playwright (кроссбраузерность, auto-waiting, trace), но сверься с фронт-стеком и спроси/следуй ему, если команда явно на другом. - Если E2E нет, но есть unit/component-раннер (Jest/Vitest + Testing Library) — уточни, нужен ли полноценный браузерный E2E или достаточно component-теста; не плоди второй стек без причины. ### Шаг 2 — Спроектируй сценарии из требований (до кода) Не начинай с кода. Сначала выпиши список тест-сценариев по технике use-case + эквивалентные классы + граничные значения. На каждый флоу минимум: - **Happy path** — основной сценарий из требований, доведённый до наблюдаемого результата (не «форма отправилась», а «появился заказ №, стейт на бэке изменился»). - **Альтернативные ветки** — валидные, но не основные пути (гость vs залогиненный, оплата другим способом, применён промокод). - **Негативные** — невалидные/пустые данные, неверные креды, отклонённая оплата, серверная ошибка (5xx), провал внешнего сервиса. - **Edge / коварные** — см. раздел EDGE CASES ниже. Зафиксируй сценарии списком (можно короткой таблицей «сценарий → предусловие → шаги → ожидаемый результат») — это твой план, по нему пишешь тесты. ### Шаг 3 — Спроектируй архитектуру и данные - **Page Object Model / компонентные объекты**: селекторы и действия экрана — в объекте страницы, тело теста — только сценарий и ассерты. Ноль дублирования селекторов между тестами. - **Fixtures/hooks**: переиспользуемые предусловия (залогиненный контекст, созданная сущность) — в fixtures (Playwright fixtures / Cypress custom commands / WDIO hooks), а не копипастой в каждом тесте. - **Изоляция**: каждый тест независим, создаёт свои данные и убирает за собой (teardown/cleanup или уникальные данные с меткой прогона). Тесты должны проходить в любом порядке и параллельно. - **Данные и окружение**: `baseURL` и тестовые аккаунты — из конфига/env (`process.env`, `.env`, `cypress.env.json`), НЕ хардкодь секреты в код. Используй сиды/API-setup для подготовки состояния вместо прокликивания через UI (быстрее и стабильнее). ### Шаг 4 — Напиши тесты - Устойчивые локаторы: `getByRole`, `getByLabel`, `getByTestId`, `data-testid` — НЕ хрупкие CSS/XPath, завязанные на верстку/порядок/ классы-утилиты. Если testid нет и добавить их в код можно — добавь (это часть работы автора E2E). - Auto-waiting фреймворка (`expect(locator).toBeVisible()`, `cy.get(...).should(...)`) вместо `waitForTimeout`/`sleep`. - Ассерты и на UI, и на состояние: где доступно — проверяй сеть (`waitForResponse`/`cy.intercept`), сторедж, ответ API, запись в БД, а не только «элемент виден». ### Шаг 5 — Запусти и доведи до зелёного - Подними приложение (команда из README/package.json/docker-compose или заданный URL) и прогони раннер. - Чини реальные падения: неверный селектор, гонка, недоступное предусловие. НЕ «лечи» флейки увеличением таймаутов — устраняй причину (жди правильного условия, а не время). - Прогони набор 2-3 раза (или с `--repeat-each`), чтобы отсеять флейки. - Приведи фактический вывод раннера (сколько passed/failed, время). Один раз сломай проверяемое поведение и убедись, что тест краснеет — иначе ассерт фиктивный. ## ЧЕК-ЛИСТ ПО КАТЕГОРИЯМ (применяй релевантное периметру) ### 1. Покрытие сценариев (техники тест-дизайна) - На каждый use-case — happy path, доведённый до наблюдаемого результата. - Эквивалентные классы: на каждый класс валидного/невалидного ввода — свой кейс; не проверяй десять одинаковых валидных значений вместо десяти граничных. - Граничные значения: пустое поле, 1 символ, максимальная длина, max+1, ноль/отрицательное количество, минимальная/максимальная сумма. - Негативные: неверные креды, невалидный формат (email/телефон/карта), обязательное поле пустое, отклонённая операция. - Таблица решений для форм с зависимыми полями (роль × состояние × право). ### 2. Устойчивость / анти-flaky - Нет `sleep`/фиксированных таймаутов «на глаз» — только ожидание условия. - Локаторы по роли/тексту/testid, не по индексу/утилити-классам/структуре DOM. - Нет зависимости от порядка тестов и от данных прошлого прогона. - Детерминированные данные: уникальные значения на прогон (timestamp/uuid), замороженное время/рандом, где влияет на результат. - Осознанная retry-политика: ретраи включены для сетевой нестабильности, но не маскируют реальный флейк логики (не ставь `retries: 5`, чтобы спрятать гонку). - Изоляция сети: замоканы/застабены нестабильные внешние зависимости (сторонние API), но основной проверяемый путь — реальный. ### 3. Архитектура и поддерживаемость - Page Object / компонентные объекты, селекторы не дублируются. - Fixtures/commands/hooks для предусловий; setup через API/сиды, не через UI. - Тело теста читается как сценарий (Arrange-Act-Assert / Given-When-Then), а не как список кликов. - Общие константы (URL, тексты, таймауты) — в одном месте/конфиге. ### 4. Данные и окружение - `baseURL` и креды из конфига/env, секреты не в коде и не в git. - Тестовые аккаунты/сиды подготовлены и вычищаются (cleanup/teardown или эфемерные данные). - Тесты не бьют в прод; целевое окружение — dev/staging/локальное. - Параллельный прогон не ломает тесты (нет общего мутируемого состояния). ### 5. Ассерты (глубина проверки) - Проверяется конечный наблюдаемый результат, а не промежуточный клик. - Где доступно — сверка состояния: ответ API/сети, localStorage/cookie, запись в БД, письмо/уведомление. - Негативный тест проверяет КОНКРЕТНОЕ сообщение об ошибке и что действие НЕ произошло (заказ не создан), а не только «показалась какая-то ошибка». - Нет ассертов, проходящих всегда; тест краснеет при поломке поведения. ### 6. Доступность и визуал (если в проекте уже есть) - a11y-чек (axe-core / `@axe-core/playwright` / cypress-axe) на ключевых экранах, если такой инструмент уже подключён. - Visual regression / скриншот-снапшоты (`toHaveScreenshot`, Percy/Applitools), если в проекте уже настроены — не вводи новый инструмент без запроса. - Проверка состояний loading/error/empty, если применимо. ## EDGE CASES, КОТОРЫЕ ЧАСТО ПРОПУСКАЮТ - **Двойной сабмит**: быстрый двойной клик по «Оплатить»/«Отправить» — не создаётся ли дубль заказа; заблокирована ли кнопка на время запроса. - **Обновление/навигация посреди флоу**: F5 или «назад» в браузере на середине многошагового визарда — теряется ли прогресс, восстанавливается ли стейт. - **Потеря сети / медленная сеть**: запрос завис/упал в середине — показан ли корректный error state, можно ли повторить (эмулируй через offline/`cy.intercept` с forceNetworkError/route abort). - **Пустые и предельные данные**: пустой список/корзина, единственный элемент, очень длинная строка, спецсимволы и эмодзи в полях, вставка из буфера. - **Отмена действия**: закрытие модалки крестиком/Esc/кликом вне, «Отмена» в подтверждении удаления — состояние не должно измениться. - **Повтор операции**: повторная отправка той же формы, идемпотентность на UI-уровне (не задваивается ли сущность). - **Права и роли**: тот же экран под другой ролью — скрытые/задизейбленные элементы; прямой переход по URL на запрещённый экран (не только «кнопка скрыта»). - **Валидация на клиенте vs сервере**: обход клиентской валидации (ввод через DOM/вставку) — ловит ли сервер. - **Сохранение состояния формы**: незакоммиченные изменения при попытке уйти со страницы (диалог «покинуть страницу?»). - **Локаль/формат**: разделитель дробей, формат даты/валюты, RTL, если приложение мультиязычное. - **Таймзоны и «сегодня»**: тест, завязанный на текущую дату/время, ломается в полночь/в другой TZ CI — фиксируй время. - **Первый вход vs повторный**: онбординг/пустое состояние показывается один раз; тест на «повторный» флоу не должен зависеть от того, было ли уже пройдено. - **Флейки от гонки рендера**: ассерт до завершения анимации/подгрузки данных; жди стабилизации, а не фиксированное время. ## КРИТЕРИИ ГОТОВНОСТИ (Definition of Done) Набор считается готовым, только если: 1. Написан в конвенции существующего E2E-стека проекта (или согласованного, если стека не было). 2. Каждый спроектированный сценарий из шага 2 покрыт (happy + альтернативные + негативные + релевантные edge). 3. Архитектура: Page Object/fixtures, без дублирования, тесты изолированы и проходят в любом порядке. 4. **Прогон зелёный и стабильный** — приведён фактический вывод раннера; набор прогнан ≥2 раз без флейков. 5. Проверено, что ассерты не фиктивны (тест краснеет при поломке поведения). 6. Секреты/URL вынесены в env/конфиг, данные вычищаются. 7. Есть раздел «что не удалось автоматизировать и почему». ## ФОРМАТ РЕЗУЛЬТАТА 1. **Вердикт одной фразой**: набор готов и зелёный / готов с оговорками (часть сценариев не запустить из-за окружения) / не готов (почему). 2. **SCOPE**: покрытые экраны/флоу, выбранный E2E-стек (и почему), команда запуска приложения и раннера. 3. **Матрица сценариев**: таблица «сценарий → тип (happy/alt/neg/edge) → файл теста → статус (pass/fail/не запускался)». 4. **Созданные/изменённые файлы**: полные пути к тестам, page objects, fixtures, конфигам. 5. **Вывод фактического прогона**: команда, сводка passed/failed, время, подтверждение стабильности (повторный прогон). 6. **Что сделано для стабильности**: какие анти-flaky меры применены (локаторы, ожидания, изоляция данных). 7. **Что НЕ удалось автоматизировать и почему**: нет тестового окружения/ данных, требуется реальный платёжный шлюз, капча, ручная 2FA, недоступный внешний сервис — честно, чтобы пробел не читался как «покрыто». 8. **Рекомендации**: что добавить в CI, какие testid внести в код, какие предусловия автоматизировать через API. ## ЗАПУСК (практическая инструкция) 1. **Сам, в основном потоке**: выполни SCOPE (раздел выше) и Шаг 1 (определение стека) — это нельзя делегировать, субагент не видит контекст диалога и не знает, какой флоу и где запускать. Зафиксируй SCOPE и стек. 2. Спроектируй сценарии (Шаг 2) и архитектуру (Шаг 3) — тоже сам, это единое решение по всему набору. 3. **Написание**: если сценариев много и они независимы (разные флоу/экраны) и доступен Agent tool — можно распараллелить по группам: каждому субагенту передай конкретный флоу, выбранный стек и конвенцию, релевантные разделы этого скилла (чек-лист, edge cases, DoD), путь к общим page objects/ fixtures — субагент не видит сам файл скилла. Общие page objects/fixtures создай ДО распараллеливания, чтобы наборы их переиспользовали, а не дублировали. 4. **Запуск и починка** (Шаг 5) сведи в основном потоке: подними приложение один раз, прогони весь набор, чини падения, добейся стабильной зелени. Сохраняй тесты сразу в тестовую директорию проекта по его конвенции (`e2e/`, `tests/e2e/`, `cypress/e2e/`), page objects — рядом по конвенции. 5. Приведи фактический вывод прогона и заполни раздел «что не удалось автоматизировать». Артефакты — в тестовую директорию проекта по его конвенции; если своей структуры нет, заведи `e2e/` (или `tests/e2e/`) с подпапками `pages/`/`fixtures/`. Тест-план/матрицу сценариев, если нужен отдельный документ, клади в `docs/qa/test-plans/.md`. Это авторский скилл: код тестов пиши так, чтобы он реально проходил, был детерминированным и поддерживаемым — не «заглушки ради галочки». Правки в самом приложении (добавление testid и т.п.) допустимы, если это нужно для устойчивого теста; несоответствия реализации требованиям фиксируй как находки.