Це приклад звіту Health Check. Звіт Quick Scan коротший: орієнтовна оцінка, топ-5 ризиків і швидкі покращення на основі конфігурації CI та звітів, без доказів на рівні файлів вихідного коду.
1. Підсумок
Простими словами. Набір тестів добре організований і покриває основні сценарії клієнтів. Найбільша проблема — збої залишаються непомітними: тести, що впали, автоматично перезапускаються, а звіт показує лише фінальний зелений результат. Білди виглядають здоровішими, ніж є, і команда перестає довіряти червоним білдам.
Що зробити спершу. Зробити повтори видимими й зберігати скріншоти та трейси при збоях (близько 1,5 години). Потім дати кожному паралельному worker-у власного тестового користувача й розділити пайплайн на паралельні завдання. Разом це має скоротити CI з 38 до приблизно 15 хвилин і прибрати більшість хибних тривог.
Що переглядали
| Параметр | Деталі |
|---|---|
| Репозиторій | northwind-e2e (вигаданий) |
| Тести | 412 усього: 318 UI та 94 API |
| Стек | Playwright, TypeScript |
| CI | GitHub Actions, один workflow (e2e.yml), 38 хвилин на запуск |
| Матеріали | Архів репозиторію та звіти 30 останніх запусків CI |
| Не перевіряли | Тести не запускалися. Production-код, безпека й продуктивність поза обсягом. |
2. Оцінка стану: 72 / 100
Рівень: працює, але з помітними ризиками. Шкала: 0–39 крихкий фундамент, 40–59 потрібне цільове покращення, 60–79 працює з помітними ризиками, 80–100 міцний фундамент. Кожна категорія нижче оцінена від 0 до 100 і має свою вагу.
| Категорія | Вага | Оцінка | Простими словами |
|---|---|---|---|
| Архітектура | 15% | 78 | Рівні тестів чітко розділені, спільні утиліти легко знайти. |
| Надійність тестів | 20% | 62 | Нестабільні збої трапляються часто й приховані повторами (F1, F2, F3). |
| Підтримуваність | 15% | 86 | Зрозумілі назви й невеликі page object-и. Найсильніша сторона. |
| Стратегія покриття | 15% | 76 | Вхід, оплата й рахунки покриті. Повернення коштів — ні (F6). |
| CI/CD | 15% | 70 | Працює, але повільно й запускає по одному тесту за раз (F4). |
| Звітність і спостережуваність | 10% | 66 | Збої не залишають скріншотів чи трейсів (F5). |
| Тестові дані й середовища | 10% | 66 | Багато тестів використовують один спільний акаунт (F3). |
| Загалом | 100% | 72 | Працює, але з помітними ризиками |
Як це складається: оцінка × вага, потім сума. 78×15% + 62×20% + 86×15% + 76×15% + 70×15% + 66×10% + 66×10% ≈ 72.
3. Як побудовані набір тестів і пайплайн
Набір тестів
Структура вдала, тому архітектура й підтримуваність мають високі оцінки.
tests/ui/містить 318 браузерних тестів, аtests/api/— 94 API-тести, тож два рівні чітко розділені.pages/містить невеликі page object-и, по одному на екран, без логіки тестів усередині.tests/fixtures/містить спільні налаштування, наприклад вхід. Саме звідси походить проблема спільного акаунта (F3).playwright.config.ts— єдине місце для налаштувань, але кількох значень для CI бракує (F1, F4, F5).
CI-пайплайн
Один workflow у GitHub Actions виконує всі 412 тестів в одному завданні й триває 38 хвилин. Він використовує один worker, перезапускає тести, що впали, двічі й не зберігає скріншотів чи трейсів (F1, F4, F5).
Ризик нестабільних тестів
Підтверджено: дев’ять тестів пройшли лише з повтору в останніх 30 запусках, і чотири з них конфліктують через спільний акаунт (F3). Не перевірено: решту п’ять. Їх потрібно відтворити локально з увімкненими трейсами.
4. Висновки
Шість висновків за пріоритетом. Для кожного показано, що ми побачили, чому це важливо, що робити, скільки це займе й що ви отримаєте.
| ID | Серйозність | Висновок | Зусилля |
|---|---|---|---|
| F1 | ВИСОКИЙ | Тести, що впали, автоматично перезапускаються, тому проблеми лишаються непомітними | Близько 1 години на кроки 1–2, потім 2–3 дні на крок 3 |
| F2 | СЕРЕДНІЙ | Фіксовані очікування сповільнюють тести й усе одно ламаються, коли застосунок повільний | 1–2 дні |
| F3 | СЕРЕДНІЙ | Усі тести входять в систему під одним акаунтом | Близько 1 дня |
| F4 | СЕРЕДНІЙ | Пайплайн виконує все в одному завданні на 38 хвилин | Близько 1 дня |
| F5 | НИЗЬКИЙ | Збої не залишають скріншотів чи трейсів | Близько 30 хвилин |
| F6 | СЕРЕДНІЙ | Повернення коштів і зниження тарифу не мають автоматичних перевірок | Близько 2 днів |
Тести, що впали, автоматично перезапускаються, тому проблеми лишаються непомітними
- Що ми побачили
playwright.config.ts:14встановлюєretries: 2для кожного тесту, а.github/workflows/e2e.yml:41публікує лише фінальний результат. У 23 із 30 останніх запусків принаймні один тест спочатку впав, а з повтору пройшов. Дев’ять тестів дають 81% таких повторів.- Чому це важливо
- Справжня помилка, що виникає не завжди, «позеленіє» й потрапить у реліз. Команда також не знає, які тести ненадійні, тому білди перезапускають за звичкою й збоям більше не довіряють.
- Що робити
- Показувати в підсумку CI тести, що пройшли з повтору, як «нестабільні» (flaky).
- Зменшити
retriesдо 1. - Виправити дев’ять найпроблемніших тестів, починаючи з найгірших.
- Зусилля
- Близько 1 години на кроки 1–2, потім 2–3 дні на крок 3
- Результат
- Нестабільні тести стають видимими й піддаються підрахунку, а частка повторів — числом, яке можна знижувати.
Фіксовані очікування сповільнюють тести й усе одно ламаються, коли застосунок повільний
- Що ми побачили
- 74 жорстко заданих паузи (
waitForTimeout) у 31 файлі. Наприклад,tests/checkout/payment.spec.ts:57завжди чекає 3 секунди. Разом вони додають близько 3 хвилин чистого очікування до кожного запуску. - Чому це важливо
- Якщо застосунок відповідає за 3,5 секунди, тест падає. Якщо за 0,5 секунди, тест усе одно чекає 3. Він одночасно повільний і ненадійний.
- Що робити
- Замінити кожну паузу очікуванням реальної умови, наприклад
await expect(page.getByText('Payment received')).toBeVisible(). Почати з 10 файлів, де паузи трапляються найчастіше. - Зусилля
- 1–2 дні
- Результат
- Швидші запуски й менше збоїв через таймінги.
Усі тести входять в систему під одним акаунтом
- Що ми побачили
tests/fixtures/auth.ts:12авторизує кожен тест як[email protected], і 41 тест створює рахунки під ним. Чотири з дев’яти нестабільних тестів падають лише тоді, коли два з них виконуються одночасно.- Чому це важливо
- Тести заважають один одному при паралельному запуску. Окремий перезапуск одного тесту дає інший результат, ніж у повному прогоні, тому налагодження відбувається повільно.
- Що робити
- Створювати нового користувача для кожного паралельного worker-а через API й видаляти його дані наприкінці запуску.
- Зусилля
- Близько 1 дня
- Результат
- Усуває конфлікти, що стоять за приблизно 4 з 9 нестабільних тестів, і робить паралельні запуски безпечними, що потрібно для F4.
Пайплайн виконує все в одному завданні на 38 хвилин
- Що ми побачили
e2e.ymlмає одне завдання.playwright.config.ts:19задаєworkers: 1у CI, а браузери завантажуються заново під час кожного запуску (близько 4 хвилин).- Чому це важливо
- Розробники чекають 38 хвилин, щоб дізнатися, чи безпечна зміна, тому об’єднують зміни або перестають чекати на результат.
- Що робити
- Розділити тести на 4 паралельні завдання через
--shard, кешувати браузери Playwright і піднятиworkersдо 2, коли буде виправлено F3. - Зусилля
- Близько 1 дня
- Результат
- Час CI зменшується з приблизно 38 до приблизно 15 хвилин.
Збої не залишають скріншотів чи трейсів
- Що ми побачили
playwright.config.ts:22–23задаєtrace: 'off'іscreenshot: 'off', а workflow не завантажує теку зі звітом.- Чому це важливо
- Щоб зрозуміти збій, інженер має відтворити його локально, а це часто займає більше часу, ніж виправлення. Серйозність низька, але виправлення дуже дешеве.
- Що робити
- Задати
trace: 'on-first-retry'іscreenshot: 'only-on-failure'та завантажуватиplaywright-report/як артефакт CI зі строком зберігання 14 днів. - Зусилля
- Близько 30 хвилин
- Результат
- Кожен збій можна відкрити й зрозуміти за кілька хвилин.
Повернення коштів і зниження тарифу не мають автоматичних перевірок
- Що ми побачили
- 412 тестів покривають вхід, оплату й рахунки, але жоден не перевіряє повернення коштів чи зміну тарифу. Обидві функції пов’язані з грошима.
- Чому це важливо
- Помилки тут коштують грошей і довіри клієнтів, а ручне тестування перед кожним релізом легко пропустити.
- Що робити
- Спершу додати API-тести, бо вони дешевші й стабільніші за UI-тести: повне повернення, часткове повернення та зниження тарифу під час продовження. Пізніше додати по одній UI-перевірці на сценарій.
- Зусилля
- Близько 2 днів
- Результат
- Найризикованіші сценарії захищені під час кожного релізу.
5. Швидкі покращення
Дії з низьким ризиком, які команда може завершити за один день.
| Дія | Час | Користь |
|---|---|---|
| Зберігати скріншоти й трейси при збої та завантажувати звіт (F5) | 30 хв | Кожен збій можна діагностувати без локального перезапуску. |
| Показувати в підсумку CI тести, що пройшли з повтору (F1) | 1 година | Прихована нестабільність стає видимим списком. |
| Кешувати браузери Playwright у CI (F4) | 20 хв | Економить близько 4 хвилин на запуск. |
| Прибрати 10 найдовших фіксованих очікувань (F2) | 2 години | Приблизно на хвилину швидше й менше збоїв через таймінги. |
6. План на 30 днів
Що робити й коли, щоб робота вписувалася в звичайну розробку.
| Коли | Що | Результат |
|---|---|---|
| Зараз (тиждень 1) | Чотири швидкі покращення, потім зменшити retries до 1 (F1, F5, F4, F2) | Збої видимі й легко діагностуються. |
| Далі (тижні 2–3) | Тестові користувачі для кожного worker-а (F3), 4 паралельні завдання (F4), початок виправлення дев’яти нестабільних тестів (F1) | CI близько 15 хвилин і значно менше хибних збоїв. |
| Пізніше (тиждень 4) | Замінити решту фіксованих очікувань (F2), додати API-тести повернення коштів і зниження тарифу (F6) | Швидший, стабільніший набір тестів і захищені сценарії з грошима. |
Чого очікувати через 30 днів
| Показник | До | Ціль |
|---|---|---|
| Час запуску CI | 38 хвилин | близько 15 хвилин |
| Запуски з прихованим повтором | 23 з 30 | менше 5 з 30 |
| Збої зі скріншотом чи трейсом | 0% | 100% |
Це цілі для вигаданого прикладу. Реальні звіти містять оцінки на основі ваших матеріалів, а не гарантії.
Що далі
Ваша команда сама вирішує, що впроваджувати. Виправлення не входять у Health Check. Якщо потрібна допомога, Audit + Fix Sprint охоплює до 10 годин виправлень у вигляді pull request-ів: запросити пропозицію.
Як читати оцінку
Зважена оцінка — внутрішня методика, а не галузевий стандарт, сертифікація чи гарантія якості ПЗ. У реальному звіті кожен висновок спирається на докази з ваших матеріалів.
Замовити Health Check · 17 499 грн → Замовити Quick Scan · 7 499 грн