Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Чинний installation flow JetBrains описує один PyCharm product із core features та Pro features, а не окремі Community і Professional installers. Рекомендація використовувати Toolbox App залишається актуальною.
1. Налаштування PyCharm, JetBrains Toolbox, створення проєкту та структура проектів →Поточна документація Playwright прямо застерігає, що універсального стану «page loaded» немає: після browser load application може ще отримувати дані або завершувати hydration. Якщо видимий control не реагує, спочатку перевір hydration; product-side виправлення — тримати control disabled до готовності, а не додавати sleep у тест.
Що має описувати isLoaded →@pytest.mark.parametrize створює окремий test invocation для кожного набору аргументів; stacked decorators утворюють Cartesian product, а не automatic pairwise selection.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Коли робота відрізняється від очікувань, Developers і Product Owner переглядають scope Sprint Backlog, не руйнуючи Sprint Goal.
Як працювати на спокійному проєкті та з нав’язаними оцінками →У Scrum Guide відповідальність за sizing несуть Developers, які виконуватимуть роботу; Product Owner допомагає зрозуміти trade-offs, але не підміняє їхню оцінку.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Увімкни Slow 3G у DevTools, одразу взаємодій із видимим control і перевір, чи handler уже підключений. Якщо дія губиться, зафіксуй product-side умову готовності без sleep у тесті.
Проблему відтворено або виключено на сповільненій мережі.
Відокремлено browser load, видимість control і завершення hydration.
Запропоновано disabled state до готовності, якщо handler підключається пізніше.
Перше питання — що саме болить: release speed, regressions, platform drift, backend instability, device coverage чи migration. Далі з’ясовують product architecture, team ownership, roadmap і engineering maturity. Інструмент обирається після цього. Наприклад, планована migration з native на cross-platform або навпаки змінює test seams і робить speculative framework марним.
`LoginPage.login(email, password)` ховає locators і послідовність fill/click за дією користувача. Великий product page можна розкласти на логічні components, наприклад product card або related products, якщо вони мають власну поведінку. Page Object не повинен ставати контейнером усієї test logic.
[Дивитися з 08:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=480s). Досвідчений engineer із точним plan може реалізувати frontend, backend і частину deployment pipeline, використовуючи готову design system та API contract. Frontend має знати, який resource і endpoint запросити; backend — який response повернути; shared components і design tokens дають повторюваний UI. AI допомагає заповнити реалізацію, але не визначає самостійно правильні boundaries і product behavior.
[Дивитися з 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.
[Дивитися з 39:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=2340s). AI збільшує кількість solo-built products і release frequency, але коротший development cycle не гарантує довше product lifetime: слабка consistency, regressions і недостатня перевірка знижують довіру users. Практичний висновок для учасників — опановувати automation та AI не заради постійно більшого workload, а щоб виконувати роботу ефективніше, накопичувати перевірений досвід і лишатися корисними при зміні проєкту чи ринку.
Credentials, product, company чи іншу сутність не варто фіксувати безпосередньо в тілі всіх тестів: один екземпляр не дає варіативності й приховує проблеми з іншими значеннями. Faker або власний generator має враховувати domain constraints і boundary values, а кожен run — по можливості створювати інший валідний набір. Детермінований seed можна залишити для відтворення падіння.
Flutter і React Native дозволяють розвивати iOS та Android з однієї основної codebase, а native-модулі підключати для Bluetooth, geolocation, notifications чи інших можливостей системи. Це прискорює MVP, але native-застосунки на Swift і Kotlin зазвичай мають менше проміжних шарів і працюють швидше. Навіть у cross-platform продукті команди часто розділяються за iOS/Android або за product streams. Тестувальнику потрібно розуміти специфіку кожної платформи, а не вважати однакову codebase гарантією однакової поведінки.
Playwright підтримує тривалий двосторонній канал із browser process і через browser-specific protocol передає команди click, fill, navigation та читання стану. Locator actions мають auto-waiting: перед дією Playwright перевіряє релевантні actionability conditions — наприклад, видимість, стабільність, можливість отримати events і editable state. Це дозволяє тесту формулювати намір «виконай click для цього locator», а orchestration layer бере на себе очікування готовності елемента в межах timeout. Auto-waiting не усуває потребу в assertion: після дії все одно треба перевірити очікуваний результат. Основні browser engines Playwright — Chromium, Firefox і WebKit. WebKit наближає поведінку Safari, але не є повною копією всіх Safari/macOS/iOS інтеграцій. Branded Chrome або Edge можуть запускатися як Chromium channels, проте повну browser matrix потрібно визначати з реальної product analytics і support policy.
Створення або читання сутності через API проходить routing, application logic, database access і serialization, тому сотні setup-запитів накопичують час. Прямий запит до database інколи виконується за кілька мілісекунд і може бути корисним для підготовки або пошуку test data. У Java типовим низькорівневим контрактом є JDBC; у Python — драйвер конкретної СУБД, який зазвичай підтримує Python DB-API. Для підключення потрібні host/URL, database/schema, credentials і driver. Секрети не мають бути в коді, а тестовий користувач БД повинен мати мінімальні права. Прямий insert не завжди еквівалентний product operation: він може обійти validation, events, audit, caches та синхронізацію. Тому DB setup доречний лише для сутностей, де команда явно приймає такий контракт.
Окремий generator може повертати не одне поле, а цілісний `User`, `Company` або `Product` з усіма значеннями, які тест перевірятиме далі. Частина полів випадкова, частина належить до обмеженого набору, частина приймається як parameter. Такий обʼєкт є очікуваною моделлю даних сценарію; окремі actions використовують його для onboarding, create або update через API чи UI.