Roman Yakymchuk Consulting

Доброго дня, сьогодні хочу з вами поділитися своїми спостереженнями по впровадженню ШІ в роботу наших клієнтів. Я вже пів року впроваджую AI в роботу команд тестувальників. І результати мене дуже радують 🙌В першу чергу, для мене як для консультанта з великим досвідом, АІ дає дуже багато допомоги. Так як більшість аудитів я роблю самостійно і все записую, АІ допомагає всю цю сиру інформацію перетворити на структуровані документи, що виглядає прям дуже найс 🤌По-друге я налаштовую тест менеджмент систему та також використовую вбудовані АІ для генерації тест кейсів, автоматичне створення багів теж допомагає. Бо раніше на створення тест кейсів та баг репортів, команди витрачала багато часу, а тепер все це робиться буквально за лічені секунди. Нам вдалося в 5 разів пришвидшити стадію тест дизайну та покращити покриття системи тестами. Використовуємо Claude для написання стратегій, планів, створення онбординг планів та різних типів тестової документації, це теж в десятки разів пришвидшує роботу. В автоматизації використовуємо також Claude, який дуже класно накидує структуру та пише непогані, я б сказав, скрипти, які звісно потрібно рефакторити, але все ж результати круті 🔥Якщо брати в середньому по всім клієнтам, нам вдалося мінімум на 30% покращити ефективність команд завдяки інструментам штучного інтелекту. А це в свою чергу знижує витрати на ресурси і компанії економлять чималі кошти на цьому, а якість тільки зростає 💪А ви користуєтесь ШІ, напишіть свої кейси використання нижче 👇

Друзі всім привіт, сьогодні останній день коли можна придбати менторську програму QA Growth за 1490$ замість 2490$Блок 1. Ознайомлення та аналіз продуктуУрок №1: Дослідження продукту за допомогою декомпозиціїУрок №2: Алгоритм тестування вимогУрок №3: Вибір та оптимізація тестової документаціїБлок 2. Планування ТестуванняУрок №1: Планування роботи над проектомУрок №2: Підготовка стратегії тестуванняУрок №3: Проведення оцінювання робітБлок 3. Використання Технік тест дизайнуУрок №1: Розбиття на класи еквівалентностіУрок №2: Аналіз граничних значеньУрок №3: Попарне тестуванняУрок №4: Діаграми станів та переходівУрок №5: Таблиці станів та переходівУрок №6: Таблиці рішеньБлок 4. Тест аналізУрок №1: Аналіз параметрів та значеньУрок №2: Використання техніки доменного аналізуУрок №3: Комбінаторика на основі аналізу взаємозв'язківУрок №4: Тестування прав доступа. Права та роліУрок №5: Аналіз середовищ, кросплатформене тестуванняУрок №6: Аналіз залежностей. Планування та відбір тестів для Регресійного тестуванняБлок 5. Дослідницьке тестуванняУрок №1: Загальне розуміння про Дослідницьке тестування vs Ad hoc тестуванняУрок №2: Тестування на основі сесій з використанням CharterУрок №3: Парне тестуванняУрок №4: Мозковий штурмУрок №5: Тестування на основі персонУрок №6: Тестові туриУрок №7: 6 думаючих капелюхівБлок 6. Управління командамиУрок №1: Найм працівників Урок №2: Онбординг на проект Урок №3: Розвиток командиУрок №4: Мотивація та підтримка командиУрок №5: 1 на 1 мітингиУрок №6: RACI матриця для менеджменту командиУрок №7: Психологія лідерстваБлок 7. Управління процесамиУрок №1: Створення процесу тестування з нуляУрок №2: Вибір інструментів для менеджменту тестуванняУрок №3: Налаштування та використання TMSУрок №4: Конфігурація процесів Jira + TMSУрок №5: Менеджмент дефектів Bug TriageУрок №6: Тестова документація. Traceability Matrix, Test Summary ReportУрок №7: Збір МетрикУрок №8: Аудит та покращення QA процесів40 уроків7 додаткових воркшопів, мастермайндів та практичних вебінарів від мене та інших експертів (рекрутер, freelance expert, QA architect)5 місяців зворотнього звʼязку від мене по будь яким питанням щодо навчальної програмиДодатково бонуси: підготовка до співбесіди, створення CV, індивідуальна консультація від мене на 2 години за вашим запитомP.S. нагадую що це останній запуск навчання зі мною

Чи правда потрібно бити на сполох, якщо у вас немає вимог на проєкті?Постійно чую від колег, що в нас немає людини яка б писала вимоги. І всі задачі створюються в Jira з мінімальним описом (слава Богу що хоч Jira є і опис мінімальний 😁). Але вимоги то не є проблема в сучасному світі. Я раніше коли тільки починав, то був у нас такий кейс, але я взяв відповідальність та запропонував за 1500 грн (~200$ - 2013 рік) до зп, ще писати гарні вимоги до своїх проєктів. Зараз на проєктах у своїх клієнтів ми просто впроваджуємо повноцінний AI який генерує круті Acceptance Criteria. PM потім тільки проходиться і коригує все що не дуже, хоча можна і промптами підкоригувати, при бажанні. А коли вже є вимоги, то вже підвищується якість і розробки і тестування.Тому рекомендую вам наступного разу, перед тим як жалітися на відсутність вимог на проєкті, просто взяти і згенерувати їх самим, зробити ревю та далі йти по процесу Refinement -> Planning -> Test Design -> Test Execution - Test ClosureHappy Testing 😉

