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

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

Практика · 22:13

Negative tests для даних і доступу

Спроєктуй negative tests для читання чужого row, підміни owner claim, вставки row поза дозволеним scope та запиту на erasure з legal-retention exception. Відокрем authentication evidence, database authorization і data-lifecycle decision.
Набір cases показує, який шар відхиляє кожну дію та який audit evidence потрібен.

Прихована складність бекенд-тестування →

Практика · 14:00

Підготувати розмову про внутрішній перехід

Опишіть automation-ціль на шість місяців без прив’язки до нового title.
Додайте очікуваний coverage, потрібний час і спосіб вимірювання користі.
Запишіть критерій, за якого внутрішній перехід вважається заблокованим і починається зовнішній пошук.
Чернетка PDP proposal та явний decision threshold.

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

Нюанс

Це не медична діагностика

Відео й LessonDocument допомагають структурувати career decision, але не діагностують mental health condition. Якщо виснаження тривале або суттєво впливає на функціонування, потрібна індивідуальна професійна консультація, а не лише зміна title чи відпустка.

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

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

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

Урок описує Java-based Allure CLI flow, характерний для Allure 2.

Станом на 2026-07-31 існує Allure 3, який встановлюється через npm і потребує Node.js. Migration guide заявляє сумісність з official framework integrations, але перехід генератора є окремим migration decision.

Allure 3 migration documentation перевірено 2026-07-31.

4. Allure репорт, основи та інтеграція в CI →

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 · 24:19–26:41

Внутрішній перехід чи нова компанія

Шанс внутрішнього переходу залежить не стільки від типу компанії, скільки від зрілості конкретного promotion process, competency matrix і менеджера. У поточній компанії легше знайти корисний automation scope, бо вже відомі система й контакти; водночас саме там можуть бути найжорсткіші уявлення про старий грейд. Фінальна рекомендація: спочатку перевірити можливість прозорої внутрішньої домовленості. Якщо компанія визнає automation як upskilling — залишатися простіше. Якщо вимагає необґрунтованого downgrade — набрати доказовий досвід на поточному продукті й шукати зовнішній перехід.

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

Python мануфактура · Програма курсу · 25:00–29:46

WebDriver BiDi та критерії вибору

WebDriver BiDi додає двосторонні події й команди до WebDriver ecosystem: console/network events, більш оперативний browser state та можливості, для яких односпрямованого command-response API недостатньо. У відео технологія описується як така, що ще потребує узгодження версій Selenium, browser і driver та не має однакової зрілості у всіх language bindings. Фінальне порівняння: Playwright — менше ручних waits, багаті debugging artifacts і швидкий workflow для сучасних engines; Selenium — ширша browser/vendor compatibility, але більше інфраструктурних і synchronization витрат. Вибір робиться від support matrix, geography, потрібних protocols і вартості maintenance, а не від загальної популярності інструмента. Практичний default для курсу — Playwright. Selenium варто додавати лише тоді, коли конкретний browser або remote provider є перевіреною вимогою, яку Playwright suite не закриває.

3. Selenium vs Playwright - яка різниця →
Запитати в чаті про «decision» →