Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Smoke і regression jobs передають reports/results через artifacts.
upload-artifact v4+ створює immutable artifacts: кілька jobs не можуть дописувати один artifact з однаковим name. Smoke і regression outputs потребують унікальних names і явного merge у publish job.
upload-artifact v4; перевірено за GitHub Docs 2026-07-31.
2. Практика та написання пайплану CI/CD →Ранній сигнал про вплив змін на якість і regression. Automation може скоротити повторювану ручну роботу, але потребує ресурсів на створення й підтримку та не скасовує manual testing з погляду користувача.
Як manual QA перейти в automation →Оберіть одну DTO з проєкту.
Для кожного field зафіксуйте source entity/service, mapping rule, nullability, required status, serializer behavior і regression test.
Додайте один gateway header, який має пройти до внутрішнього service.
Mapping table і один перевірений routing contract.
Візьміть один feature flow і перевірте його через frontend, API та persistence boundaries. Зафіксуйте contract для time fields, кількість backend/provider calls, authorization states і system-level regression risks.
Короткий risk-based review із конкретними evidence та переліком перевірок, яких бракує.
Ручне очищення cookies і local storage не дорівнює новому BrowserContext. Якщо reuse справді потрібен після вимірювання, fixture повинна мати явний contract стану й окрему regression check на leakage.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Виберіть один повторюваний manual regression scenario на поточному проєкті.
Зафіксуйте ручну тривалість, частоту запуску, ризик і доступні test seams.
Сформулюйте мінімальну automation-версію та критерій, за яким вона окупилася.
Один короткий candidate brief із baseline time, scope, ризиком і вимірним очікуваним feedback improvement.
Test job повторює підготовку середовища, встановлює Chromium для Playwright і запускає pytest з відповідними markers. Smoke, regression, API та UI перевірки повинні мати явні набори запуску; в міру зростання проєкту їх краще рознести по окремих workflow, якщо вони мають різні triggers, dependencies або час виконання. Markers треба переглядати як продуктову класифікацію, а не разове маркування: smoke suite має залишатися малим і відповідати на питання, чи застосунок узагалі придатний до глибшої перевірки. Regression містить ширше покриття й не повинен блокувати ранній feedback від smoke.
[Дивитися з 08:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=480s). YOY навмисно лишається живим продуктом із evolving behavior, щоб учні бачили не стерильні приклади, а неоднозначні UI states, responsive issues, calendars, images, links, QR та chat/network mode. Помічену неточність не варто автоматично списувати на «специфіку»: вона може розростися в regression. Питання про робочі проєкти треба анонімізувати — прибирати domains, secrets, персональні дані та інші identifiers зі screenshot, HTML або endpoint fragment.
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
[Дивитися з 24:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1440s). AI скорочує час написання feature, але developer витрачає дедалі більше часу на ручне підтвердження, regression і перевірку side effects. Навіть автор із досвідом architecture та automation пропускає defects після багатьох iterations. Тому композиція «один developer + один tester» може бути економічно й операційно сильнішою, ніж developer, який сам генерує, review-ить і повністю тестує весь продукт.
У спрощеній моделі Playwright спочатку запускає browser process, потім створює ізольований `BrowserContext`, а в ньому — одну або кілька `Page`. Launch options стосуються процесу браузера, context options — сесії користувача, cookies, permissions та емуляції, а `Page` представляє вкладку й виконує дії зі сторінкою. Через `channel="chrome"` можна запустити встановлений branded Chrome замість bundled Chromium. Це потрібно, коли поведінка залежить від повного браузера або медіакодеків; для більшості перевірок швидшого bundled Chromium достатньо. Маркери дають змогу виконувати `smoke` і `regression` окремо. Практичний CI flow: спочатку короткий smoke suite перевіряє, що середовище придатне до тестування, і лише після нього запускається довша regression suite.
Завантажений trace відкривається через Playwright Trace Viewer. Демонстрація виявляє, що hover-стан поводиться інакше на headless CI runner, а сторінка може зберігати неочікуваний authorization state. Тимчасовий fix перевіряється повним smoke-командним запуском, але нез’ясована причина shared state прямо залишається окремою проблемою, а не оголошується остаточно виправленою. Smoke suite має падати рано й зупиняти беззмістовний regression run, якщо застосунок не завантажився або критичний flow зламаний. Якщо smoke зелений, а regression масово червоний, критерії smoke треба переглянути.
У `pytest.ini` задаються каталоги з тестами, шаблони імен тестових файлів і функцій та директорії, які не потрібно сканувати. Це звужує test discovery до структури проєкту й прибирає зайву роботу з `.git`, `.idea`, build-артефактами та кешами. Через `addopts` виносяться параметри, які мають застосовуватися до кожного запуску: verbose output, короткий traceback, відображення output лише для failed tests, strict markers, Playwright tracing і генерація self-contained HTML report. Маркери `smoke`, `regression`, `web` та `slow` реєструються явно, щоб помилка в назві не перетворилася на тихе пропускання потрібної групи. Для traces обирається `retain-on-failure`: артефакт створюється під час тесту, але зберігається лише після падіння. Це практичніший default, ніж trace для кожного успішного тесту, бо архіви можуть швидко зайняти багато місця.
CLI встановлюється як системний інструмент, а `allure-pytest` додається до Python dependencies. Pytest налаштовується зберігати машинні результати в `allure-results`; цю директорію не комітять. Smoke і regression jobs завантажують свої `allure-results` як artifacts. Publish job завантажує їх, встановлює сумісну версію Allure CLI та виконує `allure generate`. Старі Playwright HTML artifacts можна прибрати, якщо Allure справді стає єдиним report і не втрачає потрібної діагностики. Версії CLI, Python binding і pytest adapter мають залишатися сумісними. Їх не слід незалежно оновлювати без pipeline verification, бо format results і генератор розвиваються окремо.
CLI економніше за довгу MCP-взаємодію для короткої перевірки. Але якщо дію треба повторювати — regression check, bug verification або scraping — краще один раз згенерувати й зберегти script. Агент, який щоразу імпровізує новий набір CLI-команд, створює різну поведінку й ускладнює debugging.
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає `undefined`, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.