Піраміда тестування: як побудувати стратегію автотестів

Команда автоматизувала 900 UI-тестів. Прогін займає дві години, щодня 20–40 тестів падають «просто так», а розробники звикли тиснути «Re-run». Знайомо? Це класичний антипатерн «ріжка з морозивом»: найбільше дорогих і повільних тестів нагорі, і майже нічого внизу.

Рівні піраміди

            /\
           /E2E\          мало: критичні сценарії користувача
          /------\
         / Інтегра-\      середньо: API, БД, черги, контракти
        /  ційні    \
       /--------------\
      /    Юніт-тести  \  багато: логіка функцій і класів
     /------------------\

Що нижче рівень — то точніше тест вказує на причину падіння. Упав юніт-тест calculate_discount — зрозуміло, де шукати. Упав E2E «оформлення замовлення» — причина може бути будь-де: фронтенд, бекенд, тестові дані, мережа.

Скільки тестів на якому рівні

Пропорції на кшталт «70/20/10» — орієнтир, а не закон. Краще правило:

Важливо

Перевіряйте кожну річ на найнижчому рівні, де її можна перевірити. E2E-тест не повинен перевіряти, що знижка 15% рахується правильно, — це робота юніт-тесту. E2E перевіряє, що користувач може оформити замовлення зі знижкою.

Приклад розподілу для фічі «промокоди»:

• Юніт: розрахунок знижки, прострочений код, мінімальна сума, поєднання з іншими акціями, округлення — 15–20 тестів.
• Інтеграційні: API /promo/apply повертає правильні коди помилок, промокод списується в БД після оплати, повторне використання заблоковане — 5–7 тестів.
• E2E: користувач вводить промокод у кошику і бачить нову суму; невалідний код показує помилку — 2 тести.

Контрактні тести — окремий рівень між сервісами

У мікросервісах інтеграційні тести «з усім реальним» дорогі. Контрактні тести перевіряють, що сервіс-постачальник відповідає саме так, як очікує споживач: структура, типи, обов'язкові поля. Ламаються вони рано — на етапі CI постачальника, а не на спільному стейджингу.

Ручне тестування нікуди не зникає

Автотести перевіряють відоме. Невідоме знаходить людина:

• дослідницьке тестування нових фіч з обмеженням у часі (наприклад, сесія 60 хвилин з місією «зламати оформлення замовлення через повернення назад у браузері»);
• юзабіліті, тексти, візуальні дрібниці;
• сценарії, які дорого автоматизувати і які рідко змінюються.

Ознаки здорової стратегії

• повний прогін для пул-реквесту займає до 10–15 хвилин;
• нестабільних тестів (flaky) — менше 1%, і кожен має власника та тікет;
• падіння тесту в 9 випадках з 10 означає реальну проблему;
• нова фіча не мерджиться без тестів на відповідному рівні — це частина code review.

Порада

Почніть з метрик: скільки триває прогін, скільки тестів перезапускають, скільки багів з продакшену могли б зловити тести і на якому рівні. Ці цифри переконують команду краще за будь-яку діаграму.

Як вибратися з «ріжка з морозивом»

1. Заморозьте ріст E2E: нові перевірки логіки — лише юніт та API.
2. Знайдіть дублі: E2E, що перевіряють розрахунки чи валідацію, переносьте на нижчі рівні.
3. Карантин для flaky-тестів: нестабільний тест не блокує пайплайн, але має тікет і дедлайн.
4. Залиште в E2E лише критичні шляхи: реєстрація, вхід, оплата, головний сценарій продукту.