Вчора було надзвичайно круто та душевно 🙏🏻

Дякую велике всім хто був офлайн та онлайн, надіюсь вам всім сподобалось ❤️

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

Гайз привіт 👋

В суботу провели 4ту зустріч QA Magic MeetUP 4.0

Буду ділитися з вами презентаціями і коротко розповідати про доповіді.

Почну зі своєї 😉

Я цього разу обрав тему Zero Bugs
Якщо коротко то це про те, що всі баги мають бути пофікшені до релізу і не переносити ті баги з спринту в спринт.

Розповідав про різні стратегії Quality Prevention, що можна робити, щоб запобігти виникненню помилок 🪲

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

Все це можна подивитися в записі, якщо хочеш подивитися всю конференцію, пиши мені @yakymchuk_roma

Друзі у цю Пʼятницю проведу ранкову QAvu в Чернівцях

Кому цікаво, пишіть +

Як часто ви користуєтесь техніками тест дизайну на своїх проектах?

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

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

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

За 2 місяці роботи вже почав вимальовуватись базовий функціонал, наша команда тестувальників почала активно розвиватися, з 6 тестувальників ми виросли до 8 і + ще взяли 2 мобільних тестувальники. Мене також закинули до мобільної команди на підмогу. Але все ж я був 70% на вебі і 30% на мобільних.

Я завжди стараюся використовувати всі можливі техніки тест дизайну де вони тільки можуть бути застосовані. Таким чином це дозволяє мені не аби як зекономити час на тестуванні.
Взагалі за 11 років State Transition мене вже стільки разів виручав, що я вже знайшов біля 50 критичних помилок, використовуючи тільки таку техніку і це завжди неочевидні баги, які можна знайти тільки вміючи використовувати саме цю техніку. Також Еквівалентне розбиття та граничні значення - це номер 1 по кількості знайдених помилок за всю мою кар'єру. Майже на кожному проекті та що тут, майже на кожному спринті я знаходжу баги використовуючи ці базові техніки.

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

Так от, коли я прийшов до мобільної команди, вони мені скинули чеклісти для перевірки нашого додатку. Я після того як відкрив, чесно кажучи я трохи ух...їв, представте собі кількість тестів 100 штук на одну маленьку формочку. Коли як застосував тільки домений аналіз, в мене вийшло з тих же самих 100 штук всього 12 тестів, що на секундочку майже в 9 разів зменшило їх кількість, а одже зекономило мені кілька годин на тестування.

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

Благодійний вебінар на тему:

«Як економити час за допомогою технік тест дизайну»

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

Мета вебінару: дати вам корисних знань і порадувати діток, привітавши їх з Новим Роком!

Звертаю увагу на те, що донати добровільні і не обовʼязкові 🙃

Коли: в неділю об 11:00

Де: zoom.

Хто планує доєднатися, ставте 🔥 в коментарях.

Посилання на банку для донатів:
https://send.monobank.ua/jar/9rGhVn8qUV

Карта банки:
5375411212621416

Завтра зранку збираємось на ранкову каву в Чернівцях, разом з @popeliuha

Кому цікаво отримати відповіді на свої QA питання приходьте. Все буде у вигляді круглого столу де кожен учасник буде давати свій зворотній звʼязок на запит 😉

Чекаємо всіх бажаючих в ресторанні Shiller, вулиця Шілера 7, Чернівці

Час: 10:30 ранку
Тривалість: ~2 години

Сьогодні класно побалакали та можна вважати QA Club Chernivtsi відкритим ✅

Рекомендую всім їздити та підтримувати QA спільноту в Україні 😉

Друзі, це посилання на донат, зараз скину запис етеру 🙏

Як економити час за допомогою технік тест дизайну

Всі хто був на етері запитували про вокшопи, ось інформація та ціни 🫵

Цього року 26 та 27 грудня, я хочу провести свої 2 завершальні тренінги по Тест дизайну та Дослідницькому тестуванні

26 грудня 18:00-21:00
Воркшоп по Технікам тест дизайну

- Еквівалентні класи
- Граничні значення
- Таблиці рішень
- Попарне тестування
- Тестування станів та переходів
На практичному воркшопі ви дізнаєтесь та зможете на практиці навчитися застосовувати усі техніки тест дизайну.

Тривалість воркшопу: 3 години
Вартість: 2000 гривень


27 грудня 18:00-22:00
Воркшоп по Дослідницькому тестуванню

