​​- Ти перевірив чи пофіксився баг?
- Так перевірив, не працює
- А що пише?
- Інтернет з'єднання відсутнє
- А ти перевірив чи є в тебе світло?
- От бл#а. Йоб#.а рсня. Вже все працює
- 😂😂😂. Тобі аби баги заводити

Як знайти справжні причини проблеми?

Всім привіт 👋🏻

Аналіз першопричини (Root Cause Analysis) – це процес, який допомагає людям зрозуміти справжні причини проблеми, щоб дізнатися, чому ця проблема взагалі виникла.

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

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

Отже перше що потрібно це визначити проблему. Питання які допоможуть нам визначити проблему:
⁃ Що за проблема?
⁃ Як ця проблема впливає на потреби наших клієнтів?

Другий крок це збір даних про проблему. Виписуємо всі відомі нам характеристики та деталі проблеми. Задаємо такі питання:
⁃ Які сприяючі фактори?
⁃ Коли ця проблема виникає?
⁃ На що вона впливає?
⁃ Чи постійно вона повторюється?

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

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

П’ятий крок це приорітезація причин. Ми виявляємо вплив однієї причини на іншу і таким чином доходимо до основної першопричини.

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

Друзі привіт 👋

У цю суботу хочу провести невеличкий мітап по Оцінюванню Тестування.

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

Зустрічаємось у цю суботу об 11:00 zoom

Вартість - Добровільний донат на банку, всі кошти підуть на ЗСУ

Можна кидати сюди
https://send.monobank.ua/jar/9ZzUK3aVLQ

❗️Запис буде

Ставте + в комент хто планує бути

Друзі вибачте за непередбачувані обставини, які виникли під час івенту, але це робить нас тільки сильнішими. Це я погано прорахував ризики 😂

Але як і обіцяв, ось запис
Лінка на донат https://send.monobank.ua/jar/9ZzUK3aVLQ

Що таке якість?

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

Через це нам дуже важливо розуміти, що саме хочуть наші замовники. Це поняття називається голос замовника VOC (voice of customer).

Однак VOC може бути досить розпливчастим. Наприклад, клієнт може сказати, що продукт (або послуга) має бути:

• Зручний для користування
• Мати класний вигляд
• Мати щось таке, що мої конкуренти будуть заздрити

Наведені вище приклади являються розпливчастим VOC. І для того щоб команда розробки зробила дійсно якісний, зручний для користування та класний на вигляд продукт, це вимагає від нас перекладу VOC на так звані фактори, критичні до якості (CTQ). У наступній статті розповім як це зробити

Критичні фактори якості:

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

Давайте розглянемо на прикладі програми Loom.
Замовник хоче:

1. Щоб продукт був зручний для користування.

Отже ми починаємо задавати додаткові питання, що значить зручний?
• Хочу щоб можна було записувати екран
• Хочу щоб також можна було записувати того хто говорить
• Або ще краще, щоб записувався і екран і того хто говорить
• І щоб можна було перемикатися швидко між цими 3 типами та не зупиняти запис відео

Це ми виявили CTQ для першочергового розмитого поняття замовника.

Давайте розглянемо інший VOC

2. Продукт має мати щось таке, щоб мої конкуренти заздрили

Що мається на увазі, зворотній зв’язок по відео?
• Можливість залишати комент для якоїсь конкретної секунди відео
• Можливість залишити реакцію для якоїсь конкретної секунди відео

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

Ми доречі на курсі по тест аналізу практикуємо такі питання, коли робимо брейнштормінг та більш детально розбираємо критичні характеристики якості продукту.

Старуємо останній у цьому році курс по тест аналізу 🔥

Починаємо 10 грудня❗️

Це ваша можливість продуктивно зафіналити 2022 рік не дивлячись на ситуацію навколо, та вже у 2023 стати більш крутим спеціалістом та підвищувати свій рівень доходу завдяки крутим навичкам та новим знанням ❗️

На курсі по тест аналізу ми з вами НА ПРАКТИЧНИХ ПРИКЛАДАХ, без води, розберемо 4 повноцінних модулі, а саме:

1. Комбінаторика
2. Аналіз залежностей
3. Стратегія та планування
4. Інструменти оптимізації

Більш детально про них ви зможете глянути на сайті https://test-analysis.ry-consulting.online/

У цей раз, у перше, на курсі будуть діяти 2 тарифи:

Пакет PRO - Це 16 повноцінних уроків з перевіркою домашніх завдань і 3 сесій розборів і відповідей на питання.
Вартість 15500 грн. 💰

Пакет LITE - Це 16 повноцінних уроків і 3 сесії розборів і відповідей на запитання, але без перевірки домашніх завдань
Вартість 10500 грн. 💰

❗️Важливо - для вашого комфорту, на курсі діє внутрішня розстрочка❗️

Хто хоче більш детально дізнатись про курс, пишіть ➕ у коментарях, або у особисті @yakymchuk_roma

Треба завжди бути трохи голодним!

Цю фразу почув приблизно місяць тому і довго намагався зрозуміти як саме це працює🧐

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

Так само і в житті, наступає момент коли ми досягаемо певного рівня життя ми зупиняємось у подальшому рості і з часом, ну от 100%, життя починає потроху втрачати барви.

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

1. Великі мрії. Моя наприклад, у найближчі 5 років збудувати собі будиночок у лісі щоб їздити туди на вихідні

2. Навчання. Це як один із способів швидше досягати своєї мети, так і один із способів розширити межі своєї уяви

3. Подорожі. Але поки на паузі

4. Сім'я. Час проведений разом безцінний ♥️

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

А де ви берете мотивацію?

Події які ви не можете передбачити

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

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

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

