AI trust boundary
Дозволена межа даних, providers і controls для AI workflow, визначена governance, privacy, security та contractual requirements організації.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Browser install треба повторювати після Playwright upgrade
У відео пояснено, що package version у requirements не гарантує наявність потрібного browser binary.
Актуальна документація підтверджує version-specific browser binaries і прямо зазначає, що після Playwright update може знадобитися повторний install CLI.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →CLI не скасовує policy та data risk
Не передавайте proprietary code, secrets, logs, customer data або PII зовнішньому AI provider без explicit approval і визначених controls. Спосіб запуску через CLI не змінює governance, privacy та contractual requirements.
Як працювати на спокійному проєкті та з нав’язаними оцінками →hash-checking mode
Режим pip --require-hashes, у якому requirements мають бути pinned і містити hashes для всіх прямих та транзитивних залежностей.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →NIST SSDF 1.2 ще draft
Відео описує Shift Left як ранню перевірку requirements і системних ризиків.
Станом на 2026-07-31 NIST SSDF 1.1 є final, а SP 800-218 Rev. 1, що відповідає SSDF 1.2, має draft status. Перед нормативним посиланням статус потрібно перевірити повторно.
2025-12-17
Vibe coding, склад команди та нова роль тестувальника →Secure installs | pip documentation
Фіксує безпечніші pip installs через pinned requirements, hashes і binary distributions.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки → Першоджерело ↗Three Amigos і справжня цінність Gherkin
BDD працює, коли product/business analyst, developer і tester разом розбирають examples, assumptions та edge cases до написання коду. У відео це описано як Three Amigos practice, до якої за потреби долучають інших ролей. `Given/When/Then` допомагає зафіксувати передумову, дію та очікувану behavior мовою, зрозумілою business і engineering. Цінність виникає під час розмови та static testing requirements, а не від самого факту, що текст збережено у `.feature` file.
Shift Left і експертиза як multiplier
[Дивитися з 36:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=2160s). Тестувальник може раніше перевіряти consistency requirements, contradictions, duplicated rules і missing states. Business analyst, designer, product owner, developer та QA працюють із тим самим problem context, але бачать різні ризики. Сильна domain expertise плюс AI skills підсилює команду; слабка expertise лише швидше масштабує неправильні рішення.
Починати з product pain, а не з tool
Перше питання — що саме болить: 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 марним.
`requirements.txt` і транзитивні залежності
Щоб проєкт можна було клонувати й запустити на іншій машині, його прямі залежності фіксують у конфігурації на кшталт `requirements.txt`. Бібліотеки самі залежать від інших пакетів — це транзитивні залежності. Повний freeze може додати до файлу весь граф пакетів. Автор радить не зберігати зайвий шум без потреби: достатньо явно вказати основні залежності, наприклад Playwright і pytest, а їхні сумісні внутрішні пакети підтягнуться автоматично. Жорстко фіксувати весь граф варто тоді, коли відтворюваність або конфлікти версій справді стали проблемою. Інакше довгий список складніше підтримувати й аналізувати.
`python-dotenv` і `load_dotenv()`
Сам файл `.env` не потрапляє в `os.environ` автоматично. Додається пакет `python-dotenv`, викликається `load_dotenv()`, після чого `os.getenv()` бачить локальні значення. Версію залежності фіксують у `requirements.txt`. Після зміни запускаються всі наявні тести. Їх успішне проходження підтверджує, що перенесення конфігурації не змінило поточну поведінку сценаріїв.
Що насправді потрібно продукту
Business зазвичай цікавить, чи можна продемонструвати й продати ключовий flow, чи стабільний продукт і чи не блокують bugs інвестиції або клієнтів. Формат внутрішньої документації другорядний, доки він допомагає команді передбачувано delivery-ити результат. Додаткові process artifacts стають виправданими, коли зменшують реальну проблему: часті incidents, втрату domain knowledge, складний onboarding або неоднозначні requirements. Сам по собі Gherkin не виправляє низьку якість implementation чи відсутність coverage.
Коміт залежностей і підсумок
Перед комітом перевіряється, що Faker має зафіксовану версію в `requirements.txt`, а всі тести проходять після переходу на dataclass і fixture. Повідомлення коміту описує обидві зміни: типізовану конфігурацію та генерацію тестових даних. Підсумковий стан: конфігурація незмінна й має явний тип, негативний сценарій використовує згенерований пароль, а логін виконується fixture лише там, де потрібен. Це зменшує дублювання без передчасного переходу до складнішої архітектури.
Налаштування редактора та `requirements.txt`
У PyCharm можна ввімкнути CamelHumps/Camel Words, щоб навігація й виділення працювали за частинами `snake_case` та інших складених імен. Для відтворення середовища на іншому комп’ютері або CI версії залежностей фіксуються у `requirements.txt`: ```bash pip freeze > requirements.txt pip install -r requirements.txt ``` `pip freeze` записує також транзитивні бібліотеки. Автор показує, що список можна звести до прямих залежностей із зафіксованими версіями, якщо команда свідомо підтримує такий формат.
Commit і підсумок практики
Перед комітом переглядаються видалені plugin parameters, custom fixtures, requirements і параметризовані cases. У підсумку кожна ітерація має читабельний ID, test data винесені з тіла сценарію, а browser reuse виконується через явний fixture graph. Практика після уроку — додати власні cases до таблиці, дати їм змістовні IDs, намалювати залежності fixtures і перевірити setup/teardown кожного scope. Окрема перевірка має довести, що попередня ітерація не залишає авторизацію або client-side state наступній.