- Тестування на основі сесій
- Тестування на основі персон
- Мозковий штурм
- Парне тестування
- Дослідницькі тури
На практиці використаємо дослідницький підхід та побачимо результати, які можуть принести нам ці інструменти

Тривалість воркшопу: 4 години
Вартість: 2000 гривень

Кількість місць обмежена, тому поспішайте 😉

Хто хоче продуктивно завершити рік, пишіть мені 👇
@yakymchuk_roma

Сьогодні хочу з вами поділитися, топ 10 пунктами по тестуванні UX

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

Бачу всі вже почали підводити підсумки 2023 року, але я поки ще не готовий до цього 😂

Поділюсь з вами своїм власним баченням Трендів тесування в 2024 році

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

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

Shift Left Testing
Насправді нове - це давно забуте старе. Всі ми знаємо, що чим раніше ми почнемо тестувати тим краще, але сам підхід більше про взаємодію з сусідніми ланками, наприклад розробник з тестувальником, розробник з дизайнером, дизайнер з бізнес аналітиком, якщо ми здвинемось трішки вліво то якість точно збільшиться.

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

In-Sprint Test Automation
Це варто уваги, тому що ми всі знаємо що тут і вручну деколи неможливо встигнути протестувати все якісно, а тут ще й автоматизувати спринт в спринт нереально. Але саме завдяки грамотній взаємодії девелоперів, автоматизаторів та бізнес аналітиків, можливо продумати всі нюанси та писати автоматизацію ще до того як девелопер почав писати свій код. Детальніше розповім про цей підхід вже в наступному році

QAOps
Це фреймворк, який включає ще додаткові процеси забезпечення якості вже в існуючий DevOps процес. Коротко кажучи, паралельне тестування, плідна взаємодія з девелоперами, девопсами, архітекторами і всіма членами команди задля покращення якості на ранніх стадіях. Також додаткові введення репортів та розуміння регресійного тестування і використання того самого імпакт аналізу - це все про QAOps

Пишіть свої прогнози в коментарях, та діліться даним постом і зберігайте собі для порівняння через рік 😉

Друзі, всіх вітаю з новим роком!

Плани грандіозні, тому до скорої зустрічі 😉

Гарно відпочиньте і будемо продовжувати здобувати нові знання у новому 2024 🐲

Друзі привіт 🙋‍♂️

Сьогодні хочу поставити собі цілі і тим самим мотивувати вас зробити собі дорожню карту на цей рік 🗺️

Минулого року я випустив 400 учнів
План цього року 800

Минулого року я додав 4 продукти та 1 конференцію
Цього року хочу вивести +7 продуктів + запросити кілька спікерів іноземних на конференції

Минулого року виступив 5 разів на конференціях
Цього року план 8 разів, 1 раз міжнародна

По роботі хочу отримати офер на позицію QA Director

Минулого року, як ціль собі я поставив Mercedes GLE 350 - ціль досягнута
В цьому році я хочу почати будувати будинок

В минулому році я задонатив 800 000 гривень
В цьому році план 1,500,000 гривень

В минулому році я потрохи почав додавати спорт після травми локтя, але тепер маю травму коліна 😭
В цьому році ціль по спорту жим 105кг
Вилікувати коліно і стати на лижі

По навчанню в минулому році вступив в університет на Менеджмент підприємництв та організацій - дуже радий цьому
В цьому році додам ще навчання у менторів всесвітньо відомих QA

Якось так, що у вас, діліться в коментарях 😉

Привіт гайз 👋

Для мене завжди, одним з найважливіших навиків було вміння комунікувати.

Чому я вважаю, що цей навик має один з найвищих пріоритетів?

Давайте спробуємо розібрати декілька ситуацій

Кейс 1й: До вас прийшли вимоги, ви починаєте їх читати та вивчати кожен пункт (Acceptance Criteria), щось з того прочитаного вам нічого не зрозуміло. Ви намагаєтеся добре все ще раз обдумати, витрачаючи годинку - другу, але всерівно є не зрозумілими певні моменти і ви ніяк не можете придумати, як описати це тест кейсом. Пишите як не будь той тест кейс і переходите до наступних вимог. Приходить час тестувати і ви знову зіштовхуєтесь з проблемою, бо тепер не розумієте як вам те все протестувати по незрозумілому тест кейсу.

Кейс 2й: Ви переглядаєте дизайн і бачите що поведінка системи описана в дизайні не зовсім для вас зрозуміла, але так як дизайн являється теж вимогою, ви пишете по ньому тест кейси. Після релізу до вас повертається баг з продакшена, тому що користувачу точно так же, як і вам, не зрозуміла поведінка системи.

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

