Setting up CI
Показує first-party end-to-end CI sequence для checkout, Python, dependencies, browsers, pytest і trace artifact.
2. Практика та написання пайплану CI/CD → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Вибрати правильний test seam для persistence
Для одного business flow перелічіть validation, events, audit і data transformations між API та database.
Визначте, які properties доводить unit, integration та end-to-end test.
Якщо direct DB setup залишається, задайте connection ownership, transaction boundary і cleanup для parallel workers.
Test matrix без дублювання framework behavior і з явним direct-DB ceiling.
Матриця перевірок OTP
Для одного OTP flow випиши окремі cases для carrier/країни, TTL, delivery latency, fraud, rate limit, shared IP, billing, test bypass і live end-to-end перевірки. Для кожного case назви потрібний test environment та очікуваний доказ.
Матриця не змішує simulated provider contract із реальною доставкою та показує, де потрібен контрольований live test.
Намалювати test-aware service map
Вибрати один user flow і намалювати client, gateway, services, databases і brokers.
Позначити synchronous і asynchronous contracts, state setup і failure boundaries.
Для кожної boundary записати одну contract check і одну end-to-end check.
Одна діаграма, за якою видно, де готувати data і як локалізувати test failure.
Не прибирайте trace fallback завчасно
У демонстрації Allure report не показав очікуваний інтерактивний Playwright trace. Зберігайте окремий trace artifact, доки конкретна інтеграція не пройшла end-to-end verification у вашому стеку.
4. Allure репорт, основи та інтеграція в CI →Доменні межі, кілька застосунків і один стартовий repository
Великий продукт може мати B2C, B2B, back office, tool-sharing або branch-office застосунки зі спільним core. Структуру automation варто повторювати за реальними domain/app boundaries, а common-код піднімати лише тоді, коли він справді спільний. Для нового automation effort рекомендовано починати з одного repository: розділити усталену систему пізніше простіше, ніж одразу координувати кілька репозиторіїв без перевіреної потреби. Один repository також полегшує справжні end-to-end flows через кілька доменів.
Спочатку стабільність, потім оптимізація
Початковий end-to-end тест має бути стабільним. Лише після цього його можна декомпозувати або переносити частину перевірок на нижчі рівні заради швидкості. `isLoaded` підтримує стабільність двома способами: фіксує видимий користувацький стан і рано зупиняє сценарій із зрозумілою помилкою, якщо сторінка не готова.
Системний рівень і реальний стан проєктів
На системному рівні перевіряється вже розгорнута система. Тут корисно розділяти UI-сценарії користувача й перевірки системних компонентів або API, що формують дані для інтерфейсу. На багатьох реальних проєктах нижні рівні покриті нерівномірно або майже відсутні. Тому QA не може просто виходити з ідеальної піраміди: потрібен шар перевірок, який дає впевненість у поведінці всієї системи на тестовому оточенні.
Community flow і перші boundary cases
[Дивитися з 01:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=90s). Початковий end-to-end flow: створити user, створити community, перевірити її сторінку та редагування. Уже тут видно реальні edge cases: auto-generated URL під час створення не обов’язково поводиться так само під час edit, mobile-first layout відрізняється на desktop, а payment merchant потребує окремого test configuration і не має використовувати production credentials.
Починати з найдовшого критичного user journey
Першим кандидатом є довгий наскрізний P0-сценарій: checkout, реєстрація, основний бізнес-флоу тощо. Він швидко проходить через найбільшу кількість сторінок, API та станів, тож одночасно знайомить автора тестів із широкою частиною продукту. Автотест можна уявити як шлях у графі: кроки — це вузли, а різні переходи утворюють гілки. Після покриття найдовшого маршруту коротші сценарії часто повторно використовують уже реалізовані вузли. Це робить наступні тести дешевшими. Для кожного test suite варто зафіксувати кількість кейсів, середній ручний час і час автоматизованого прогону. Наприклад, якщо checkout вручну займає 20 хвилин, а автоматично — 30 секунд, дельта кожного запуску є наочною цінністю.
Окремі `storageState` і suites для кожного контексту
Fixture може завантажувати заздалегідь підготовлений Playwright `storageState` з потрібними cookies та `companyId`. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії. Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.
Перехід як upskilling, а не обнулення грейду
Manual QA вже знає домен, продукт, архітектурні межі та командні процеси. Ці знання не зникають після появи коду, тому перехід на automation не повинен автоматично означати downgrade до junior. Це розширення набору інструментів для тих самих інженерних задач. Практична домовленість може мати горизонт близько пів року: обрати дорогі end-to-end або data-heavy перевірки, автоматизувати їх і показати вимірний результат — швидший feedback та зекономлений ручний час. Досягнення такої цілі є аргументом для підвищення, а не для зниження зарплати.
SMS, OTP, billing, fraud і rate limits
[Дивитися з 11:05](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=665s). SMS-провайдер на кшталт Twilio приховує різні carrier contracts, billing і правила блокування. Успішний тест на одному українському префіксі не доводить доставлення через Vodafone чи оператора іншої країни: окремі ranges можуть бути заблоковані через fraud. Атака на authorization endpoint може витратити платний SMS-бюджет або спричинити блокування application, тому потрібні rate limits на правильному рівні. Водночас надто грубе обмеження за IP заблокує весь офіс або тестове середовище. OTP із TTL одна хвилина функціонально непридатний у країні, де SMS приходить за дві хвилини. Для автоматизації часто потрібні test numbers або контрольований bypass, але вони не замінюють окремої end-to-end перевірки реального каналу.
Test trophy і правильний розподіл перевірок
У відео test trophy протиставляється механічній testing pyramid: в основі quality gates лежать static analysis і security checks, далі — швидкі unit tests, ширший шар integration tests і невелика кількість end-to-end scenarios. Ідея — інвестувати в той рівень, де система має найбільший ризик і де перевірка дає швидкий надійний сигнал. Важливе уточнення: не слід зменшувати unit coverage лише тому, що продукт використовує Spring, Django або готову database. Не потрібно тестувати код framework; потрібно unit-тестувати власну чисту domain logic, а integration tests залишити для mappings, transactions, SQL, serialization та зовнішніх contracts.
Завдання: повний API-ланцюжок
Домашнє завдання — створити suite у вибраному project, отримати його через API і перевірити результат. Потім той самий підхід застосовується до test case: потрібно реалізувати `TestController`, request model, response model і перевірку створеної сутності. Базові HTTP-методи, headers, error handling і logging перевикористовуються з `BaseController`. Якщо documentation schema неповна, спершу виконується реальний request, а його JSON response перетворюється на початкову `Pydantic`-модель. Помилки validation у цьому процесі допомагають поступово відтворити фактичний контракт.