Софт скіли

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

Які саме софт скіли потрапляють у топ на мою думку:

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

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

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

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

- Хто кінцевий користувач програми?
- Як вона буде використовуватися?
- Які найпоширеніші конфігурації браузера чи операційної системи?

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

А які софт скіли важливі на вашу думку?

Друзі привіт, дублюю текстом

У цю суботу збираємося на корисний мітап по метрикам (деталі того що розберемо у кругляшку)😉

Коли: у цю суботу 12.11
Вартість: донейшн на ЗСУ, будь яка довільна сума.
Початок: о 12:00

Приєднуйтесь та давайте вчитися разом 😉

Всім привіт😎
Сьогодні в Україні дуже гарні новини 🍉🇺🇦

Друзі, хочу нагадати вам, що завтра о 12:00 збираємося з вами на мітап по метрикам тестування!

Вартість, донейшн на ваш розсуд, усі отримані кошти підуть на волонтерський фонд https://instagram.com/trushnaperemoha

Гроші збираємо на банку: https://send.monobank.ua/jar/9JDnSjm97s

Посилання на зустріч закину завтра вранці

Давайте навчатися та допомагати Україні разом😉

QA Metrics

Вийшло доволі продуктивно. Тому не соромимось донатимо 🙏🏻❤️🇺🇦
https://send.monobank.ua/jar/9JDnSjm97s

Гайз👋

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

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

Тестування на основі сесій - це одна із технік дослідницького тестування, що дозволяє структуризувати ваші тести.

Сесія, це якась частина вашого тестування, яка виконується в рамках визначеної вами тривалості (30, 60 чи 90 хвилин), впродовж якої, будь які відволікання на смс, емейли, вхідні дзвінки чи відволікання вашими колегами не допустимі.

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

Тестування на основі сесій робить дослідницьке тестування структурованим та примінимим навіть на великих складних проектах де команди працюють в режимі Agile.

Хотіли б спробувати тестування на основі сесій на практиці?

#exploratorytesting

Давайте практикуватися🔥

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

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

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

Ціна: 1500 грн.
Тривалість: 4 години
Починаємо об: 11:00

І ще, давайте одразу, запису воркшопу нажаль не буде ❌, оскільки він максимально націлений на практичну роботу тут і зараз!

Хто бажає доєднатися, або більш детально дізнатись про воркшоп, пишіть + у комент під постом 😉

#exploratorytesting

​​6 грудня команда Levi9 запрошує на QA Meetup!

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

Що у програмі?

“Техніки тест-дизайну”, ━ Дмитро Топчій, Test Lead в Levi9
Розглянемо наглядно приклади технік тест-дизайну, що здатні допомогти тест інженерам в плануванні дослідницького тестування та автоматизації.

“Тестування доступності: теорія, інструменти та чому це важливо”, ━ Сергій Собур, Test Lead/ Principal QA Engineer в Levi9, спікер/модератор мітапу.
Чому і коли необхідно проводити тестування доступності, з чого почати та які інструменти стануть у пригоді.

“Автоматизація тестування доступності за допомогою Playwright” , ━ Віктор Кипоренко, Test Developer Junior в Levi9
Зосередимось на автоматизації: встановлення; різні варіанти конфігурації; створення і аналіз звітів та можливі проблеми.

Коли: 6 грудня о 19:00 (GMT+2)

Обирай формат участі:
Онлайн — безкоштовно за попередньою реєстрацією

Офлайн нетворк & пивко у Києві
Адреса: БЦ Техно Лофт, вулиця Володимирська, 101
Вхід з організаційним внеском ₴300
Всі кошти, отримані з продажу квитків направимо на благодійність💙💛

👉Деталі та реєстрація: http://bit.ly/3UVn8Q7

Побачимось!

6 думаючих капелюхів як підхід в Quality Assurance

Едвард де Боно розробив цікаву техніку на основі 6 різних капелюхів, приміряючи які ми під різним кутом дивимося на речі.

Давайте розглянемо як їх можна використати в тестуванні

1. Синій капелюх - управлінський
Одягаючи цей капелюх, команда думає з точки зору менеджмента і ми описуємо кінцеву ціль нашого продукта
Ми можемо задати собі такі питання:
- Чому ми розробляємо цей продукт?
- Які потреби юзера ми вирішуємо?
- Чи буде це корисно для наших користувачів?

2. Білий капелюх - інформаційний
В цьому капелючі ми можемо задавати такі запитання:
- Що ми уже знаємо про продукт?
- Що нам ще потрібно дізнатися та яку інформацію знайти?
- Які можуть виникнути прогалини, на що звернути увагу?

3. Червоний капелюх - емоційний
Одягаючи цей капелюх команда має відповідати на такі питання:
- Які емоції у нас викликає використання тієї чи іншої фічі?
- Чи є якісь неприємні відчуття при взаємодії з продуктом?
Таким чином ми аналізуємо продукт з точки зору користувача, як кажуть що наш шлунок говорить по віднощенню до продукту. Чи класний UI, чи добре продуманий UX і т. д.

4. Чорний капелюх - розсудливий
В цьому капелюсі ми продумуємо та аналізуємо різні факти наприклад:
- Чи ця фіча зрозуміла для наших користувачів?
- Чи юзер зрозуміє як йому користуватися новою фічою?
- Чи не виникнуть якісь проблеми, якщо ми змінимо певний функціонал?

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

6. Зелений капелюх - креативний
- Досліджуємо і аналізуємо подібні продукти та використовуємо інформацію для покращення
- Використовуємо нові інструменти та методології для покращення тестування
- Повторюємо цикл примірки капелюхів та генеруємо нові ідеї

Це один із підходів дослідницького тестування.

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

Залишилось ще кілька місць, хто бажає вскочити в останній вагон пишіть @yakymchuk_roma

#exploratorytesting

Реальне сімейне життя тестувальників 😉

Гайз 👋

Давайте сьогодні трохи відволічемось від теми QA і поговоримо про енергію.

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

Поділюсь із вами сьогодні своїм чек листом, який наповнює мене енергією:

▪️хожу на прогулянку, дуже полюбляю ходити пішки, особливо якщо це парк, ліс або просто по вуличкам міста.

▪️відпочиваємо з сім'єю, розважаємось з донькою, зараз наприклад ходимо кататися на льодянці з гірки.

▪️зустрічаємось з друзями та граємо настільні ігри або просто спілкуємось на різні теми.

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

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

▪️заняття спортом, в основному в домашніх умовах або на вуличних спорт майданчиках.

▪️читання цікавої літератури.

▪️перегляд фільмів чи мультиків у колі сім'ї.

▪️також мене заряджає навчання інших людей і коли вони діляться результатами впроваджених нових знань.

А як ви наповнюєтесь енергією?

🔥ЗНИЖКА 30% на мій курс по Тест Аналізу на честь чорної п‘ятниці

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

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

Знижки на Чорну П'ятницю 🔥

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

❗️10850 грн. замість 15500 грн.

Пакет LITE - Це 16 повноцінних уроків, але без перевірки домашніх завдань.

❗️7350 грн. замість 10500 грн.

Новий поток курсу стартує з 10 грудня. Ціни чорної п'ятниці діють до понеділка 28.11.
Щоб забронювати за собою місце, вам необхідно внести передплату 1000 грн.

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

Хто планує доєднатися кидайте + у коментарях 😉

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

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

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

Аналіз першопричини (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. Продукт має мати щось таке, щоб мої конкуренти заздрили

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

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

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