Друзі, сьогодні я хочу поговорити з вами про метрики в QA, які ми маємо збирати для того, щоб покращити наші процеси.Почнемо з першої метрики ⬇️Для початку давайте домовимося, що зараз ми поділяємо метрики на кількісні та якісні.🔹 Кількісні — збирають кількісні показники,🔹 а якісні — збирають показники якості.Перша з кількісних метрик, яку я пропоную впроваджувати на проєкті — це Escaped Bugs 🐞Що це взагалі за така метрика?Коли ми тестуємо наш софт, ми знаходимо різні баги.І нам потрібно підраховувати всю кількість багів, яку ми знайшли.А якщо на проді виявляються баги — то ми маємо заміряти, який відсоток багів проникає на прод з тієї кількості, що була загальна.Таким чином ми будемо розуміти:який відсоток наших багів потрапляє на продакшн.Ця метрика дає можливість визначати, як часто баги прориваються на прод, згідно з цією кількістю.📌 Якщо ти хочеш поглиблено зрозуміти, як працювати з цією метрикою, як вона допомагає нам визначати баги — заповнюй анкету на безкоштовну персональну консультацію до мене 👇🏼https://forms.gle/boJPMtoKspT7tDeQ8

🧠 Як підготуватись до співбесіди так, щоб отримати свою омріяну роботу? Поради QA з 12-річним досвідомУ 2012 році я йшов на свою першу співбесіду, маючи в голові лише одне питання: «А що взагалі там питатимуть?» Гуглив списки питань, зубрив терміни, хвилювався.Сьогодні, маючи 12 років досвіду, я сам проводжу співбесіди і точно знаю, чого очікують від кандидата, і що допомагає виділитись серед десятків претендентів.🔹 Ось кілька практичних порад, які реально працюють: ▫️Розумій свою цінність. Не просто повторюй, де працював, а показуй, які проблеми вирішував ▪️Готуй приклади. Твої кейси — найкраще підтвердження твоїх навичок ▫️Знай компанію. Знання про продукт і бізнес показує твій інтерес, а не просто пошук «будь-якої роботи» ▪️Питання = інтерес. Продумай, що сам запитаєш. Це діалог, а не допит ▫️Впевненість. Її дає тільки хороша підготовкаІ головне — бути собою, але у версії 2.0: чітким, сфокусованим, професійним📌 Якщо готуєшся до співбесіди або вже мав невдалі спроби — приходь на мій розбір: Розберемо твої відповіді, підготуємо сильні кейси, і я покажу, як уникнути типових помилок.👉 Напиши мені «Співбесіда» — і домовимось про формат#qa #співбесіда #qaпоради #тестування

Чому новачки в ІТ залишаються без роботи? 🤔Після курсів здається, що ось-ось все буде — і робота, і оффер, і перша ЗП в доларах. Але проходять тижні, а відгуки — без відповіді. Знайомо?✅ Ось 5 причин, чому так трапляється:💻 Немає практики. Курс — це добре, але без прикладів реальних проєктів у портфоліо роботодавцю складно оцінити твої навички📉 Сире резюме. Часто або занадто загальне, або навпаки — повне технічних термінів, які ти сам погано розумієш⚡️ Пасивність. Просто відгукуватися на вакансії недостатньо. Потрібно бути активним: писати рекрутерам, нетворкати, бути видимим🚫 Провальні співбесіди. Боятись питань типу “Розкажи про себе” — це ок, але з цим треба працювати. Бо часто саме на цьому етапі все і зупиняється. Ви навіть не можете впевнено розповісти про себе, що вже говорити про технічну співбесіду💰 Завищені очікування. Всі хочуть одразу у великий проект і з хорошою ЗП. Але часто треба починати з простішого, щоб далі зростати. Маленькі компанії, швидше дадуть вам ріст і можливість працювати Якщо ти зараз у цьому стані — не панікуй. Я бачив сотні схожих ситуацій і знаю, як з цього вибратись.Пиши мені в телеграм @yakymchuk_roma «+» та я підкажу лайфхаки, як швидше знайти першу роботу та почати заробляти в ІТ 📩

