QA1 · Шпаргалка: тест зі сценарію, навмисний дефект, healer, Stryker

У кожній функції — усе для завдання: правила і сценарії, один «порожній» тест і дві зміни для L2.

src/features/NN-назва/
├── rules.ts            # правила функції — не змінювати
└── page.ts             # поля сторінки — не змінювати
materials/features/NN-назва/
├── scenarios.md        # правила і сценарії — джерело правди
├── ui-change.json      # L2: зміна інтерфейсу
└── behaviour-change.json  # L2: зміна поведінки
e2e/features/NN-назва.spec.ts   # один наявний тест

Агент, якого попросили «напиши тест на сторінку», подивиться, що сторінка показує, і запише це як очікуване. Якщо на сторінці дефект — тест його закріпить. Тому очікуване значення — зі scenarios.md, а розбіжність зі сторінкою — знахідка для звіту.

.claude/agents/ і .mcp.json — командні налаштування: їх комітять разом із тестами. Описи агентів — звичайні markdown-файли з інструкціями, модель у них — sonnet.

.claude/agents/
├── playwright-test-planner.md
├── playwright-test-generator.md
└── playwright-test-healer.md
.mcp.json          # cmd /c npx playwright run-test-mcp-server (Windows)
specs/README.md    # сюди planner пише плани
e2e/seed.spec.ts   # уже є — з фіксованою датою «сьогодні»

У проєкті QA1 MCP-сервер агентів запускає власну копію застосунку на порту 4174 (playwright.config.ts). Тому npx playwright test у терміналі працює паралельно з агентом і не падає з «порт зайнятий».

Planner → план: збігається зі сценаріями, межі є? Generator → тест: що перевіряє кожен expect і звідки очікуване? Healer → змінений тест: що він змінив і чому? Без цих трьох перевірок ви отримуєте зелені тести, а не перевірені.

Локатори за роллю, підписом і test id; одна дія — один крок; перевірка — конкретний результат.

test.describe('NN · Назва', () => {
  test.beforeEach(async ({ page }) => { /* як у наявному тесті */ });

  test('S2 · над межею …', async ({ page }) => {
    await page.getByLabel('Підпис поля').fill('…');
    await page.getByRole('button', { name: 'Назва кнопки' }).click();
    await expect(page.getByTestId('result-lines')).toContainText('…');
  });
});

result — блок, який є завжди (у нього вставляється і картка, і помилка). result-card — картка результату, result-title — її заголовок, result-lines — рядки з числами, result-error — текст помилки. «Картки немає» — expect(page.getByTestId('result-card')).toHaveCount(0).

Так: правило вашого варіанту; одна зміна, як помилка розробника; видно на сторінці; ви знаєте, який тест його ловить. Ні: ламає збірку чи всю сторінку (впаде будь-який тест — нічого не доводить); зміна, якої не видно (перейменована змінна, коментар); дефект під тест, який уже є; зміна чужої функції чи form-page.ts.

Дефект «зсув межі» ловить точка з того боку, куди зсунули. У демо межу 5 кг зсунули до 6: тест «на межі» 5 кг лишився зеленим, упав тест 5,2 кг. Тому для межі — під, на і над. Розбір — demo.html#demo3-defect.

Змінилась реалізація (підпис поля, текст кнопки, розмітка), поведінка за scenarios.md та сама — лагодь локатор чи крок, очікуване не чіпай. Змінилась очікувана поведінка (число, межа, текст правила) — стоп: «сценарій каже X, сторінка показує Y» → дефект чи нова вимога? Вирішує власник продукту чи аналітик, не тест і не агент.

Відкрийте .claude/agents/playwright-test-healer.md: виправляти локатори, перевірки й очікувані значення; питань не ставити — «зробити найрозумніше, щоб тест пройшов»; безнадійний тест — test.fixme(). Для зміни підпису кнопки це ідеально, для зміни поведінки — ризик закріпити дефект.

Healer на зміні поведінки запускали тричі (Sonnet): з правилами проєкту, із запобіжником і без правил. Усі три рази він не змінив очікуване значення: показав 80 проти 82 і спитав. Інша модель, інший агент чи довга сесія можуть поводитися інакше — тому правило записують явно. Записи — demo.html#demo2-behaviour.

1 — toBeVisible() на блоці, який є завжди. 2 — заголовок картки замість числа. 3 — перевірка власного вводу. 4 — очікуване «що показала сторінка»: падає, коли дефект виправлять, і зелений, поки дефект живе.

Не зараховується: зниження порогу в stryker.config.mjs, // Stryker disable, .skip, тест, що повторює обчислення з коду, очікуване з виводу функції. Чесно: очікуване зі scenarios.md, кожна межа — під, на і над, точний текст помилки, живий мутант — тест або пояснення.

killed — тест упав; survived — усі тести зелені; no coverage — жоден тест не виконує рядок. Mutation score = (вбиті + timeout) / (вбиті + timeout + живі + без покриття). Compile error у бал не входить. Повний npm run mutation не потрібен: функції інших варіантів без тестів.

Одна перевірка: передумова, кроки, очікуваний результат. В автотесті — один test('…'), напр. «S2 · 5,2 кг по області — 80 грн».

