Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Не маскувати недооцінку — не означає навмисно ламати tests або quality gates. Фіксуйте deferred checks, carry-over і risk, не позначайте неперевірене як done та вимагайте явного рішення про scope, deadline або quality.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Для одного test suite зафіксуйте кількість кейсів, ручний та автоматизований час, кількість запусків і дельту. Окремо запишіть, на які quality activities пішов звільнений час.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Опишіть available capacity і підтверджені unknowns.
Сформулюйте, що безпечно завершити до deadline.
Запропонуйте явний вибір: зменшити scope, змінити deadline або прийняти перелічені quality risks.
Одне коротке повідомлення без звинувачень і без обіцянки прихованого overtime.
Знання test design, ризиків, вимог, bug reporting, Agile і тестової стратегії залишаються частиною роботи automation engineer. Quality assurance описується не як відповідальність однієї ролі, а як командний процес; автоматизація допомагає зробити його feedback loop швидшим. Якщо компанія підтримує розвиток, перехід варто зробити видимим: погодити цілі, потрібний час, очікуваний coverage і критерії перегляду ролі. Це краще за невизначене «я трохи пишу автотести», бо дає обом сторонам спостережуваний результат.
[Дивитися з 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.
[Дивитися з 21:47](https://www.youtube.com/watch?v=crzGm6nzfbU&t=1307s). Одна-дві людини з агентами можуть швидко створити alpha або beta й навіть працювати з великою enterprise codebase, якщо моделі мають достатній контекст. Але продуктивність має спиратися на quality gates: CI/CD, tests, performance checks, review іншими агентами та явні артефакти. Якщо команда не читає код і результати test runs, за пів року чи рік накопичуються зміни, які важко підтримувати, масштабувати й діагностувати. Тоді знову потрібні інженери з глибокими знаннями architecture, backend, PostgreSQL, messaging та конкретного domain.
Перед commit треба переглянути кожен changed file і переконатися, що до нього потрапили лише навмисні зміни. Commit message коротко описує зміст. IDE може запустити reformat code, optimize imports і code analysis; ці перевірки допомагають знайти технічні проблеми, але не замінюють ручного diff review.
Плагін, що аналізує всю сторінку, швидко створює десятки локаторів і методів. У демонстрації результат надмірний: зайві imports, асинхронний API, складні обгортки та невдалі перевірки на кшталт `is_element_visible`. Статична перевірка видимості дає гіршу діагностику й не використовує автоматичне очікування Playwright. Для тесту краще залишати дії простими, а очікуваний стан виражати через `expect`. Велика кількість автоматично згенерованого коду збільшує обсяг підтримки, не гарантуючи стабільності.
На початку витрати на розробку переважають, але регулярні локальні й CI-запуски поступово наздоганяють інвестицію. За кілька місяців команда може показати, скільки умовних робочих годин замінили повторні прогони. Водночас менеджмент може спитати, куди пішов звільнений час. Відповідь має бути предметною: ранній аналіз фіч, швидший фідбек, shift left, observability, робота з документацією, ризиками або іншими quality activities. Автоматизація створює можливість робити цю роботу, але не гарантує її сама по собі.
Твердження «код генерується з тестами, тому тестування потрібно менше» не витримує практичної перевірки. Більший обсяг змін збільшує простір можливих помилок, а зростання кодової бази поступово ускладнює кожну наступну фічу. Рекомендована позиція QA: приймати AI-інструменти й самим використовувати їх, але зберігати поділ відповідальності. Розробники забезпечують комбінаторне покриття ближче до коду, QA перевіряє інтегровану систему, інфраструктуру та користувацькі ризики. Автор окремо фіксує потребу знайти дослідження про довгостроковий вплив ШІ на швидкість розробки. Отже, тезу про повернення продуктивності до плато слід сприймати як практичне спостереження, яке потребує підтвердження даними, а не як уже наведений у відео доказ.
У відео 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.
Business зазвичай цікавить, чи можна продемонструвати й продати ключовий flow, чи стабільний продукт і чи не блокують bugs інвестиції або клієнтів. Формат внутрішньої документації другорядний, доки він допомагає команді передбачувано delivery-ити результат. Додаткові process artifacts стають виправданими, коли зменшують реальну проблему: часті incidents, втрату domain knowledge, складний onboarding або неоднозначні requirements. Сам по собі Gherkin не виправляє низьку якість implementation чи відсутність coverage.
[Дивитися з 16:40](https://www.youtube.com/watch?v=crzGm6nzfbU&t=1000s). Для агента задаються hard stops: не починати реалізацію без погодженої архітектури, acceptance criteria чи approval. Це уповільнює миттєве «вайбкодіння», але зменшує випадкові зміни. На прикладі YOY описано working slice зі спільнотами, подіями, tickets та кількома способами authentication, який має документацію, automated tests і однакові локальні та CI checks. Окремо підкреслено практичний ризик: агент може не проіндексувати або не закомітити всі файли, тому CI повинен перевіряти чистий checkout. Надійніший цикл — спершу research і точний план змін, потім окрема implementation session, targeted tests і broader checks.