Коли я тільки починав у тестуванні, всі мої тести жили в Excel'і. Сторінка за сторінкою, кольорові комірки, якісь формули, коментарі збоку. І тоді це здавалося нормальним. Поки не настав момент, коли:🔸 потрібно було швидко знайти конкретний тест — і я гортав десятки рядків🔸 менеджер попросив прогрес по регресії — і я малював діаграми вручну використовуючи чарти в ексельці🔸 з’явилась нова людина в команді — і я витрачав години, пояснюючи, “де що лежить”Тоді я вперше глянув у бік тест-менеджмент систем. І чесно — зміни були відчутні вже з першого тижня.Тест-менеджмент системи — це не просто зручність. Це структура, прозорість і масштабованість:✔️ Всі тести — в одному місці✔️ Зрозуміла структура — як для новачка, так і для ліда✔️ Можна бачити історію змін, запускати тест ранс, будувати звіти✔️ Легко пов’язати тести з багами, вимогами, задачами в Jira✔️ І головне — це економить час і нерви всієї командиЗараз я просто не уявляю, як можна ефективно працювати без такої системи, особливо коли проект не з одним-двома флоу, а великий, живий, складний.Тож, якщо ви досі працюєте в Google Sheets або Word — подумайте, скільки часу ви витрачаєте на те, що вже давно можна було автоматизувати.І не треба одразу щось велике типу TestRail. Є купа безкоштовних або доступних рішень — Testomatio, TestLink, Xray, PractiTest, Zephyr...Ваша робота заслуговує на зручні інструменти. А не на хаос з табличок 🧩

А навіщо ці Bug Triage мітинги?Часто на проекті настає час, коли накопичується дуже багато багів і ми маємо хоч якось їх менеджити. І ось для того щоб правильно впорядкувати та відсортувати баги, нам потрібно проводити ці Bug Triage мітинги. На такому мітингу мають бути присутні, QA, це може бути або лід або хтось хто добре знає систему, Dev або Tech Lead, PO продукт овнер.На мітингу в першу чергу звертають увагу на критичні дефекти та порядок їх виправлення. Тому що деякі баги можна відкласти, а деякі можуть бути вже не актуальні, і їх взагалі потрібно закрити.Задача мітингу актуалізувати ситуацію по багам, визначити пріоритет їхнього усунення, почистити дублікати або баги які вже не актуальні. Часто навіть під час мітингу вдається перевірити чи баг досі актуальний і або додати йому відповідний пріоритет або закрити, якщо він вже не актуальний.Bug Triage бажано проводити регулярно хоча б раз на тиждень. В результаті можна оформити табличку в Confluence з переглянутими багами та відсортувати їх за пріоритетами. Закриті баги та дублікати також вказуємо, щоб команді було зрозуміло, які вже неактуальні. Ну і щоб вони пам'ятали що ці баги були закриті і мати на увазі коли буде проводитись регресія, переглядати цей список, як ризикові.

Привіт колеги 👋Продовжуємо тему тест-менеджменту і сьогодні поговоримо про види стратегій тестування Аналітична Стратегія ◽️Узгодження тестування з чітко визначеними базисами тестування (Вимоги, дизайни, прототипи, діаграми і т. д.) ◾️Вимірювання тестування на основі тестових базисів (Матриця трасування вимог, матриця трасування багів по відношенню до тестів) ◽️Запобігання дефектам шляхом раннього аналізу тест базисів (Аналіз вимог, аналіз ризиків, дослідження за допомогою декомпозиції)Стратегія на основі моделей ◾️Моделювання на основі реальних статистичних даних, наприклад навантаження на систему, як от аналіз кількості клієнтів у магазині на чорну п’ятницю ◽️Аналіз вхідних і вихідних даних, наприклад шифрування конфіденційних даних або паролів користувачівМетодична стратегія ◾️Використання чеклістів та тест кейсів ◽️Використання чітлістівРеактивна Стратегія ◾️Використання тест чартерів та інших підходів дослідницького тестування ◽️Тест кейси розробляти згідно технікам основаним на попередньому досвіді або на попередніх дефектахКонсультативна Стратегія ◾️Зацікавлені сторони з бізнесової сторони надають інформацію по девайсам, платформам та іншим можливим конфігураціям, на яких потрібно провести тестуванняРегресійна Стратегія ◽️Використання аналізу залежностей для відбору тестів ◾️Використання пріоритезації і кластеризації функціоналуСтратегія Автоматизації ◽️API тестування ◾️UI тестування ◽️Інтеграційне тестування ◾️Мобільне тестування

Сьогодні хотів би підняти черговий раз таку тему, як Обговорення беклогу перед початком ітерації. Завжди коли я бачу в компаніях якісь проблеми з нерозумінням кінцевої мети по написаній документації або різне розуміння того, як мають бути реалізовані вимоги, то найчастіше у цих командах немає стадії на якій обговорюються вимоги.Чому важливо мати стадію обговорення вимог:- це дає можливість краще зрозуміти, що має бути виконано під час майбутньої ітерації- можливість обговорити існуючі вимоги та виявити якісь неточності або суперечності в них- обговорити з командою та можливо внести правки в вимоги- ну і найважливіше, розуміти що має бути реалізовано на командному рівні, коли всі обговоривши знають, як це має бути виконано і як буде тестуватися.Ну і найчастіші проблеми - це виявлення багів на більш пізній стадії, через нерозуміння вимог. Втрата часу на зайву комунікацію для вияснення проблемних моментів і знову ж таки на пізніх етапах розробки. Тому старайтеся, якомога раніше долучатися до розробки та підвищувати якість своїх продуктів.