Кейс 4й: Ви приходите до Продакт Овнера з проблемою і кажете, це не працює, не пояснюючи, що саме не працює і як воно має працювати. Продакт дивиться на вас і каже йди до девелопера і скажи йому нехай починить.

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

Давайте тепер розберемо кожен кейс, якби ви просто застосували комунікативні навички

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

2. Якщо ви бачите що щось не зручно або відображається не так як вам здається, підходьте обовʼязково до UX дизайнера і кажіть про це, ви як і користувач маєте отримувати задоволення і мати зрозумілу поведінку системи, інакше ж ви не будете користуватись незручним додатком.

3. Перед тим як заводити купу багів потрібно знайти першопричину, і впевнитись що інші баги, які ви завели, можливо вже є наслідком однієї проблеми, і ви просто не розібравшись позаводили купу непотрібних дефектів. Спілкування з девелопером і бізнес аналітиком, має розставити всі крапки над «і» та ви зможете бути певним в тому що тестуєте.

4. Перед тим як підходити до когось з питанням, спочатку потрібно розібратися з проблемою і чітко поставити те запитання, бо від того як ви поставите ваше запитання залежить відповідь

5. Як ви знаєте тестування показує стан системи і саме тестувальник має казати чи готовий продукт до використання чи ні. І якщо ви бачите, що ви не встигаєте протестувати, потрібно зарання попередити про це свого менеджера, та спробувати перенести реліз, бо здавати продукт недороблений або з багами, це безвідповідально. І чим раніше ви скажете про проблему тим більше шансів її правильно розрулити 😉

Дякую за увагу, пишіть свої випадки, де через недомовки ви потерпіли поразки?

Гайз, давайте розпочнемо цей навчальний рік з прокачки англійської😎

Давайте без довгої прилюдії, про важливість вивчати англійську і т.д, ми всі тут дорослі люди 😌

У цей четвер, пройде вебінар від нашої крутої спікерки з ІТ Інгліш - Мирослави, на тему:

Technology in Our Daily Lives

Під час вебінару ми:

•вивчимо 10-15 сучасних актуальних фраз;
•потренуємось їх використовувати, обговорюючи вплив технологій на наше життя;
•розберемося, від чого залежить легке розуміння англійської на слух;
•обговоримо "секретні секрети" легкого запам'ятовування нових слів і фраз.

Коли: в четвер 11.01 о 19:00 📍

Хто планує доєднатися, кидайте + в коментарях і го прокачувати інгліш разом😉

QA Retreat з Романом Якимчуком

Гайз, з 1 по 4 лютого запрошую вас на дуже круту двіжуху, яка буде проходити в найбільш мальовничих горах світу - Укрїнських Карпатах

На вас чекає 3 дні максимально плідного та цікавого навчання і 1 день відпочинку в комʼюніті крутих тестерів, що дозволить вам отримувати більш круті результати на проектах і швидше зростати в карʼєрі

🔹День перший:

Тест аналіз
Декомпозиція продукту
Різні техніки комбінаторики
Доменний аналіз
Комбінаторика на основі ризиків
Попарне тестування та Таблиця рішень
Аналіз залежностей між фічами (Impact Analysis)
Косбраузерне/кросплатформене тестування
Тестування ролей і прав доступу

🔹День другий:

Тест менеджмент
Планування тестування
Оцінка тестування
Стратегія тестування
Тест дизайн
Тест аналіз
Підготовка тестових даних і середовищ
Виконання тестування
Аналіз результатів тестування
Завершення тестування
Взаємодія з командою проекту
Автоматизація тестування
Ретроспектива

🔹День третій:

Дослідницьке тестування
Тестування на основі сесій за допомогою Чартерів
Тестування на основі персон
Парне тестування
Тестування за допомогою тестових турів
Брейнштормінг
Планування дослідницького тестування

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

🔹 День четвертий
Поїздка на екскурсію до сірих та бурих ведмедів, озеро Синевир, музей старе село, прогулянки по селу між горами та ріками 🥰

Коли: з 1 по 4 лютого
У вартість включається проїзд проживання та 2х разове харчування

К-сть місць: усього 15

Локація: Колочава, Закарпатська область

Вартість: 350$ до 20 січня
400$ до 31 січня

Хто бажае дізнатись більше інфи пишіть мені в дірект @yakymchuk_roma