Пошук · Мануфактура

Python мануфактура Java Design Patterns для автоматизаторів

Java · Сесії: AMA та PMP · 3:30–6:00

Незалежні тести, test design і участь у плануванні

Тести мають бути незалежними за даними та станом. Залежна послідовність інколи може з'явитися як швидка перша ітерація, але це технічний борг: окремий тест не можна надійно повторити, а suite важче паралелити й діагностувати. Automation engineer не звільняється від базових QA-навичок: decomposition, impact analysis, risk assessment і test-design techniques. Межа між manual та automation розмивається, але повний перехід лише в один тип роботи атрофує іншу частину навичок. Участь на ранній фазі refinement допомагає заздалегідь визначити testability та потрібний рівень покриття.

Що має вміти та знати мідл автоматизатор →

Java · Сесії: AMA та PMP · 4:54–7:28

Розробники генерують тести за допомогою ШІ

Використання Codex, Claude Code або Cursor для генерації unit- та інтеграційних тестів — правильний напрям, але сам інструмент не гарантує якісного покриття. Його треба адаптувати до шаблонів проєкту, а розробникам усе одно потрібні техніки тест-дизайну та розуміння ризиків. QA може допомогти команді сформулювати комбінації, граничні випадки й очікувану поведінку. Розробники закривають детальні перевірки ближче до коду, а тестувальник зосереджується на системній поведінці та ризиках, які не видно з окремої функції. Швидша генерація коду означає також більше коду для перевірки й подальшої підтримки. Тому збільшення швидкості розробки не є аргументом для автоматичного скорочення тестування.

Піраміда тестування, чому не API спочатку та як жити з упровадженням ШІ →

Java · Advanced: API-автоматизація · 5:00–10:00

Моноліт, мікросервіси і розподіл відповідальності

У моноліті UI, business logic, persistence і integrations можуть постачатися як один application. У microservice architecture users, products і orders можуть жити в окремих services і мати власні data stores. Дрібні services не гарантують простоти: зростають coupling, deployment overhead і складність пошуку failure. Тому test architecture має відображати фактичні service boundaries, а не ідеалізовану діаграму.

Теоретичний вступ до вебсервісів →

Java · Основний курс · 6:10–8:55

Gateway і вкладена архітектура

Gateway може бути зовнішньою обгорткою над одним або кількома services. Тому один квадрат на high-level diagram може приховувати власну базу, декілька внутрішніх services і нові integrations. Кожен із цих components можна «наблизити» і знову побачити нову архітектуру. На новому проєкті варто попросити lead або developer намалювати таку service map, а потім уточнювати data stores і взаємодії. Це безпосередньо впливає на test design: де готувати state, які контракти перевіряти і де локалізувати падіння.

Вступ до API-автоматизації →

Java · Сесії: AMA та PMP · 14:00–20:24

Automation як частина quality engineering

Знання test design, ризиків, вимог, bug reporting, Agile і тестової стратегії залишаються частиною роботи automation engineer. Quality assurance описується не як відповідальність однієї ролі, а як командний процес; автоматизація допомагає зробити його feedback loop швидшим. Якщо компанія підтримує розвиток, перехід варто зробити видимим: погодити цілі, потрібний час, очікуваний coverage і критерії перегляду ролі. Це краще за невизначене «я трохи пишу автотести», бо дає обом сторонам спостережуваний результат.

Як manual QA перейти в automation →

Java · Основний курс · 32:28–37:30

AssertJ і перевірка колекцій

Для assertions підключається AssertJ Core, яку автор радить для різних data types і особливо collections. Оскільки suites endpoint повертає масив, тест перевіряє, що list actual titles містить title щойно створеного suite. Перевірка лише title через JsonPath не масштабується на description та інші fields. Тому наступний крок — deserialization повного response в typed Java object і assertions проти його полів.

API-автоматизація: MVC і Jackson →

Java · Додаткові матеріали · 1:03:35–1:11:45

Рефакторинг, найменування та домашня практика

Автор починає з одного прямого test method, не створючи Page Object і додаткові class до появи реальної потреби. Назва method має описувати тестовий сценарій, а class — сторінку, feature, test suite або роль, яку він покриває. Невикористані імпорти прибираються через optimize imports. Домашнє завдання — відтворити короткий сценарій з авторизацією, дією на наступній сторінці та перевіркою результату.

Створення першого Java-проєкту та тесту →

Запитати в чаті про «test-design» →