QA Growth. Consulting | Mentoring | Courses

Я 14 років у QA і бачив багато людей, які чекали підвищення за стаж. Більшість так і не дочекалась. Бо компанія не платить за роки. Вона платить за три речі. Перше: чи ти береш на себе рішення, а не лише виконуєш задачі. Хто вирішує, що тестувати, а що ні, і чому. Друге: чи видно твою цінність. Не «я знайшов 200 багів», а «ми не втратили реліз і не зірвали дедлайн». Третє: чи можеш ти нести відповідальність за результат команди, а не лише за свої тест-кейси. Стаж без цього означає лише те, що ти довго робиш те саме. Тому через три, п’ять чи вісім років ти опиняєшся в тому ж місці, а новачок із чіткою позицією обходить тебе. Добра новина: усе це навчається. Це не талант і не «пощастило з керівником». Скажи чесно в коментарях: скільки років ти на поточній позиції і що тебе зупиняє? Я читаю кожну відповідь, бо наступного тижня буду розбирати саме це

Колеги привіт, невеличкий апдейт по QA Lunch менеджмент, дата старту змішається на тиждень, бо лечу у відрядження. Почнемо з 9 листопада. Тому, хто хоче приєднатися до тренінгу, ще є час. Нагадаю формат, це 5 днів онлайн зустрічей на різні теми: 1. Онбординг на проєкт 2. Зустрічі 1 на 1 3. DoR та DoD 4. Backlog Refinement 5. Retrospective Реєстрація: https://secure.wayforpay.com/button/b12b2e24be530

Команда без спільних DoR і DoD сперечається не про якість, а про слова. «Готово» для розробника, QA і продакт-оунера часто означає три різні речі. Результат: задачі, які «повертаються» зі стадії тестування, переноси у наступний спринт і конфлікти на демо. DoR: що має бути до початку роботи - acceptance criteria, які можна перевірити - ясні залежності, дизайн, інтеграції - тестові дані й середовище - User Story оцінена й вміщується в спринт DoD: що має бути для завершення - код пройшов ревʼю - автоматизовані й ручні перевірки виконані - критичні дефекти закриті - документація оновлена, функціонал задеплоєний і перевірений Роль QA: ми першими бачимо наслідки нечітких критеріїв, тож маємо впливати на DoR/DoD, а не лише виконувати їх. Хороший DoR зменшує невизначеність до розробки, хороший DoD робить якість командною відповідальністю, а не етапом наприкінці. 🍽 Про це й не тільки поговоримо на QA Lunch! 📅 з 2 листопада 5 днів підряд о 16:00 Розберемо 5 тем: 1. Онбординг на проєкт 2. Зустрічі 1 на 1 3. DoR та DoD 4. Backlog Refinement 5. Retrospective Реєстрація: https://secure.wayforpay.com/button/b12b2e24be530 Вартість: 49$ 💬 А який пункт у вашому DoD команда найчастіше «забуває»?