Я вже розбирав декілька методів дослідницького тестування, ви можете знайти їх використовуючи тег #exploratorytesting

про який би хотіли дізнатись більше у наступній статті?

- Exploratory Testing Tours
- Mind Mapping
- Brainstorming

Пишіть у коментарях і на днях розберемо 😉

Test Estimation на практиці🔥

Всім привіт, наступного вівторка, пропоную вам зібратися на мітап на тему оцінювання тестування.

Цього разу ми проведемо його у парі з експертом у темі QA з досвідом 10+ років Артемом Григоренко

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

І також, додатково розглянемо ряд питань:

Хто повинен цим займатися, вся команда чи QA Lead?
Як оцінювати тест активності на проекті?
Які інструменти використовувати для оцінювання?
На що потрібно звернути увагу при оцінці?
Як покращити результати оцінювання?

Збираємось 20.12 о 19:00

Вартість, добровільний донат на ЗСУ від 10 гривень😉

https://send.monobank.ua/jar/9pYvAJtaaX

Приєднуйтесь, давайте допомагати ЗСУ та навчатися разом🔥

Пишіть + у коментарях, хто бажає доєднатися

Доречі, Артем також веде свій канал в телеграм і ділиться своїми нотатками https://news.1rj.ru/str/a_grygorenko

Гайз 👋

Нещодавно ви просили, щоб із дослідницького тестування я розібрав вам Mind Mapping.

Я записав невеличкий але максимально інформативний відос у якому розібрав, як ефективно використовувати Mind Map у вашій роботі.

15 хвилин користі для вас😉

Пишіть у коментарях, як часто і де, використовуєте цей інструмент?

https://www.loom.com/share/f6b2876bca124611b5b7590391464ce8

Гайз👋

Нагадую, що вже у вівторок ми з вами збираємось, щоб розібрати Test Estimation на практиці🔥

Спікери на мітапі: Роман Якимчук та Артем Григоренко - сумарний досвід роботи у QA понад 20 років 😎

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

Починаємо о 19:00

Умови участі: donation на ЗСУ 🇺🇦

Давайте навчатися разом😉

Всім привіт, сьогодні у нас по плану мав бути zoom про оцінювання тестування.

Але через й##%ну рсню в мене вже другу добу немає світла. Вирішили записати вам ефір вдвох.

Як на мене вийшло дуже круто! Можете переглянути це відео тут
https://youtu.be/lM1rjaqbt0A

І не забувайте донатити, ми збираємося всі гроші передати на допомогу нашим воїнам 🙏🏻

https://send.monobank.ua/jar/9pYvAJtaaX

Друзі, хто вже подивився, накидайте коментів, як вам?

Всім привіт,
Дякую за ваші донати!

Всі виручені кошти були направлені для 46-Ї бригади десантно-штурмових військ, вони зараз під Бахмутом. Попросили докупити акумуляторів до рацій, ми долучилися до збору

Слава Українським воїнам 🇺🇦

Одного разу 👉

Коли в мене було велике навантаження на проекті, я спробував впровадити одну досить цікаву річ.

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

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

Це звичайно вимагало трохи більше часу, але в перспективі ми отримували більш якісний продукт і не приходилось заводити 100500 багів і потім перепровіряти їх після фіксів, що добряче економило нам час.

Мені як інженеру з забезпечення якості такий підхід більше подобається, ну і розробникам краще, так як після завершення задачі їм не приходиться фіксити багато багів. Win-win ситуація 💪

А які ви прийомчики використовуєте для підвищення якості своїх продуктів, діліться в коментах 👇

Друзі, вітаю вас із наступаючими новорічними святами.

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

Було написано багато корисних статей, проведено цікавих вебінарів та тренінгів. Дякую, що слідкуєте за каналом та розвиваєтесь разом зі мною❤️

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

Всіх з Новим Роком! І нехай буде перемога 🇺🇦

Всім привіт👋

Потроху починає закінчуватись олів'є і більшість починає входити у активну робочу фазу 😎

Написав вам тут невеличку статтю, як ефективно застосовувати техніку Brain Storming на ваших проектах, щоб досягати більш кращих результатів у роботі в 2023-му.

https://telegra.ph/Mozkovij-shturm-01-02

Як прочитаете, діліться у коментарях як часто використовуєте дану техніку на проекті і чи застосовуєте її взагалі 😉

#QualityAssurance #brainstorming #exploratorytesting

Воркшоп по Brain Storming

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

Як це буде відбуватися:

▪️ Ми виберемо напрямок наших проектів;
▪️ Кожен випише ряд ідей фіч, які там будуть використовуватись;
▪️ Інші учасники нагенерують ідей по кожному з проектів;
▪️ Зробимо групування та фільтрацію ідей;
▪️ Кожен представить свій проект після брейнштормінгу.

На вас чекає півтори години цікавої практики, де ми будемо працювати у групі та ефективно використовувати мозковий штурм.

Вартість: 300 грн💰

Кому цікаво потрапити на воркшоп, пишіть + у коментарях🔥

А як вам працюється з нового року? 😂

Чому важливо розуміти сценарії користування?

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

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

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

Чому варто розглядати сценарії користування?

В традиційних вимогах до програмного забезпечення часто функціонал описується без контексту:
«Система повинна зберігати результати транзакцій оплат в системі трекінгу банківських операцій»

Відсутність контексту створює місце для двозначності і виникає багато додаткових запитань:

⁃ Коли відбувається ця подія?
⁃ Чи важливий порядок запису відносно інших транзакцій?
⁃ Хто ініціює подію?
⁃ Що відбувається, коли система трекінгу банківських операцій недоступна?

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

Переваги моделювання користувацьких сценаріїв

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

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

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

#QualityAssurance #usecases