Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.

Python мануфактураJavaDesign Patterns для автоматизаторів

Терміни, нюанси та джерела

Що змінилося після запису · 5:00

Selenium Manager

У відео Selenium Manager описано як автоматичний механізм, через який webdriver.Chrome() отримує потрібний driver без ручного шляху.

Станом на 2026-07-31 офіційна документація описує Selenium Manager як fallback, коли driver не передано або не знайдено. Він постачається з bindings від Selenium 4.6, підтримує керування браузерами від 4.11 і досі позначений як Beta.

Selenium 4.6 для bundled driver management; Selenium 4.11 для automated browser management

1. Selenium початок, основи, фікстури →

Що змінилося після запису · 0:00

Що змінилося після запису

Workflow у відео окремо налаштовує uv і Python.

Поточний setup-uv може встановити Python через uv, тому actions/setup-python не є обов’язковим. Окремий setup-python може залишатися виправданим через runner tool cache.

setup-uv v9.0.0 перевірено 2026-07-31; точну дату появи Python management у цьому brief не встановлено.

2. Практика та написання пайплану CI/CD →

Практика · 4:09

Порівняти management і technical role

Порівняйте не titles, а десять типових weekly activities обох ролей.
Позначте activities, які дають energy, нейтральні або системно виснажують.
Оберіть один спосіб перевірити preferred role без irreversible звільнення.
Activity-based comparison і один reversible career experiment.

Перехід із менеджменту в технічну роль і sabbatical →

Python мануфактура · Сесії: AMA та PMP · 4:35–8:20

Чому automation без test strategy не робить інженера senior

Уміння писати код саме по собі не означає middle або senior automation-рівень. Потрібні test strategy, impact analysis, risk management, test planning і вміння обрати правильний рівень перевірки. ШІ спрощує написання коду, але не вирішує за інженера, що варто автоматизувати і який feedback справді потрібен команді. Частину сценаріїв краще перевіряє автоматизація: великі масиви даних, інсталяції, API та повторювані комбінації. Інші властивості — usability, анімації, адаптивність і візуальна якість — часто потребують людської оцінки. Сильна роль поєднує обидва способи роботи.

Як manual QA перейти в automation →

Python мануфактура · Сесії: AMA та PMP · 10:02–12:20

Приклад таблиці: 96 хвилин проти 120 секунд

У прикладі suite для account management містить 12 тестів. Один ручний кейс у середньому займає 8 хвилин, отже повний ручний прогін — 96 хвилин. Автотест виконує кожен кейс приблизно за 10 секунд, а весь suite — за 120 секунд. Таблиця має зберігати щонайменше: - назву test suite або user journey; - кількість автоматизованих кейсів; - середній час ручного кейсу та всього suite; - середній час автоматизованого кейсу та всього suite; - кількість запусків за обраний період; - розраховану дельту часу. Кейси потрібно явно переводити з manual backlog до automation coverage. Інакше легко одночасно рахувати той самий обсяг як ручну та автоматизовану роботу.

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

Python мануфактура · Сесії: AMA та PMP · 16:20–19:49

Застарілі версії створюють операційний ризик

Чим довше не оновлювати ключовий runtime або framework, тим більше вразливостей і несумісностей накопичується. Критичний exploit тоді змушує виконувати велику міграцію терміново, коли команда має найменше часу на безпечну перевірку. Навіть сумісний на рівні компіляції upgrade може змінити memory management, connection pooling або роботу з Kafka й базою даних. Тому після оновлення потрібні не лише unit-тести, а й інтеграційні та, для критичних систем, нефункціональні перевірки. Підсумкова рекомендація відео — підтримувати залежності в актуальному стані планомірно й заохочувати до цього всю команду.

Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →

Python мануфактура · Сесії: AMA та PMP · 0:00–3:10

Базова планка: автоматизувати свою рутину

Перший критерій — уміти прибрати повторювану ручну роботу за прийнятну ціну. Це може бути Playwright, Cypress, Selenium, code generation або невеликий script будь-якою мовою. Важливіше отримати перевірюваний результат і feedback від сильнішого інженера, ніж одразу будувати «ідеальний framework». Глибоке знання мови стає потрібним, коли дефекти виникають на стиках: type conversion, concurrent requests, race conditions, database/file persistence, memory management, asynchronous behavior або lifecycle components. UI steps самі по собі цих причин не пояснюють.

Який рівень програмування потрібен automation engineer →

Python мануфактура · Сесії: AMA та PMP · 4:09–7:02

