Roman Yakymchuk Consulting

Друзі привіт, давно збираюся вам написати якихось корисних статей, але все руки не доходять. Вже підготовка до конференції на завершальній стадії.

Можна вас попросити накидати мені в коментарях, щоб ви хотіли дізнатися, про що почитати чи послухати. Я вам підготую пости по вашим запитам 😉

Заключний спікер на QA Magic - Євген Толчинський

Скільки разів ви чули:
“У нас багато багів”
“У нас високий тест кавередж”
“У нас багато тестів”

Я коли чую такі формулювання в мене починають випадати залишки волося 😁

Про шо ми поговоримо?
Про те що цифри мають нести інформацію і аналітику, а цифри в “вакумі” не потрібні

Ми подивимось на нестандартні метрики
- Швидкість виправлення багів
- Якість створення багрепортів
- Відсоток баг репортів, які не пройшли багрепорт ревью
- Bugness Index - а що це таке, я разповім :-)

Як змінити метрики? “У нас має бути мало багів” на “Кількість баг репортів зменьшилась на Х і якість не постраджала”

І звісно я відповім на ваші питання :-)
Тому готуйте їх

Я вже 5 років проводжу співбесіди різних QA engineer і розуміння метрик додає бонусів. А ще дуже часто PO, CTO не розуміють які метрики потрібні, до яких треба йти.

Тому, запрошую вас на мітап, уже 26 жовтня
https://conference.ry-consulting.online/

Ну що ж, 10 днів залишилось до QA Magic 6.0. Я завжди згадую ці емоції, які відчував на сцені, переживання перед кожним виступом, кожного разу наче вперше виходиш))

Мені дуже подобається та атмосфера і вайб, який відбувається на конфі. Люди спілкуються, задають багато питань, отримують дуже багато відповідей. Нові знайомства, нові знання, що може бути краще.

Отож чекаємо всіх офлайн та онлайн

​​На вихідних провів воркшоп по Дослідницькому тестуванню, і в мене є що вам сказати:

- 9 людей випробували 5 нових підходів, які раніше не використовували в тестуванні

- 9 щасливих людей, бо дізналися, що таке робота в парі і які бенефіти від цього можна отримати

- люди створили дуже круті описи своїх проектів використовуючи тестування на основі персон, та побачили, як за допомогою продумування потреб персон, можна розробити покращення та в деяких випадках навіть придумати нові фічі

- всі знають що таке тест тури, але як це застосувати саме на проекті, мало хто догадувався, а тепер вже навіть знають як назвуть свої тури

- у людей була звичка спочатку писати тести, а потім робити перевірки, а тут ти маєш перевіряти відразу після того, як придумаєш ідею, це дуже цікаво споглядати, але ще краще спробувати та побачити, як це впливає на результат

Ну що ж, я задоволений результатом, а хто хоче потрапити на такий двіж, то 19 жовтня вже знову набирається групка на воркшоп, вартісттю всього 2500 юашів

Став + в коментарях, якщо теж хочеш приєднатися та отримати купу інсайтів

Друзі привіт, на конференцію залишилось не так багато місць, і якщо ви помітили, спікери в нас просто 🔥
Я особисто дуже хочу послухати доповідь Антона, тому що ця тема дуже перегукується з моїм досвідом.

Раджу обговорити з колегами, та прийти разом на QA Magic, так як це класний отриманий досвід інших, і не тільки від спікерів, а й від нетворкінгу під час та після конференції.

Нагадую, що є також ОНЛАЙН квитики, тому ви можете дивитися конференцію з будь якої точки світу 😉

​​Наш наступний спікер - Антон Синявський

«Кожен раз, коли мова заходить про процеси, я чую різні відповіді.
Але, на жаль, дуже важко зрозуміти послідовність того, що на що впливає: документи, цикли, покриття? Дуже часто бачу, як створюють документацію, яка взагалі не використовується в процесі, але її все одно підтримують, витрачаючи час і ресурси всієї команди.
Коли питаю, навіщо це робити, всі хитають головами й кажуть: «Ну, так було зроблено до нас».

На співбесідах, коли я питаю про концепції, які використовують для побудови процесів, часто стикаюсь із здивованими поглядами.

Найскладніше починається, коли потрібно побудувати процес з нуля.

З чого почати?
На що звернути увагу?
Які інструменти використовувати?
Яку документацію створювати?
Яка послідовність?
Як відстежувати прогрес?

Чому це важливо?

З моєї точки зору, найбільша й найцінніша навичка QA спеціаліста – прийти в хаос і зрозуміти, як його приборкати, перетворивши на зрозумілу послідовність дій, яку можна контролювати і яка вирішуватиме практичні питання бізнесу.

