Програма · QA Architecture
Набір скоро відкриється
Senior QA / Lead → QA Architect / Head of QA
Побудуйте QA-архітектуру та стратегію тестування, яка витримає ріст продукту і команди.
01. Для кого
Senior QA → Lead
«Я добре тестую, але не знаю, як масштабувати вплив на якість за межами власних tasks»
Навчитеся
Навчитеся читати архітектуру системи як джерело ризиків, будувати risk-based стратегію й говорити з product мовою рішень — а не мовою дефектів.
Lead → Test Manager / Head of QA
«Я відповідаю за процес і releases, але governance, OKR і C-level комунікація — моє слабке місце»
Навчитеся
Отримаєте framework QA-функції: RACI-модель, metrics-based управління — і вмітимете захищати quality-рішення перед steering committee.
Senior QA / SDET → QA Architect
«Хочу бути власником технічної test strategy й архітектури якості на рівні продукту»
Навчитеся
Пройдете повний ланцюг: architecture-to-risk map, risk-based стратегія, DORA-метрики, тестування AI-систем, governance та стратегічний вплив.
02. Результат
03. Програма курсу
35 занять · Практичні завдання · Фінальний проєкт
Побудуйте QA-архітектуру та стратегію тестування, яка витримає ріст продукту і команди: від architecture-to-risk map до захисту Capstone перед steering committee.
Mindset & Framing
Розвилка ролей QA Manager vs QA Architect, чотири спільні осі (risk, metrics, governance, strategy), career ladder та вибір Project X.
Практика: кожен студент формулює кандидата на власний Project X і пояснює, де зараз у ланцюгу.
Application architectures для QA
Як архітектурний стиль системи диктує, де ставити test levels й де народжуються ризики якості?
Практика: розбір реальної архітектурної діаграми — класифікація стилю, позначення test levels і risk-точок.
ДЗ: Project X brief + адаптована test pyramid + перевірка tenant isolation.
Читання системи: testability, risk hotspots, test levels
Як із архітектурної картини знайти зони ризику й точки нетестованості раніше, ніж вони стануть інцидентом?
Практика: позначення 5 risk hotspots на спільній діаграмі з аргументацією пріоритету.
ДЗ: Architecture-to-risk map для Project X (компонент → ризик якості → тест-рівень).
Outsourcing vs product company: різниця в управлінні
Як той самий продукт вимагає різної стратегії, метрик і governance залежно від моделі залучення?
Практика: для одного продукту — що змінюється в підході QA-лідера як аутсорсера vs власника продукту.
ДЗ: one-page порівняння керування якістю Project X як аутсорсер vs product owner.
Risk-based testing від початку до кінця
Як систематично перетворити «що може піти не так» на пріоритети тестування — до того, як щось пішло не так?
Практика: побудова risk matrix, калібрування likelihood/impact у групі.
ДЗ: Risk register ≥12 ризиків + risk matrix для Project X.
Ієрархія документів: policy → strategy → plan
Який документ за що відповідає — і чому плутанина рівнів руйнує governance?
Практика: розкласти набір реальних документів по рівнях ієрархії 29119.
ДЗ: чернетка organizational test policy + позначення рівня Project X.
Навіщо існують артефакти: traceability, auditability, «just enough»
Як відрізнити артефакт, що знижує ризик, від документації заради документації?
Практика: критика over- і under-documented прикладів з пропозицією балансу.
ДЗ: artifact justification table для 6 артефактів Project X (навіщо, хто споживач, ризик відсутності).
Написання test strategy (Test Strategy v1)
Як зібрати ризики, архітектуру й контекст в одну project test strategy, захищувану перед бордом?
Практика: написання секції «test approach + objectives» для навчального кейсу.
ДЗ: Draft Test Strategy v1 (scope, approach, levels, objectives, risks-link).
Quality gates і release readiness
На яких даних і хто приймає go/no-go — і як явно прийняти залишковий ризик?
Практика: проєктування одного quality gate з вхідними/вихідними критеріями.
ДЗ: quality-gate / release-readiness checklist для Project X.
Метрики тестування, що мають значення
Чим «метрика для команди» відрізняється від «метрики для борду»?
Практика: для сценарію обрати 5 метрик і аргументувати вибір.
ДЗ: metrics specification для Project X (метрика + формула + джерело).
Delivery & quality analytics: DORA + DX Core 4
Як поєднати швидкість доставки і стабільність в одну картину?
Практика: інтерпретація набору DORA-даних — де команда сильна, де нестабільність.
ДЗ: metrics spec v2 + макет dashboard з QA + DORA + DX Core 4 метриками.
Quality dashboard, vanity metrics і GQM
Як зібрати dashboard, який реально читають?
Практика: GQM від однієї бізнес-цілі до 2–3 метрик.
ДЗ: GQM-дерево для Project X + рефайн mock dashboard.
Моделі покращення процесів: TMMi та IDEAL
Як оцінити зрілість тест-процесу об'єктивно й спланувати покращення на даних?
Практика: швидкий TMMi self-assessment навчальної організації.
ДЗ: TMMi maturity self-assessment + improvement roadmap для Project X.
Release process і контроль якості на ньому
Де в CI/CD-конвеєрі живе контроль якості?
Практика: нанесення quality signals на схему CI/CD pipeline.
ДЗ: release-process quality-control checklist для Project X.
Ландшафт AI-SDLC
Де AI прискорює доставку, а де дестабілізує?
Практика: AI-SDLC impact map для Project X (фаза → допомога → ризик нестабільності).
ДЗ: AI-SDLC impact map для Project X.
GenAI для тестувальної роботи
Як застосувати GenAI до реальних тест-задач так, щоб якість не «провисала»?
Практика: генерація тест-кейсів з поганим та хорошим входом — порівняти якість.
ДЗ: prompt-engineered test-artifact pack + human-review log.
Тестування AI-систем
Як перевіряти систему без детермінованого oracle?
Практика: проєктування metamorphic-тестів і сурогатного oracle для недетермінованого виходу.
ДЗ: test approach для AI/GenAI-фічі Project X (non-deterministic поведінка, drift, bias).
Ризики й governance AI у QA
Які ризики AI неможливо «відтестувати» технічно?
Практика: побудова AI-risk register на навчальному кейсі.
ДЗ: AI-risk register для Project X (hallucination, bias, privacy, drift) з mitigation.
Test Strategy в умовах AI-SDLC (v2)
Як апгрейдити класичну test strategy до AI-SDLC?
Практика: модифікація одного наявного quality gate під AI-фічу.
ДЗ: AI-SDLC upgrade до Test Strategy v2.
Проєктування governance
Як спроєктувати governance під масштаб проєкту?
Практика: CoE-структура для заданої організації.
ДЗ: governance model + RACI для Project X (large + medium варіанти).
Goal-setting: OKR, KPI, SMART
Як перетворити quality-ціль на каскад OKR/KPI?
Практика: написати один QA-OKR з key results і відрізнити від KPI.
ДЗ: QA OKR/KPI set для Project X (3 OKR + supporting KPIs).
Agile-frameworks для QA-лідерів
Де в Scrum чи Kanban живе test management?
Практика: розміщення QA-активностей у Scrum-спринті vs Kanban-потоці.
ДЗ: QA-in-delivery model для Project X (де QA, як рухаються test-таски).
Working agreements: DoR / DoD / Acceptance Criteria
Як зробити DoR/DoD/AC живими working agreements?
Практика: переписати слабкий набір AC у Given/When/Then + додати testability в DoR.
ДЗ: working-agreements pack (DoR-checklist, багаторівневий DoD, AC-шаблон + 3 приклади).
Управління людьми для QA-лідерів
Як побудувати й розвивати QA-команду, щоб якість трималася на системі, а не на героїзмі?
Практика: hiring scorecard для однієї QA-ролі.
ДЗ: team structure + hiring/mentoring plan для Project X.
Управління процесами
Як проєктувати дефект-менеджмент і capacity planning?
Практика: defect workflow зі станами й правилами переходів.
ДЗ: defect lifecycle + capacity plan для Project X.
Письмова комунікація технічного лідера
Як написати повідомлення про ризик так, щоб executive прийняв рішення за 30 секунд?
Практика: переписати розпливчасте повідомлення у decision-oriented форму.
ДЗ: communication pack — risk-escalation email, go/no-go status, decision log entry.
Вплив на stakeholders без формальної влади
Як зробити, щоб «release risk у $X» переважив «ми знайшли 200 bugs»?
Практика: зібрати бізнес-аргумент за/проти release для умовного борду.
ДЗ: executive one-pager — обґрунтувати одне quality-рішення мовою бізнесу.
Capstone integration workshop
Як зібрати артефакти M1–M5 в один board-ready пакет без суперечностей?
Практика: складання чернетки пакета + cross-review між студентами.
ДЗ: Integrated Capstone Test Strategy package (M1–M5 в одному документі).
Захист Capstone перед steering committee
Чи здатен студент захистити стратегічне рішення під тиском питань?
ДЗ: defense deck + живий захист.
Storytelling для QA-лідера
Як перетворити сухі метрики на narrative, який топ-менеджмент запам'ятає? Структура «ситуація → ускладнення → вирішення → результат»; адаптація під аудиторію (команда / менеджмент / C-level).
ДЗ: storytelling-версія метрик-звіту Project X (до 1 стор. + нотатки для усної подачі).
How to Sell: продаж ідей і якості всередині організації
Як «продати» QA-ініціативу через цінність для stakeholder — і подолати «нема часу / бюджету / не пріоритет»? Value proposition для QA-ініціативи; подолання заперечень; продаж тиском vs цінністю.
ДЗ: pitch на продаж однієї QA-ініціативи Project X.
Driving the Change: управління змінами в QA-процесах
Чому зміни в процесах провалюються — і як провести трансформацію, щоб вона закріпилася? ADKAR / Kotter для QA-трансформацій; роль change agent; sustain після впровадження.
ДЗ: change-management plan для однієї зміни в Project X.
TaaS (Testing as a Service)
Коли TaaS доцільний, а коли краще власна команда? Моделі ціноутворення; ризики: залежність від провайдера, контроль якості, knowledge transfer.
ДЗ: one-page аналіз TaaS для частини тестування Project X.
Discovery: оцінка проєкту на старті залучення
Як за перші два тижні в новому проєкті зібрати картину, якої ще немає? Stakeholders, процеси, болі команди, очікування клієнта; типові помилки — поспішні висновки.
ДЗ: discovery plan для нового залучення на Project X.
Firefighting: управління якістю в кризі
Як діяти, коли якість «горить» — і як вийти з режиму постійного пожежника? Продакшн-інцидент, провалений дедлайн, масовий приплив дефектів: пріоритети та комунікація.
ДЗ: firefighting playbook для Project X (ролі, комунікація, ескалація, post-mortem).
Basics of Successful Negotiations
Як вести переговори про терміни, обсяг тестування й бюджет з позиції інтересів? Позиції vs інтереси; BATNA як джерело сили; win-win замість конфронтації.
ДЗ: negotiation brief для кейсу в Project X (інтереси, BATNA, тактики іншої сторони).
04. Фінальний проєкт
Протягом курсу ви будуєте реальний board-ready пакет для свого поточного проєкту — не навчальний кейс, а робочий артефакт, з яким виходите на наступну роль. 19 deliverables, єдиний захист:
M1Architecture-to-risk map + Project X briefM2Risk register ≥12 ризиків + risk matrixM2→M4Project Test Strategy v1 → v2 з AI-SDLC апгрейдомM2Quality-gate / release-readiness checklistM3Metrics specification + mock dashboard: QA + DORA + DX Core 4M3TMMi maturity assessment + improvement roadmapM4AI-risk register + test approach для AI/GenAI-фічіM5Governance model + RACI — large & medium варіантиM5Working-agreements pack: DoR / DoD / ACM5QA OKR/KPI set + team & hiring planM6Communication pack: risk-escalation email, go/no-go status, decision logM6Defense deck + захист 20 хв + 15 хв питань від steering committeeM7Storytelling-narrative: метрики → narrative для топ-менеджментуM7Sales pitch: продаж QA-ініціативи з відпрацюванням запереченьM7Change-management plan за ADKAR / KotterM7TaaS feasibility analysis: скоуп, ризики, SLAM7Discovery plan: перші два тижні в новому проєктіM7Firefighting playbook: ролі, комунікація, ескалація, post-mortemM7Negotiation brief: інтереси, BATNA, тактики іншої сторони05. Як проходить навчання
06. Викладач
QA & Performance Architect · AI Agent Development & Testing · 14+ років в IT
07. Вартість
Повна вартість
120 000 грн
Повна вартість програми: 8 блоків, 35 занять, ~33 тижні.
Що входить
Чому курс окупається
Head of QA та QA Architect — серед найвище оплачуваних ролей у тестуванні. За даними Glassdoor (2026): Великобританія — £83 554/рік, Німеччина — €97 001/рік, США — $189 075/рік. Курс готує саме до цього переходу — і окупається за один–два місяці після зміни ролі.
Джерела: Glassdoor UK · Glassdoor DE · Glassdoor US
08. FAQ
Так. Курс розроблений саме для тих, хто вже в Lead-ролі або впритул до неї. Якщо ви виконуєте роботу лідера, але ще не маєте системних інструментів (стратегія, governance, OKR, C-level комунікація) — ви в правильному місці.
Для обох. Блоки з архітектурного аналізу ризиків і стратегії тестування однаково актуальні для product і outsource. Заняття 3 (Outsourcing vs product company) і заняття 33 (Discovery) дають окремий фрейм для сервісних компаній.
Ні. Курс орієнтований на стратегію, архітектуру та управління, а не на написання тестів. Базове розуміння SDLC і тестування — достатньо.
2–3 год на живе заняття + 2–4 год на домашнє завдання (Capstone-артефакт для свого проєкту). Загалом 4–7 год/тиждень.
Кожне заняття записується. Запис доступний одразу після заняття. Домашнє завдання можна здати з відставанням на 1 тиждень без штрафів.
Так, сертифікат про проходження курсу. Але головний результат — це Capstone-пакет: реальний board-ready артефакт, який ви захищаєте і кладете в портфоліо.
Групи малі — деталі про старт і розмір групи уточнюються індивідуально. Залиште контакт — напишемо особисто.
Набір скоро відкриється