Технічна й управлінська робота вимагають різного хисту

Робота з людьми може бути хаотичною й емоційно складною; глибока технічна робота дає інший тип задоволення. Немає універсально вищої ролі — важливо чесно визначити, який характер задач підходить саме зараз. Корисно пробувати різні професійні ролі й хобі та дізнаватися про труднощі designer, developer, DevOps і manager. Навіть якщо роль не стане основною, цей досвід покращує співпрацю й допомагає розуміти мотиви інших учасників команди.

Перехід із менеджменту в технічну роль і sabbatical →

Python мануфактура · Сесії: AMA та PMP · 6:55–10:20

Ринкова цінність навичок без культу overperformance

[Дивитися з 06:55](https://www.youtube.com/watch?v=reaHS8_pZbU&t=415s). Автор очікує, що на майбутніх співбесідах питатимуть не лише про prompts, а й про context management, перевірку output, open-source tools, code analysis та integration AI у development workflow. Повна відмова від таких інструментів на поточному client може залишити прогалину в досвіді, тому навички варто розвивати на дозволених або власних матеріалах. Для досвідченого інженера постійний overperformance не гарантує стабільності роботи: layoffs можуть бути наслідком budget, product strategy, regulation, зміни пріоритетів або перерозподілу resources. Рекомендована альтернатива — передбачуваний sustainable pace. Новачку тимчасово потрібна більша інвестиція часу для навчання, але це не має перетворюватися на норму для всієї кар’єри.

Як працювати на спокійному проєкті та з нав’язаними оцінками →

Python мануфактура · Сесії: AMA та PMP · 9:10–12:45

CVE, dependencies і patching

Відомі вразливості реєструються в загальнодоступних базах та ідентифікуються, зокрема, через CVE. Scanners зіставляють dependency versions із такими записами й повідомляють, що конкретна library або її transitive dependency потребує оновлення. Patching не завжди дорівнює зміні номера version. Якщо vulnerable API змінено або видалено, команді доводиться оновити dependency і переписати код, який спирався на небезпечну behavior. Security engineer має пояснити не лише «scanner червоний», а шлях експлуатації, реальний impact і безпечний upgrade path.

Перехід у пентестинг: що важливо →

Python мануфактура · Сесії: AMA та PMP · 9:30–15:25

Антипатерн: Cucumber живе тільки в automation

Типовий невдалий варіант: manual test cases уже містять steps, але автоматизатор повторно перекладає їх у Gherkin, а потім створює step definitions. Одна дія існує як feature text, regex/parameterized step і code implementation. Різні автори формулюють однакові steps по-різному, тому повторне використання швидко руйнується. Management може вимагати кількість automated scenarios або «читабельний для business report», але потім не відкривати ці reports. У такій ситуації Cucumber не забезпечує BDD: він лише додає maintenance cost команді automation. Ознака справжнього BDD — scenarios використовуються для спільних рішень, а не лежать наприкінці pipeline.

Чому критикують BDD і Cucumber →

Python мануфактура · Сесії: AMA та PMP · 14:25–19:20

Що робити, коли задачі оцінили без команди

[Дивитися з 14:25](https://www.youtube.com/watch?v=reaHS8_pZbU&t=865s). Якщо estimate нав’язано ззовні, команда не повинна регулярно рятувати його unpaid overtime: тоді management бачить лише формально виконаний plan і не отримує evidence, що estimation process зламаний. Потрібно фіксувати фактичний effort, невідомі залежності, скорочений testing scope та carry-over, а на retrospective вимагати участі виконавців в оцінюванні. Сильніша позиція виникає, коли кілька інженерів незалежно описують ту саму проблему фактами. Спочатку питання піднімають із tech lead/engineering lead, потім — на retro або з manager, якщо прямий канал не працює. Повідомлення має бути не «ми не хочемо встигати», а «за такого scope й available capacity безпечний результат потребує X; до deadline можемо завершити Y, решту переносимо або свідомо приймаємо перелічені ризики». У відео також звучить ідея зробити недооцінку видимою через накопичення нестабільних tests і technical debt. Навмисно ламати quality gate не варто: це створює product risk і послаблює аргументацію команди. Правильний еквівалент — не приховувати незавершену роботу, явно документувати deferred checks/debt, не позначати неперевірене як done і вимагати product decision про scope, deadline або quality.

Як працювати на спокійному проєкті та з нав’язаними оцінками →

Python мануфактура · Сесії: AMA та PMP · 18:57–21:24

Чи реальні 8 хвилин проти 10 секунд

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

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