AI не замінить QA. Але QA, який володіє AI, матиме перевагу над тим, хто ним не користується. За 14+ років у QA я бачив кілька хвиль змін: автоматизація, CI/CD, shift-left. AI-агенти та скіли – наступна, і вона швидша за попередні. Чому це важливо саме зараз Значна частина QA-роботи рутинна: написання тест-кейсів, підготовка даних, оформлення багів, аналіз падінь у регресі. AI вже вміє це робити добре. Тестувальник, який делегує рутину, вивільняє час на те, що справді створює цінність: аналіз ризиків, дослідницьке тестування, комунікація з продактом і розробкою. Які інструменти варто знати 1. Чат-асистенти (Claude, ChatGPT та ін.): аналіз вимог, пошук прогалин в історіях, генерація тест-кейсів і тестових даних, покращення баг-репортів. 2. AI в IDE (GitHub Copilot, Cursor, Claude Code): написання й рефакторинг автотестів, пояснення чужого коду, генерація page objects. 3. Playwright з AI-агентами та MCP: модель бачить реальну сторінку, планує сценарії, генерує тести й допомагає лагодити нестабільні. 4. Платформи з вбудованим AI (mabl, Applitools, Testim, Katalon та інші): self-healing локаторів, візуальне порівняння, аналіз флакі-тестів. Агенти та скіли: чим вони відрізняються і чому це важливо - Агент виконує багатокрокову задачу: читає вимоги, використовує інструменти, запускає тести, аналізує результат і повертається з висновком. - Скіл це пакет інструкцій і стандартів, який можна повторно використовувати: шаблон баг-репорту, формат тест-кейсів, чекліст ревʼю, правила іменування. Разом вони дають головне: AI працює за стандартами вашої команди, а не «як вийде». Приклад робочого процесу Скіл описує, як у команді пишуться тест-кейси: структура, рівень деталізації, обов'язкові негативні сценарії. Агент бере сторю з беклогу й спершу формулює уточнювальні питання до PO. Потім за скілом генерує чернетку тест-кейсів. Після цього пропонує автоматизацію ключових сценаріїв. QA перевіряє, виправляє й доповнює. Замість години рутини виходить 10-15 хвилин експертного ревʼю. Правила безпечного використання ✅ Перевіряйте кожен результат: AI може впевнено помилятися. ✅ Не передавайте конфіденційні дані клієнтів і код без дозволу компанії. ✅ Починайте з одного повторюваного процесу, а не з «автоматизації всього». ✅ Вимірюйте ефект: час, кількість знайдених дефектів, стабільність тестів. Підсумок: AI не знімає з QA відповідальність за якість, він підсилює тих, хто вміє ставити правильні питання й оцінювати результат. Тому критичне мислення, розуміння ризиків і контексту стають цінністю, яка ще зросте.

Backlog refinement: найдешевший момент знайти баг – до того, як з'явився код  Дефект у вимогах, знайдений на рефайнменті коштує хвилин обговорення. Той самий дефект, знайдений на проді, коштує спринту, нервів і довіри клієнта. Тому QA на рефайнменті – це не «послухати й записати». Це одна з найактивніших ролей на зустрічі. Що робити ДО мітингу (20-30 хвилин, які окуповуються з лихвою): • прочитати user story, які будуть на розгляді; • позначити неоднозначності: «швидко», «зручно», «за потреби»; • перевірити, чи є acceptance criteria і чи їх можна перевірити; • продумати негативні сценарії та граничні значення; • підготувати 3-5 питань для PO та розробників. Приклад. Сторя: «Користувач може скасувати замовлення». QA, який підготувався, ставить питання: до якого статусу можна скасувати? Що з уже проведеною оплатою? Чи сповіщаємо склад? Що, якщо скасовують двоє адмінів одночасно? Без цих питань ми б дізналися відповіді вже під час тестування, коли код написаний. Що це дає команді: ✅ точніші оцінки ✅ менше переробок ✅ спільне розуміння ще до розробки QA, який з'являється на рефайнменті без підготовки, втрачає найцінніше, що в нього є: можливість вплинути на якість до початку розробки. А ви готуєтесь до рефайнментів заздалегідь? 👇

Не існує «найкращих практик» у тестуванні. Існують практики, які найкраще підходять до вашого контексту. За 14+ років у QA я бачив одну й ту саму помилку: команди копіюють підхід із попереднього проєкту й дивуються, чому він не працює. Це ключова ідея context-driven testing: цінність будь-якої практики залежить від контексту, в якому її застосовують. Приклад: одна функція, дві стратегії Візьмемо «Оплата карткою». Фінтех-продукт –  Ризик: втрата коштів, порушення вимог регулятора, репутаційні збитки –  Фокус: безпека, ідемпотентність транзакцій, коректність розрахунків, поведінка при збоях мережі й таймаутах –  Підхід: глибока ризик-аналітика, автоматизація регресу, негативні й edge-сценарії, перевірка логів та аудиту Невеликий e-commerce –  Ризик: втрата конверсії, погана користувацька взаємодія –  Фокус: зручність checkout на мобільних, швидкість, зрозумілі помилки, збереження кошика –  Підхід: дослідницьке тестування, перевірка основних пристроїв і браузерів, швидкий цикл зворотного зв'язку Функція однакова. Стратегія, глибина й пріоритети різні, бо різні ризики, користувачі й обмеження. Чотири питання, з яких я починаю будь-яку QA-стратегію: Хто користувачі й що для них критично? Яка реальна ціна помилки для бізнесу? Які в нас обмеження: час, бюджет, команда, технології? Де найбільша невизначеність і ризик? Підсумок: якість – це не кількість тест-кейсів і не відсоток покриття. Це здатність знайти й попередити те, що важливо саме для цього продукту й цих людей. Хороший тестувальник вміє виконувати чеклісти. Сильний QA вміє вирішувати, що саме варто перевіряти, а що ні. 💬 А який найцікавіший приклад із вашої практики, коли «стандартний підхід» не спрацював через контекст?

