Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Ранній сигнал про вплив змін на якість і regression. Automation може скоротити повторювану ручну роботу, але потребує ресурсів на створення й підтримку та не скасовує manual testing з погляду користувача.
Як manual QA перейти в automation →Оберіть одну DTO з проєкту.
Для кожного field зафіксуйте source entity/service, mapping rule, nullability, required status, serializer behavior і regression test.
Додайте один gateway header, який має пройти до внутрішнього service.
Mapping table і один перевірений routing contract.
Візьміть один feature flow і перевірте його через frontend, API та persistence boundaries. Зафіксуйте contract для time fields, кількість backend/provider calls, authorization states і system-level regression risks.
Короткий risk-based review із конкретними evidence та переліком перевірок, яких бракує.
Виберіть один повторюваний manual regression scenario на поточному проєкті.
Зафіксуйте ручну тривалість, частоту запуску, ризик і доступні test seams.
Сформулюйте мінімальну automation-версію та критерій, за яким вона окупилася.
Один короткий candidate brief із baseline time, scope, ризиком і вимірним очікуваним feedback improvement.
[Дивитися з 08:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=480s). YOY навмисно лишається живим продуктом із evolving behavior, щоб учні бачили не стерильні приклади, а неоднозначні UI states, responsive issues, calendars, images, links, QR та chat/network mode. Помічену неточність не варто автоматично списувати на «специфіку»: вона може розростися в regression. Питання про робочі проєкти треба анонімізувати — прибирати domains, secrets, персональні дані та інші identifiers зі screenshot, HTML або endpoint fragment.
[Дивитися з 24:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1440s). AI скорочує час написання feature, але developer витрачає дедалі більше часу на ручне підтвердження, regression і перевірку side effects. Навіть автор із досвідом architecture та automation пропускає defects після багатьох iterations. Тому композиція «один developer + один tester» може бути економічно й операційно сильнішою, ніж developer, який сам генерує, review-ить і повністю тестує весь продукт.
CLI економніше за довгу MCP-взаємодію для короткої перевірки. Але якщо дію треба повторювати — regression check, bug verification або scraping — краще один раз згенерувати й зберегти script. Агент, який щоразу імпровізує новий набір CLI-команд, створює різну поведінку й ускладнює debugging.
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає `undefined`, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.
Системні тести дають сигнал не лише про бізнес-логіку. Вони можуть виявити, що health check бекенду зелений, але UI не працює через gateway, неправильну конфігурацію або несумісні версії фронтенду й бекенду. Це окремий клас ризику, який unit- та інтеграційні тести не закривають. AI-інструмент може прискорити написання регресійних тестів і фідбек розробникам, але цей ефект не обов’язково зростає нескінченно. У великому продукті підтримка наявного коду та впровадження нових змін із часом знову стають складнішими. Одна з причин — недетермінованість LLM: той самий запит у новому чаті може дати інший код. Команда мусить перевіряти результат, стабілізувати робочі інструкції та не плутати швидку генерацію з гарантованою коректністю.
Під час декомпозиції логіку, яка раніше жила в одному або кількох класах, переносять у різні services. Треба не лише перенести записи, а й зберегти правила зіставлення полів та джерела кожного значення. Показано типовий регресійний ланцюжок: `fullName` випадково мапиться лише з `lastName`; локальний fix додає `name`, але дані все одно не оновлюються, бо справжнім джерелом був інший service. Так само похідний `status` може формуватися з timestamps лише на одному code path і залишитися `null` під час читання.
Оновлення framework, runtime, бази даних або Kafka може майже не змінити бізнес-код, але все одно є повноцінним релізом. Такі зміни повинні регулярно проходити перевірки, бо бібліотеки накопичують відомі вразливості. Статичні dependency scanners знаходять відомі проблеми за назвою й версією прямої або транзитивної залежності. Реакція може полягати в upgrade, заміні пакета або, як останній варіант, відмові від нього.
[Дивитися з 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, а не лише факт, що сторінка відкрилася.
[Дивитися з 28:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1680s). QA має помічати, коли після змін конкретного contributor-а різко збільшується кількість defects або regression effort. Це не привід для особистої атаки, а measurable signal: planning, self-review або verification недостатні. Feedback краще передавати через узгоджений management channel із прикладами impact. Незалежно від AI, engineer зобов’язаний перевіряти власну роботу; перекладання всієї відповідальності на QA є слабкою engineering culture.
Під час міграції можна правильно перенести service, але помилитися в gateway route: не прокинути authorization header, body або інший обов’язковий параметр. Клієнт передасть credentials, gateway прийме request, а внутрішній service поверне `401`, бо потрібний header загубився між ними. API tests швидко виявляють такі дефекти mapping, schema й routing без довгого пошуку причини через UI. Практична стратегія сесії: окремо перевіряти контракт ресурсу, окремо — ключові business flows, а під час database чи infrastructure migration запускати обидва набори як regression coverage.