26 жовтня ми заглибимося в тему систем і процесів. Я покажу на прикладі одного з моїх проєктів, як перетворити хаос на чіткий процес. Навіть через рік клієнт повернувся, щоб подякувати за процес, який продовжував працювати.

P.S. Якщо ви вже створювали процеси і щось не виходило, підготуйте свої питання  – ми їх також розберемо. З радістю поділюсь своїм досвідом»

Привіт! Настав час поділитися враженнями від курсу Test Analyst#17..
Курс надзвичайно інформативний та добре організований. Матеріал був поданий чітко та лаконічно: кожне наступне заняття логічно випливає з попереднього. Все систематизовано, що допомагає краще зрозуміти з якого моменту і як саме проводити аналіз та відповідно підібрати коректну стратегію тестування, що буде оптимізувати час на тестування без втрати якості.

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

Тому, щиро рекомендую цей курс всім, хто прагне розвинути навички тестового аналізу, систематизувати знання з теорії і підкріпити практикою з можливістю отримувати зворотний зв'язок по своїй роботі.

🚀 Хочеш прокачати свої навички в тест аналізі і стати ТОП-фахівцем на ринку?

Це саме той шанс, якого ти чекав! 🔥 Всього 2 місяці, і ти перетворишся на експерта з тест аналізу, здатного вирішувати найскладніші завдання!

У практичному курсі "Тест Аналіз" я зібрав усе, що допоможе тобі:
✅ Опанувати комбінаторику і оптимізувати тестові сценарії
✅ Створювати ефективні стратегії тестування
✅ Використовувати таблиці залежностей для покращення результатів
✅ І багато іншого, щоб позбутися монотонності у роботі і стати лідером в своїй сфері!

👉 Реальний практичний досвід
Цей курс — не просто теорія, а реальні кейси і завдання, з якими ти зіткнешся на своїй роботі. Домашки перевіряються індивідуально, і ти отримуєш повноцінні фідбеки та розбори від мене особисто.

🎯 Для кого цей курс?

Якщо ти відчуваєш, що твої знання потребують апгрейду
Якщо хочеш підвищити свою зарплату та вийти на новий рівень кар’єрного росту
Якщо тобі набридло повторювати одне й те саме кожен день і хочеться справжнього виклику
Тоді цей курс саме для тебе!

💥 Акційні умови: не пропусти!
На даний момент у тебе є можливість обрати зручний для себе варіант оплати:
💳 Розстрочка до 5 платежів
І обрати один з пакетів:
🔝 Пакет PRO: 16 повноцінних уроків, перевірка домашніх завдань, індивідуальні сесії — 22500 грн
🎯 Пакет LITE: 16 уроків без перевірки домашніх завдань — 15500 грн

🔥 Бонус для тих, хто зареєструється протягом тижня — персональна консультація абсолютно безкоштовно!

⏳ Не зволікай! Місця обмежені, і цей курс може стати тим самим ключем до твого кар'єрного прориву! Переходь за посиланням і дізнайся більше ➡️ https://test-analysis.ry-consulting.online/

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

Початок — Аналіз вимог
Перш за все, важливо уважно читати вимоги. На одному з проектів, де я працював, клієнт надав дуже загальні вимоги, через що команда тестування пропустила декілька критичних сценаріїв. Ми повернулися до аналізу і виявили, що специфікації інтерфейсу не враховували різні типи користувачів. Висновок: завжди варто підключати до процесу тестування якомога більше учасників, зокрема бізнес-аналітиків. При чому тестування ролей та прав доступу має свої певні особливості.

Виявлення пробілів та ризиків
На іншому проекті, де було розроблено складну CRM-систему, ми використовували техніку "аналізу залежностей”. Ми звернули увагу на перехресні залежності між модулями, і в підсумку тестування виявило кілька помилок у синхронізації даних між модулями. А також завдяки цій техніці ми завжди відбирали тести для регресійного тестування.

Тестування станів та переходів
Грамотно сформульовані тест-кейси за допомогою цієї техніки — це запорука успішного тестування. На прикладі роботи з фінансовим проектом, де у нас сутність мала багато різних транзакцій, нам вдалося виявити, що певні дії не правильно виконуються в певних станах, що могло призвести до критичних наслідків. Якби не використання цієї техніки, нам би не вдалося виявити всіх проблемних місць у системі, та ми б дорого за це заплатили.

Візуалізація процесів у вигляді майндмепів
Ще один успішний кейс — це візуалізація процесів у вигляді діаграм. На проекті з розробки системи для індексації даних, діаграма взаємодії між модулями допомогла нам зрозуміти, де можуть бути потенційні точки відмови, і ми змогли краще підготувати сценарії тестування для цих зон. А також через глибоку декомпозицію нам вдавалось виявити де є пробіли в системі з недокінця продуманою логікою.