🍽 QA Lunch: тиждень менеджменту Наступний запуск QA Lunch присвячений менеджменту. 5 днів поспіль, щодня окрема тема, багато практики і живих розмов. Про що говоримо: 1️⃣ Онбординг на проєкт 2️⃣ Зустрічі 1 на 1 3️⃣ DoR та DoD 4️⃣ Backlog Refinement 5️⃣ Retrospective Це не тільки лекції, а й розмови з практичними порадами, які можна застосувати в команді вже наступного дня. 💰 Вартість: 49$ за весь тиждень 📅 Старт: 2 листопада Реєстрація: https://secure.wayforpay.com/button/b12b2e24be530

Друзі привіт, нагадую що в мене вже більше року діє QA Growth Club, де ми збираємося 2 рази на місяць і спікери діляться своїм досвідом. Інколи розбираємо кейси один одного. Завтра о 19:00 за Києвом буде такий виступ Тема: ШІ агенти для пришвидшення роботи QA. Як створити агента та коли потрібно його створювати а коли ні. Лімітейшини та ризики його використання Ігор Добровольський - Senior QA Automation Engineer із 9+ роками досвіду у побудові архітектури тестування та CI/CD рішень. Активно досліджує та впроваджує AI-асистовані підходи в автоматизації тестування, оптимізуючи процеси генерації тест-кейсів, аналізу коду та підвищення ROI інженерних команд. Якщо вам цікаво доєднатися, ось посилання на оплату клубу. https://conference.ry-consulting.online/ Якщо хочете прийти разово - вартість 500грн. Кошти на банку, скрін оплати для входу мені @yakymchuk_roma

Оптимізація тестування: як тестувати менше, а знаходити більше Класична пастка команди QA — намагатися перевірити все. Результат: тисячі тест-кейсів, регресія на пів дня і відчуття, що часу вічно не вистачає. При цьому критичні баги все одно проскакують у прод. Оптимізація тестування — це не про «менше роботи», а про правильний фокус. Кілька принципів, які реально працюють: 1. Ризик-орієнтований підхід Не всі частини системи однаково критичні. Оплата, авторизація, передача даних — це зони, де ціна помилки висока. Саме туди йде основна глибина тестування, а не туди, де просто «легше написати кейси». 2. Розумний тест-дизайн замість перебору Замість того щоб вручну генерувати десятки схожих кейсів, варто застосовувати техніки тест-дизайну: класи еквівалентності, граничні значення, попарне тестування, таблиці рішень. Вони дозволяють покрити ті самі сценарії значно меншою кількістю тестів — і при цьому не втратити важливі кейси. 4. Регулярний перегляд тестового набору Тест-кейси старіють разом з продуктом. Частина стає дублікатами, частинавтрачає сенс. Періодичний аудит набору — це теж оптимізація, тільки не тестування, а тест-бази. Головний висновок: оптимізація починається не з інструментів автоматизації, а з голови — з уміння правильно спроєктувати тести ще на етапі планування. Якщо хочете системно розібратися саме в техніках тест-дизайну — класи еквівалентності, граничні значення, попарне тестування, таблиці рішень, діаграми переходів станів — запрошую на курс «Техніки тест-дизайну». Формат онлайн, 3 заняття на тиждень протягом двох тижнів, багато практики на реальних кейсах. Деталі та запис — пишіть мені в особисті @yakymchuk_roma

🚀 Стартує курс «Техніки тест-дизайну»! Якщо ти хочеш не просто «пройтись» по тест-кейсам, а навчитися системно знаходити більше дефектів, не збільшуючи кількість тестів — цей курс для тебе. За 2 тижні та 6 практичних зустрічей розберемо й відпрацюємо на практиці: 🔹 Еквівалентні класи 🔹 Граничні значення 🔹 Pairwise testing 🔹 State & Transitions Diagram 🔹 State & Transitions Tables 🔹 Таблиці рішень І головне — будемо не просто слухати теорію, а розбирати реальні приклади, задачі та кейси. 📅 Старт — 28 вересня ⏱ Тривалість — 2 тижні 🔥 6 практичних зустрічей Цей курс допоможе прокачати саме тестувальницьке мислення — вміти бачити комбінації, граничні ситуації, залежності та сценарії, які легко пропустити. 👉 Хочеш приєднатися? Пиши мені @yakymchuk_roma в Direct слово «ТЕСТ-ДИЗАЙН» — розповім деталі та забронюю місце. Давай тестити розумніше, а не просто більше. 🔥

