Як упровадити автоматизацію мануальному QA та довести її ефективність

Автоматизація окуповується через повторні запуски. Для кожного сценарію потрібно оцінити час ручного виконання та час автоматизованого прогону. Розробка автотесту — окрема інвестиція, але кожен наступний запуск уже створює вимірювану економію.

Базова формула для одного запуску:

```text
економія = час ручного прогону − час автоматизованого прогону
```

Для періоду:

```text
сукупна економія = економія одного запуску × кількість запусків
```

Якщо історичні test runs неякісні — наприклад, частину кейсів відмічали пройденими після поверхневої перевірки, — не варто видавати їх за точні дані. Можна почати з експертної оцінки середнього часу, явно позначивши її як наближену, а надалі збирати чистішу статистику.

def saved_minutes(manual_minutes: float, automated_seconds: float, runs: int) -> float:
    return (manual_minutes * 60 - automated_seconds) * runs / 60

assert saved_minutes(96, 120, 150) == 14_100

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

Автотест можна уявити як шлях у графі: кроки — це вузли, а різні переходи утворюють гілки. Після покриття найдовшого маршруту коротші сценарії часто повторно використовують уже реалізовані вузли. Це робить наступні тести дешевшими.

Для кожного test suite варто зафіксувати кількість кейсів, середній ручний час і час автоматизованого прогону. Наприклад, якщо checkout вручну займає 20 хвилин, а автоматично — 30 секунд, дельта кожного запуску є наочною цінністю.

Другий сильний кандидат — перевірки, де одна послідовність кроків повторюється на великій кількості даних або проходить через кілька систем. Ручна перевірка переходів із глобальних систем продажу квитків чи банківського застосунку до сервісу перевізника може вимагати десятків людино-годин.

Так само добре автоматизуються комбінаторні перевірки: наприклад, показ або приховування UI-блоків для різних пар параметрів. Замість ручного повторення сценарій параметризується й запускається на наборі даних засобами Playwright або іншого test runner.

Критерій простий: чим одноманітніша ручна дія, більше наборів даних і частіше потрібен повторний прогін, тим вищий потенціал автоматизації.

Зекономлені години не перетворюються автоматично на прямий прибуток. Вони звільняють QA для інших задач і скорочують час до фідбеку: розробник раніше дізнається про проблему й швидше завершує зміну.

Повний бізнес-ефект краще вимірювати delivery-метриками: як змінилася швидкість проходження тікета до production, скільки цінності доставлено і чи покращився результат для користувача. Але для локального доказу цінності автоматизації достатньо чесно показати кількість запусків та зекономлений час.

У прикладі suite для account management містить 12 тестів. Один ручний кейс у середньому займає 8 хвилин, отже повний ручний прогін — 96 хвилин. Автотест виконує кожен кейс приблизно за 10 секунд, а весь suite — за 120 секунд.

Таблиця має зберігати щонайменше:

- назву test suite або user journey;
- кількість автоматизованих кейсів;
- середній час ручного кейсу та всього suite;
- середній час автоматизованого кейсу та всього suite;
- кількість запусків за обраний період;
- розраховану дельту часу.

Кейси потрібно явно переводити з manual backlog до automation coverage. Інакше легко одночасно рахувати той самий обсяг як ручну та автоматизовану роботу.

На початку витрати на розробку переважають, але регулярні локальні й CI-запуски поступово наздоганяють інвестицію. За кілька місяців команда може показати, скільки умовних робочих годин замінили повторні прогони.

Водночас менеджмент може спитати, куди пішов звільнений час. Відповідь має бути предметною: ранній аналіз фіч, швидший фідбек, shift left, observability, робота з документацією, ризиками або іншими quality activities. Автоматизація створює можливість робити цю роботу, але не гарантує її сама по собі.

Ефект AI-інструментів можна оцінювати тією ж моделлю на рівні окремої активності. Якщо якісний тест-план за шаблоном вручну займав близько чотирьох годин, а з AI — 30 хвилин, різницю множать на кількість створених тест-планів.

Так можна вимірювати підготовку тест-кейсів, баг-репортів, коментарів, тікетів та інших повторюваних артефактів. Важливо не підміняти цим загальну delivery-метрику: локальна економія показує ефективність конкретної операції, а не автоматично доводить прискорення всього SDLC.

Рекомендована послідовність для мануального QA:

1. Написати сирий наскрізний сценарій і навчитися синтаксису Playwright та test runner.
2. Винести повтори у функції.
3. Перейти до класів, Page Object та доречних патернів.
4. Оптимізувати підготовку стану й окремі кроки через API.
5. Додати параметризовані й комбінаторні сценарії.
6. Поступово покривати інші пріоритетні test suites.

Перші три місяці можуть дати лише кілька десятків тестів, але кожен із них запускається багато разів локально й у CI. Саме повторюваність створює економію, навіть якщо підтримка нестабільних падінь усе ще потребує уваги.

У Q&A уточнюється, що наведені числа взято з реального suite, а не вигадано для презентації. У ручному account-management сценарії потрібно зареєструвати користувача, змінити роль і перевірити результат; найдовші кейси займають близько 20 хвилин, коротші — близько п’яти, а середнє становить приблизно вісім.

Автоматизований тест скорочується до приблизно 10 секунд завдяки підготовці користувача через API, збереженій авторизації або прямій підстановці токена та переходу одразу до потрібної сторінки. Це результат поетапної оптимізації, а не швидкість першої сирої UI-версії.

Метрики просять не на кожному проєкті. Проте від middle або senior-спеціаліста часто очікують не лише код, а й зрозумілий документ із пріоритетами, прогресом і числовим поясненням користі.

Мінімальна сторінка зі списком пріоритетних suites, ручним та автоматизованим часом і кількістю запусків уже дозволяє відповісти, що саме зроблено. Це не «метрика заради метрики», якщо її дані відповідають реальному процесу.

Статистику краще почати збирати до зміни менеджменту або появи вимоги «тепер усе рахуємо». Зріла команда використовує метрики, щоб дослідити проблему, оцінити експеримент або зрозуміти, чи нові практики справді покращують delivery та задоволеність користувачів.

Потрібно чесно пояснювати межі: автоматизація може не прискорити delivery одразу через технічний борг, слабку testability або архітектурні проблеми. Але таблиця з часом і запусками показує локальний ефект і створює базу для ширшої розмови про процес.

Практичний висновок сесії: навіть проста, регулярно оновлювана модель робить внесок QA видимим і демонструє зрілий підхід до автоматизації.