Що перевіряємо — мовою користувача, без кліків. З одного сценарію — кілька тест-кейсів: S2 → 4,9 · 5 · 5,2 кг. У QA1 — S1–S5 у scenarios.md.

Тести, які запускають разом: файл *.spec.ts, усі e2e через npm run e2e; група всередині файлу — test.describe.

Рядок, що валить тест, коли факт не збігається з очікуваним: expect(…).toContainText('До сплати: 80 грн'). Тест без суттєвих перевірок не має діагностичної цінності.

Джерело правильної відповіді. У QA1 — scenarios.md, а не те, що зараз показує сторінка: інакше тест закріплює дефект.

Фікстура — готове оточення до старту: { page } від Playwright (свої — через test.extend); підготовка — у beforeEach (hook); фіксована дата page.clock.setFixedTime — це stub. Тестові дані — посилки PARCELS для трекера.

Спосіб знайти елемент. getByRole, getByLabel — як бачить користувач; getByTestId — окрема мітка data-testid для тестів (стабільна, але користувач її не бачить). Усі три стійкіші за CSS-селектори.

Запуск набору і звіт: npx playwright test (або npm run e2e), звіт — npm run e2e:report, trace.

Підміна справжньої залежності. Stub (заглушка) — заготовлена відповідь (now: () => NOW, brokenApi, slowApi у src/app.test.ts). Fake — спрощена робоча версія (fakeApi шукає посилку в PARCELS). Mock — дублер, у якого перевіряють взаємодію: expect(fn).toHaveBeenCalledWith(…). Spy (шпигун) — записує виклики: vi.spyOn(obj, 'm') обгортає справжню функцію, vi.fn() — порожня функція-записувач. Mock і spy у QA1 не використовуються.

То зелений, то червоний без змін у коді: залежить від часу, порядку тестів, мережі, waitForTimeout. Лікують причину, а не повторами: у QA1 дата фіксована, а локально retries: 0.

Хибнопозитивний результат — тест червоний, а дефекту немає (зламаний локатор, flaky). Хибнонегативний — тест зелений, а дефект є (тест A з toBeVisible()). Не плутати з позитивним тестом — тестом на валідних даних.

Внизу багато швидких юніт- (модульних) і компонентних (UI) тестів, вище — менше інтеграційних і API, вгорі — мало e2e і ручних. Кожну перевірку роблять на найнижчому рівні, де вона можлива.

Антипатерн — перевернута піраміда: багато ручних і e2e, мало юніт. Регресія повільна й дорога, багато хибних тривог, червоний тест не каже, де дефект. Термін — Alister Scott (2012).

Масштаб того, що тестуємо: юніт (модульне), компонентний (UI-компонент або сторінка; не плутати з ISTQB component testing = юніт), інтеграційний (контрактний), системний (e2e), приймальний (UAT).

Мета перевірки: функціональне, нефункціональне (швидкодія, доступність, безпека, зручність), пов'язане зі змінами (підтверджувальне, регресійне). Будь-який тип можна робити на будь-якому рівні.

Як спроєктовано тест, а не його рівень. Чорна — за поведінкою і scenarios.md (e2e, ручне, юніт-тест за сценарієм). Біла — за кодом (гілки rules.ts, живі мутанти Stryker). Сіра — знаєте код, тестуєте ззовні: форма робить Number(…) у form-page.ts, тож пробуєте 1e1 і 0x10 через сторінку.

Smoke — швидко, широко й неглибоко: застосунок узагалі працює (11 тестів «розрахунок працює» в e2e/features, по одному на функцію). Sanity — вузько й глибше: конкретна зміна чи виправлення після збірки. У глосарії ISTQB sanity — синонім smoke; у командах їх зазвичай розрізняють так.

Разом — тестування, пов'язане зі змінами. Підтверджувальне — виправлений дефект справді виправлено. Регресія — зміна не зламала решту: npm test і npm run e2e після кожної зміни. На QA2 це робить CI автоматично.

Значення, які програма обробляє однаково, утворюють один клас; на клас — один представник. Для 00: вага ≤ 0, (0; 5], (5; 30], > 30, не число; маршрути місто, область, Україна. «Не число» відсікає форма (form-page.ts), тож цей клас — для компонентного чи e2e-тесту.

Точки на межі й поруч з обох боків: 4,99 · 5 · 5,01; 30 · 30,01; 0 · 0,01. Тут живуть дефекти «на одиницю»: < замість <=, 5 замість 6.

Таблиця рішень — коли результат залежить від комбінації умов (маршрут × вага → ціна). Переходи станів — коли поведінка залежить від стану (Створена → … → Отримана); рівні покриття — кожен стан, кожен допустимий перехід, недопустимі переходи.

Покриття (npm run coverage, лише тести Vitest) — які рядки виконались: юніт-тест deliveryCost(2, 'місто'), що перевіряє лише ok, виконує розрахунок і не помітить зміну ціни. Mutation score — частка виявлених мутантів: (вбиті + timeout) / (вбиті + timeout + живі + без покриття); compile error не рахується.

Вносимо відомий дефект у код (defects/*.json: знайти → замінити), проганяємо тести й повертаємо код. Тест, що лишився зеленим, цей дефект не бачить. У QA1 — npm run defects:check.