За 14+ років у IT і QA я бачив багато команд. Різниця між зрілим і незрілим процесом тестування майже завжди видна в одному: чи може команда пояснити, чому вона перевіряла саме ці сценарії. Вичерпне тестування неможливе. Навіть просте поле вводу має нескінченну кількість значень. Тому питання не «як перевірити все», а «як вибрати мінімум перевірок, що дає максимум впевненості». Саме на нього відповідають техніки тест-дизайну. Що отримує бізнес, коли QA використовує техніки: 🔹 Прогнозоване покриття. Можна показати, що саме перевірено і що свідомо залишено поза увагою. 🔹 Економію часу і бюджету. Немає сотень дублюючих тест-кейсів, які ніколи не знаходять багів. 🔹 Раннє виявлення дефектів. Аналіз вимог для побудови тестів сам по собі виявляє прогалини ще до розробки. 🔹 Незалежність від людини. Результат не залежить від того, хто саме тестував і який у нього настрій. 🔹 Спільну мову в команді. «Ми застосували таблицю рішень для цієї логіки» звучить переконливіше за «ми потестили». Мінімальний набір, який варто опанувати: 1. Розбиття на класи еквівалентності 2. Аналіз граничних значень 3. Таблиці рішень 4. Тестування переходів між станами 5. Pairwise-тестування для комбінацій параметрів 6. Error guessing як доповнення, а не заміна Мій висновок простий: техніки тест-дизайну не «теорія для сертифікацій». Це інструмент, який щодня економить гроші проєкту і репутацію інженера. А як у вашій команді? Техніки використовують усі чи лише окремі люди? Поділіться в коментарях 👇

🎯 Набираю групу на 2-тижневий курс «Техніки тест-дизайну» Тестуєш навмання і сподіваєшся, що баги знайдуться самі? Час це змінити. За 2 тижні на практиці розберемо: ✅ Класи еквівалентності ✅ Граничні значення ✅ Попарне тестування ✅ Таблиці рішень ✅ Діаграми станів та переходів ✅ Таблиці станів та переходів Кожну техніку показую не в теорії, а на реальних кейсах — щоб ви нарешті навчились впевнено застосовувати техніки тест-дизайну у своїй роботі, а не лише читали про них. Формат: онлайн, 3 заняття на тиждень, веду особисто я — Роман Якимчук (14+ років у QA). 28 вересня СТАРТ 💰 Ціна курсу: 9900 грн 🔥 До 23 вересня — знижка: 7900 грн Місця в групі обмежені, встигніть зареєструватись https://secure.wayforpay.com/button/b2f0175e76fee

