Звітність, метрики, observability

Звіт, який допомагає знайти причину

Звіт має відповідати на три питання: що впало, чому і чи падало раніше. Список зелених і червоних тестів - це мінімум, а не ціль.

Що має бути у звіті для кожного падіння:

• Повідомлення assertion і стек.
• Trace Playwright: кроки, DOM-знімки, мережеві запити, консоль.
• Скріншот і відео (за потреби, бо займають місце).
• Correlation id запитів, щоб знайти логи бекенду.
• Середовище, версія збірки, номер шарда.

Рівні звітності:

1. HTML-звіт Playwright - для інженера, що розбирає падіння.
2. Історія і тренди (Allure або власна БД результатів) - для пошуку flaky і повільних тестів.
3. Нотифікація в чат - коротко: скільки впало, посилання на звіт, хто автор коміту.
4. Дашборд для команди і менеджменту - стабільність, час пайплайна, тренд.

Помилка, яку часто бачу: нотифікація на кожне падіння в загальний канал. Через тиждень канал усі ігнорують. Краще відправляти автору PR або власнику області, а в загальний канал - тільки падіння на main.

Окремо зберігайте сирі результати (JSON або JUnit XML). Тоді можна будувати свою аналітику без прив'язки до одного інструменту звітів.

Метрики тест-системи

Те, що не вимірюється, не покращується. Ось метрики, які я б показав на дашборді.

Чому p95, а не середнє. Середній час 10 хвилин може ховати те, що кожен п'ятий прогін триває 25 хвилин через повільний шард. Розробники відчувають саме хвіст.

Escaped defects - найчесніша метрика якості. Аналізуйте кожен баг з проду: чи міг його зловити тест, на якому рівні, чому не зловив. Це дає конкретні дії, а не абстрактне "збільшити покриття".

Обережно з покриттям коду. Високе покриття не гарантує якісних перевірок. Тест без змістовних assertions теж дає покриття. Для e2e корисніше покриття бізнес-сценаріїв або ризиків: чи покриті всі способи оплати, валюти, статуси переказу.

Observability і тестування

Observability - це здатність зрозуміти стан системи за її зовнішніми сигналами: логи, метрики, трейси. Для QA це спосіб знайти причину падіння в розподіленій системі, а не тільки у браузері.

Correlation id (або trace id) - ідентифікатор, який проходить через усі сервіси в межах одного запиту. Тест може передавати власний заголовок, а потім за ним знайти логи в усіх сервісах.

test('transfer completes', async ({ request }, testInfo) => {
  const corrId = `e2e-${testInfo.testId}-${Date.now()}`;
  const res = await request.post('/api/transfers', {
    headers: { 'X-Correlation-Id': corrId },
    data: { from: 'acc_1', to: 'acc_2', amount: 30 },
  });
  testInfo.annotations.push({ type: 'correlationId', description: corrId });
  expect(res.status()).toBe(201);
});

Назва заголовка залежить від проєкту: це може бути X-Request-Id або стандартний traceparent з W3C Trace Context.

Як ще QA використовує observability:

• Перевіряє не тільки відповідь API, а й що подія потрапила в чергу і в аудит-лог.
• Після деплою дивиться на метрики помилок і латентності як частину релізної перевірки.
• Synthetic monitoring - невеликий набір сценаріїв, які регулярно ходять у прод (наприклад, логін і перегляд балансу на тестовому акаунті) і алертять при падінні.