Колеги привіт 👋

Хочу вам нагадати, що сьогодні останній день дії ранньої ціни на квитки QA Magic
Цього разу будуть дуже сильні доповіді від спікерів та чудовий нетворкінг.

А зараз можна поглянути як це було минулого разу 🙃

​​Наступний наш спікер - Артем Овчаренко

Мене вкрай дістали співбесіди під час яких JS автоматизатори від джуні до сіньйора (доречі, джуни показують кращі результати 😁) не можу відповісти на питання, що таке проміс! В кращому випадку люди можуть повторити визначення або пояснити власними словами. Проте коли діло доходить до глибшого розуміння та використання на практиці - це повна лажа.

Маленька ремарка - не всі автоматизатори, але напревеликий жаль багато.

Чому це важливо?

Якщо подивитись автотести написані на JavaScript 70-80% коду буде асинхронним і відповідно використовувати проміси. Для 80% автотестів, глибоке розуміння цієї матерії непотрібне, ставимо await і все працює. Проте, з збільшенням кодової бази вашого проекту, з ускладненням задач, які ставлять перед командою автоматизації, зростають вимоги до вас, як до інженера і відповідно просто поставити await вже не достатньо, оскільки це не вирішує проблеми.

В моєму досвіді було декілька випадків, коли незнання та нерозуміння концепції промісів призвело до неймовірної нестабільності тестів. Уявіть 200 end2end автотестів і кожен запуск, рандомно падає приблизно 50-70%. Менеджмент навіть зневірився в можливостях автоматизації, хоча проблема була в знаннях і вміннях автоматизаторів.

Отже, 26го жовтня, заглибимось в цю тему, розберемо, що ж таке ті проміси і асинхронність, а також розглянемо різноманітні тонкощі їх застосування.

Доречі, буде корисно й тим, хто пише більш складні (з використанням JS скриптів) автотести на Postman.

Всім привіт!

Вчора переглядаючи цей відосик, підписники почали помічати дуже цікаві деталі
- відео дзеркальне, тобто його скоріш за все знімали на фронтальну камеру
- замість мікрофона, у хлопака зубна щітка
- видно в дзеркалі, що у нього біленькі носочки

Дуже важливо бути уважним та спостерігати за деталями. Найкраще такі деталі виявляються під час дослідницького тестування, коли ми починаємо працювати та досліджувати поведінку системи. Дивимось як відпрацьовує та чи інша функція, і в результаті спостереження, робимо додаткові дії, саме на основі отриманої інформації. Таким чином ми більш детально поглиблюємося у контекст свого проекту, детально вивчаємо його та знаходимо різні нестикування.

Доречі, на воркшоп по дослідницькому тестуванню, про який я писав вище, дуже швидко зібралася група, та тепер створився додатковий список очікування на наступний раз. Тому, хто хоче попрактикуватися у різних нових для себе підходах, записуйтесь 😉

Було таке? 😁

Оце я розумію! У когось щастя - це просто приїхати на QA Magic 🤗

Тому нагадую що квиточки зі знижкою ще можна придбати до 10 жовтня 😉

Наступний наш спікер - Ріна Ужевко

Наприкінці 2019 р. стався мій особистий переломний момент у ставленні до того, що я роблю.

З 2017 року я була на дуже великому проєкті, і в нас був дуже активний найм людей і дуже швидкий.
За найпіковіший місяць в команду тестування долучилось понад 40 людей різних грейдів. В нас тоді був якийсь процес онбордингу і він якось працював, але він був зроблений менеджером до мене, і мав (як виявилось) багатенько гепів.

В результаті аналізу, я почала перероблювати його повністю, - ми закінчили проєкт і я пішла працювати вже з іншими, коли зі мною зв'язалась компанія і попросила допомоги.

В результаті, вже після закінчення мого проєкту, процес перенесли спочатку для одного IT відділу, згодом — цю систему застосували на всіх рівнях компанії, що охоплює тисячі співробітників.
Зауважу, що я була аутстафером, а компанія, продуктова.

Що ж було такого, чого в них не було до мене?
- розуміння, що саме повинно бути в процесі онбордингу
- з яких саме етапів він складається
- не було зворотнього зв'язку
- не було досвіду онбордингу одночасно такої кількості людей різних грейдів
- не було розділення обов'язків
- певної документації та чек-листів індивідуальних для кожної людини

🔗 Про весь цей процес я розкажу на конференції QA Magic Meetup 26 жовтня, "Впровадження процесу адаптації на великому проєкті", де ми детально розберемо всі етапи та ключові стратегії.
Це ваш шанс поглибити знання і впровадити ці зміни у ваших проектах.