Чому в команді 5 QA, а якість все одно тримається на одному Senior? За роки роботи з різними командами я бачив цю ситуацію десятки разів. У компанії вже є QA є Jira є тест-кейси є баг-трекінг є навіть Test Lead Але якщо завтра найсильніший QA піде у відпустку – процес фактично зупиниться. Чому? Тому що команда не має керованого процесу тестування. Наприклад, приходить нова фіча. Менеджер каже: – Нам треба протестувати до п'ятниці. QA починають ставити питання: – А що саме тестувати? – Які ризики? – Які частини системи зачіпає? – Що вже перевіряли? – Який regression scope? – Що критично для бізнесу? – Хто приймає рішення, що реліз можна випускати? І замість тестування команда витрачає час на з'ясування того, як взагалі організувати тестування. Я часто бачу ще одну проблему. Команда намагається вирішити процес за допомогою інструменту: «Давайте поставимо Xray» «Давайте перейдемо на TestRail» «Давайте спробуємо Testomatio». Але якщо немає Test Strategy, планування, правил роботи, відповідальності, критеріїв входу/виходу і зрозумілого тест менеджменту – новий інструмент просто допоможе швидше створювати безлад. Що я зазвичай роблю під час аудиту QA-процесу? Я дивлюся не тільки на тестувальників Я розкладаю весь процес: Business → Requirements → Development → QA → Release → Production І шукаю, де саме виникають втрати. Наприклад: – вимоги приходять до QA вже після початку розробки – QA не залучені до аналізу ризиків – немає зрозумілого regression scope – кожен QA тестує «по-своєму» – тестова документація існує, але ніхто не знає, навіщо вона – баги закриваються, але root cause ніхто не аналізує – менеджмент бачить кількість багів, але не бачить реальний стан якості – відповідальність за quality фактично лежить тільки на QA І ось тут починається справжній Test Management. Не з тест-кейсів А з питання: «Як зробити так, щоб команда могла стабільно забезпечувати потрібний рівень якості?» У хорошому процесі QA не повинні бути «фінальним фільтром перед продом». QA повинні допомагати команді керувати ризиками ще до того, як код написаний. І це одна з найбільших змін, які я бачу, коли команда переходить від «ми тестуємо» до «ми керуємо якістю». Бо зрілий QA-процес – це не більше тест-кейсів. Це менше невизначеності, менше втрат і більш передбачувані релізи. Саме тому під час роботи з командами я завжди починаю не з питання: «Який у вас Test Management tool?» А з питання: «Як у вас зараз приймається рішення, що продукт достатньо якісний для релізу?» Відповідь на це питання часто розповідає про зрілість QA-процесу набагато більше, ніж кількість написаних тест-кейсів.

14 років тому я прийшов у професію та вніс новий запис у свою трудову книжку «Інженер по забезпеченню якості ПЗ» І сьогодні в день Тестувальника, я хотів би привітати всіх причетних до цього свята. За ці роки я протестував десятки проєктів, знайшов та виявив на ранніх стадіях тисячі багів. Завтрматизував купу веб, мобільних, embedded та десктоп фіч. Впродовж всієї карʼєри було дуже багато різного досвіду. З 2014 року почав вести блог про тестування. Навчив та підвищив кваліфікацію більше 1000+ інженерів. В 2014 році 3 місце на змаганнях dev challenge в категорії тестування. В 2016 2 місце в Європі серед тестувальників Senior рівня. 100 записаних відео на YouTube та проведених вебінарів. І в 2026 році випуск моєї книги «Свідоме тестування» і це ще не кінець. Це тільки частинка з усього того, мій практичний досвід, переданий на сторінках книги. https://secure.wayforpay.com/button/b36db437c00b6 Не знаю як у вас, а я пишаюся своїм карʼєрним шляхом і мисленням, яке дала мені ця професія. Всіх причетних вітаю 🥳

Ти не станеш сеньйором, просто працюючи більше років. Можна 7 років працювати в QA і фактично 7 разів повторити один і той самий рік. Senior – це не цифра в LinkedIn і не кількість років у CV. Для мене senior-рівень починається там, де людина перестає просто виконувати задачі й починає впливати на результат. Можна чудово тестувати фічі, знаходити баги та закривати тікети. Але якщо ти не розумієш, чому саме команда тестує так, а не інакше, де процес втрачає час і гроші та як його можна перебудувати – одного досвіду недостатньо. На рівні Senior важливо: – бачити не лише сам баг, а й причину, через яку він потрапив на цей етап – розуміти, чи справді конкретний тест-кейс приносить користь – уміти будувати та змінювати процеси, а не лише працювати в уже створених – самостійно помічати проблеми та пропонувати рішення – розуміти продукт, ризики, бізнес і те, як працює команда загалом – ділитись досвідом з молодшими колегами, делегувати на них задачі та контролювати хід виконання І саме тут багато спеціалістів застрягають. Вони думають: Junior → Middle → ще кілька років → Senior. Але час сам по собі не підвищує рівень. Підвищує рівень складність задач, які ти здатен вирішувати, рівень відповідальності, яку ти можеш взяти, і масштаб впливу на команду та продукт. Тому замість питання: «Скільки років мені ще потрібно до Senior?» я б поставив інше: «Які проблеми сьогодні вирішує Senior, які я поки що не вмію вирішувати?» Ось із цього питання зазвичай і починається справжній професійний ріст. А що для вас є головною ознакою Senior QA: технічні знання, самостійність, відповідальність чи вплив на процеси?