Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
SAST шукає weaknesses у code, DAST перевіряє running application ззовні, а SCA зіставляє third-party components із відомими vulnerabilities. Це доповнювальні techniques, а не взаємозамінні назви одного scanner-а.
Перехід у пентестинг: що важливо →Допомагає будувати career path від target role, tasks, knowledge і skills, а не від нечіткої назви certification.
Перехід у пентестинг: що важливо → Першоджерело ↗[Дивитися з 21:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1260s). Foundations — colors, typography, spacing, radii, shadows — і reusable components дають AI контекст для створення нових screens. Проте implementation може відійти від запланованого design: інший modal pattern, невідповідний alignment або duplicated component. Потрібні structural і visual checks, а не лише факт, що сторінка відкрилася.
Перший критерій — уміти прибрати повторювану ручну роботу за прийнятну ціну. Це може бути 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 самі по собі цих причин не пояснюють.
Gateway може бути зовнішньою обгорткою над одним або кількома services. Тому один квадрат на high-level diagram може приховувати власну базу, декілька внутрішніх services і нові integrations. Кожен із цих components можна «наблизити» і знову побачити нову архітектуру. На новому проєкті варто попросити lead або developer намалювати таку service map, а потім уточнювати data stores і взаємодії. Це безпосередньо впливає на test design: де готувати state, які контракти перевіряти і де локалізувати падіння.
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає `undefined`, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.
[Дивитися з 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.
У React Native частина компонентів доступна як native UI, частина може поводитися як web content, а для platform-specific можливостей додається Swift або Kotlin code. Крім Appium, для такого стеку згадується Detox. Якщо продукт значною мірою рендериться як web view, більшу частину логіки іноді дешевше перевіряти Playwright-тестами на web-рівні, залишивши кілька справжніх mobile flows для інсталяції, permissions і наскрізної інтеграції. Flutter сам рендерить значну частину UI, тому accessibility tree і поведінка елементів можуть відрізнятися від стандартних native components. Це не робить Flutter автоматично добрим чи поганим: потрібен окремий proof of concept на реальному застосунку, перш ніж обирати automation stack.
Для складних API-тесів недостатньо знати request syntax. Потрібно «занурюватися» у систему: знаходити природу помилки, відтворювати ланцюжок залежностей і розуміти, де закінчується контракт однієї частини і починається інша. Автор радить підтримувати живу діаграму у Figma або Miro: ліворуч — архітектура і зв’язки, праворуч — test baselines і шаблони перевірок для окремих components. Така карта покращує онбординг, локалізацію дефектів і планування покриття.
[Дивитися з 42:15](https://www.youtube.com/watch?v=crzGm6nzfbU&t=2535s). Без чіткого плану той самий prompt може щоразу змінювати різні files, selectors, components або classes, особливо у великій codebase. Тому спочатку фіксують місце й межі зміни, а реалізацію запускають у новому контексті вже за погодженим планом. Для професійного розвитку корисні не декларації про AI, а власні case studies: як було поставлено задачу, які gates захистили якість, що перевірено й які обмеження лишилися. Найпростіший спосіб отримати такий досвід — зробити невеликий власний інструмент, який розв'язує реальну особисту проблему.
Рекомендований порядок у класі: test data, самі tests, а потім допоміжні methods. Спершу можна залишати methods біля конкретного test class, побачити реальне дублювання й лише тоді ділити UI на Page Objects або components. `Boolean.parseBoolean` і `assertEquals(expected, actual)` показані як ще один приклад перетворення тексту з UI; практична задача — написати три-чотири читабельні tests, винести secrets у `.env` і потренувати IDE refactorings.
Playwright рекомендується як швидша й зручніша основа для UI automation, особливо на remote execution. У Java повторювану ініціалізацію можна прибрати через JUnit integration, Page Object-и та невелику application facade, а стабільність дій забезпечують auto-waiting і динамічні assertions. Для домашньої роботи потрібно переписати на Playwright наявний Selenium-сценарій, налаштувати browser options, увімкнути tracing, відкрити trace локально та використати `page.pause()` або recorder для налагодження. Згенеровані recorder-ом кроки слід переносити вибірково й узгоджувати locator strategy в межах команди. `getByRole` додатково перевіряє accessibility semantics сторінки: сучасні Angular і React components мають формувати ролі та ARIA attributes, які screen reader розпізнає як кнопку, поле введення чи інший control. Для колекцій strict locator semantics складніша, тому в більшості дій варто будувати locator, що знаходить один конкретний елемент.