Часто чую від колег, що вони прям дуже переживають за те, що клієнт знайде баг.
Але основне питання яке їх лякає це "Як ти так тестував/ла, що пропустив/ла баг?"

Люди відразу стають в ступорі і не знають, що на це відповісти.
Ну по-перше ви повинні мати якісь артефакти, щоб показати, як саме ви тестували та що саме ви робили. Для цього потрібно вести тестову документацію та показати людині, яка у вас запитує, ваші чеклісти чи тест кейси. Бажано підготувати список знайдених багів під час тестування, щоб було видно результати вашої роботи.
Також, ви можете обговорити з вашим клієнтом план вашого тестування, розпитати, які користувацькі сценарії є, про які він можливо не розповідав.
Також коли наприклад девелопер не правильно зрозумів завдання, вам потрібно це проговорити та вияснити, що саме мав на увазі клієнт, щоб не було такого, що баг виник тому, що хтось не правильно зрозумів суть завдання.
Ну і врешті решт, всі ми люди і можемо пропустити якусь помилку, головне зробити з цього висновки та виявити причину, щоб наступного разу її не повторювати

Друзі привіт, до мене прийшов запит на воркшоп по Дослідницькому тестуванню, тому якщо хтось хоче відвідати воркшоп, заповнюйте гугл форму, там всередині опис що буде і ціна
https://forms.gle/4JJzrgnyadTbPt9T9

Накидаю трохи анонсів, що планується на цей місяць

Основна подія місяця це QA Magic Meetup, дуже хочеться, щоб по максимуму прийшло людей та відвідало онлайн
26 жовтня, дуже круті допопвіді від експертів галузі

28 жовтня дуже хочу запустити курс по Тест Аналізу, як показала практика останніх 17 груп, всі задоволені практичним досвідом, який отримують в результаті навчання. Особливо ті, хто працюють зі мною по своїм проектам

15 жовтня Тест Марафон, хоч і в записі, але пишаюся результатами студентів, хочеться, щоб кожен пройшов ці 12 уроків досвіду

Кому потрібна буде консультація, пишіть, знайдемо час для вирішення ваших задач і проблем

Друзі привіт

Всіх причетних вітаю зі святом і дякуємо всім хто захищає 🇺🇦
Всім полеглим велика вдячність і пошана 🙏🏻

Борітеся - поборете, Вам Бог помагає

📊 Персональна ефективність

Привіт друзі! Цього літа я вперше за довгий час шукав собі нову роботу. До цього я дуже пишався своїм резюме:
✅ в ньому описані мої навички та багатий досвід
✅ воно було концентроване - лише 3 сторінки
✅ воно мало непоганий дизайн

Але я вирішив, що хочу мати щось набагато крутіше. Тож почав з оптимізації контенту. На щастя, зараз є десятки сервісів-аналізаторів, куди можна завантажити резюме і отримати його оцінку. Я був впевнений, що зараз ШІ тільки гляне на моє CV, пустить скупу цифрову сльозу радості і видасть мені оцінку 99/100. Але я отримав лише ~25%. Але чому так?

Причина дуже проста - моє резюме не містило конкретних досягнень. Тобто, працював я в різних проєктах. Брав участь в низці успішних релізів. Але чи це моя заслуга? Може я просто поруч стояв, поки інші вкалували? Як це виміряти?

Всі аналізатори зараз дають поради та приклади на кшталт:
- "завдяки моєму менеджменту, зменшив час регресійного тестування в 3 рази"
- "мій тест дизайн допоміг досягти 90% покриття продукту тестами і збільшити якість на 27%"
- "моя стратегія тестування призвела до зменшення кількості критичних багів на 95%"

Всі приклади вимагають від власника резюме посилань на конкретні метрики - що конкретно ви зробили і як це вплинуло на продукт? Це те, що давно вже є нормою в розвинених країнах і те, чого в Україні я майже ні в кого не зустрічав. Ба більше, не всі (і навіть я) навіть рахують такі метрики, якими можна потім пишатись.

А значить, ми маємо просту та очевидну думку - настав час кожному інженеру усвідомити необхідність збирати такі метрики і почати щось робити в цьому напрямку. В своїй ролі хеда практики тестування, я починав це впроваджувати, тож маю ідеї і практичні поради, якими і хочу поділитись з вами у найближчому майбутньому. Найбільш імовірно, зможу це зробити на Magic Meetup 6 вже скоро, а трохи пізніше і розлогий пост напишу.

А поки бережіть себе
допомагайте ЗСУ
Слава Україні! 🇺🇦