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

І сьогодні один з таких днів, коли хочу поділитись чимось що опосередковано дотичне до роботи!

🏆 Цього місяця я завершую курс тест менеджера, проте попереду ще довга підготовка до здачі, також мене ще чекає курс API OWASP TOP 10 і в кінці лютого я починаю нове навчання!

📚 Це навчання буде повʼязане з експертністю та про те, як її масштабувати!

Якщо чесно, я давно думала про це і відверто кажучи налаштована завжди до таких навчань скептично…
Але цього року я хочу відкривати для себе нові горизонти, тому все ж наважилась! 💪🏼

Я - як ІТ-виця, постійно навчаюсь, накопичую досвід, розбираю складні кейси і дуже хочу цим ділитись правильно!

❔ В звʼязку з цим я постійно ставлю собі одне питання: «Як системно упакувати знання?»

💡 Тут як раз і мені трапився курс про те, як правильно будувати свій експертний продукт!

Тому найближчі два місяці буду ділитись з Вами:
• що з цього реально має сенс.
• що виглядає як маркетингова теорія.
• що можна адаптувати під IT-контекст.
А там вже разом зробимо висновки ✨

Ліночку на навчання залишу тут - можливо Вас теж зацікавить!

Привіт, колеги!
Перш ніж почати, хочу щиро подякувати кожному з Вас за ту підтримку, пропозиції та рекомендації, які я отримала щодо пошуку роботи!
Це було надзвичайно важливо в той момент!
Вкотре переконуюсь, що QA community це щось неймовірне 🫶🏼 дякую Вам ❤️

Зараз я активно працюю над пошуком своєї dream job, але пошуки пошуками, а розвиватись треба продовжувати 🔥


У пʼятницю я переглянула останню трансляцію по курсу ISTQB TM і готова поділитись тим, що чекає мене далі та тим, що вже пройшла!

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

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

А поки я намагаюсь зібрати всю інформацію в своїй голові та закарбувати її, аби здача іспиту пройшла успішно! 🤞🏼

😅 Насправді навчання завершилось лише офіційно, проте попереду мене чекає ще повний, пробний тест, розбір цього тесту, робота над помилками і апрув на іспит…
А після цього його здача, в разі провалу - знову робота над помилками та повторна здача!

Я майже на фінішній прямій, то ж про результати тестів проміжних та повних буду писати! ✍🏼

А поки, побажайте мені успіху, бо попереду ще багато нервів на шляху до здачі 😁🤞🏼

Мій шлях навчання не закінчується ніколи 😁

Вчора пропустила вебінар, то ж дивилась у записі сьогодні!
І скажу Вам, що це було задоволенням, бо платіжки то моя окрема любов 🥰


🧑🏼‍💻 Дмитро Лук'янчук, «The Right Way of Testing Payments»

💰Пейменти в наш час всюди.

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

На прикладі інтеграції Stripe, ми розбирали 5 успішних кроків до тестування платіжних інтеграцій 🔥

1️⃣ Перший степ до перевірки інтеграції - це задавати питання.
Максимально багато стільки скільки можна.

❔Питання можуть бути такі:
• Як ми це будемо тестувати?
• За що ми відповідаємо?
• Яка інтеграційна логіка?
• Як обробляємо помилки?
• Хто обробляє картки?
• Чи відповідаємо за fraud?
• Який АРІ ми використовуємо?
• Де наша основна логіка? Клієнт чи сервер?
• Як ми обробляємо вебхуки? І чи є вони в нас?
• Як виглядає пеймент флоу для нашого юзера?
• Що відбувається до оплати?
• Що відбувається після оплати?

2️⃣ Другий степ до перевірки інтеграції - будуємо sequence diagram аби зрозуміти флоу.

Малюємо все!

3️⃣ Третій степ до перевірки інтеграції - покладаємось на прод! Це дуже важливо!

• Сендбокс - простий замоканий енвайрмент.
• Тест мод - реальне пеймент флоу з тест креденшелами.

❗️Важливо розуміти, що тестові сендбокси часто дуже сильно відрізняються від проду.

4️⃣ Четвертий степ до перевірки інтеграції - комунікація це мастхев!

5️⃣ Пʼятий степ до перевірки інтеграції - не все потрібно автоматизовувати.
Памʼятаємо про Принцип Паретто.

🐉 Чотири кити тестування пейметів:
• Humility.
• Communication.
• Pragmatism.
• Empathy.


❔А Ви тестували (тестуєте) платіжки?
😍 - так.
🥲 - ні.
👻 - я не QA.

Ну що ж? Ви готові?)

А тепер йдемо до найцікавішого - вижимки з Суворої QA конференції, яка відбувалась протягом минулого тижня!
Мої враження про свій виступ - я залишила тут.
А відгуки та інші штуки залишу на кінець серії вижимок! ☺️

То ж, гайда дивитись на перші три доповіді!
п.с. буду давати вижимки в рандомному порядку, не так, як вони йшли під час конференції)


👩🏼‍💻 Олександра Ковальова, «Як очолити Щекавицю тестових артефактів»

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

✨ «Традиційні» артефакти:
• Test Policy.
• Test Strategy.
• Test Plan.
• Test Suite.
• Test Case / Checklist.
• Test Report.
• Test Logs.
etc.

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

💡Good enough for now, safe enough to try.

❗️Мовчання не дорівнює згода. Завжди комунікуйте!

❔Ненасильницька комунікація як використовувати в плані змін?
• Спостереження - що маємо, хто споживач змін?
• Почуття - болі, страхи, мотиватори?
• Потреби - задачі, цілі, обовʼязки.
• Запит - формулювання зміни.


👩🏼‍💻 Інна Двойнікова, «Test Reporting: як QA впливає на релізи та бізнес-рішення»

✍🏼 Мета репорту:
• Дати статус тестування.
• Окреслити ризики.
• Відповісти чи можна у реліз.

💧Прозорість = чітка картина стану продукту.

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

❌ Типові помилки тест репорту:
• Перелік багів.
• Забагато цифр.
• Немає висновків.
• Недостатньо корисної інформації.
• Багато зайвої інформації.
• Відсутність структури документу.
• Забагато даних без висновків.

📤 Структура репорту:
• Титулка + approvals.
• Goals for testing / entry criteria.
• Detailed block (метрики, ризики, тестові результати і тд.) - саме цим розділом можна регулювати обʼєм репорту.
• Рекомендації.

📜 Типи репортів:
• По фічі.
• По спринту.
• По проєкту.
• У таблиці / дошці.

📂 Дані для звіту можна брати з:
• Баг тренінг системи.
• Тест менеджмент системи.
• Моніторингу та аналітики продукту.
• Командні інсайти.

💪🏼 Формуємо сильні висновки:
• Аналіз динаміки.
• Висновки через вплив.
• Аналітичне мислення.
• Причинно наслідкові звʼязки.


🧑🏼‍💻 Олександр Хотемський, «Нікому не потрібні ваші тестові артефакти»

💡 Інколи застаріла документація - ще гірше, ніж її не було б.

1️⃣ Тест плани зазвичай погано апдейтяться і стають нікому не потрібні.
⬇️
Тест плани мають працювати як дорожня карта і мають мати правильні пріоритети.

2️⃣ Тест кейси мають сенс тільки коли багато нових QA, бо зазвичай досвідчені спеціалісти проходять все по Summary і вони треба нам як чекліст зазвичай.
⬇️
Тест кейси потрібні тільки нам самим, нікому більше.

3️⃣ Тест репорти повинні давати інформацію про якість, а не про те що там упало в тестах.
Вони мають відповідати на питання - чи можемо ми релізити продукт, підсвічувати ризики та демонструвати куди рухається якість.

4️⃣ Баг репорти мають бути заведені якісно. Без халтури.
Мають мати правильні пріоритети.

❔Хто що хоче?
• QA хоче, щоб тест план не мінявся, щоб в нього вникали і щоб він був зрозумілий.
• Деви хочуть від багрепорту швидко в ньому розбиратись і щоб їх було по мінімуму.
• Менеджмент хоче від тест репортів розуміти стан якості системи людською мовою.


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

Попереду Вас чекає ще 6 вижимок - то ж, не перемикайтесь! ❤️‍🔥

Як Ви, друзі?
Вангую, що вже чекаєте вихідних!
(І, сподіваюсь моїх вижимок теж 😁)
То ж, гайда дивитись ще 3 вижимки з конференції!


👩🏼‍💻 Олена Тесленко, «Ефективна організація тест-кейсів: як заощадити ресурси та уникнути дублювання»

❔Що робить тест кейс якісним?
• Коротка, але інформативна назва.
• Один кейс - одна перевірка.
• Відрізняємо тестування флоу та його тригерів.
• Виділяємо прекондішини.
• Кожен має розуміти кейс, треба дивитись очима різних людей (новачок, ПО, розробник і тд.).

💡Тестування флоу - процес від початку до кінця.
💡Тестування тригерів - перевіряємо умови, що запускають флоу.

❗️Розділення цих понять дозволяє уникати дублювання.

🗝️ Test convention - єдиний стандарт написання тест кейсів.
Дуже круто працює у командах.

❌ Типові проблеми:
• Неатомарні кейси.
• Роздуті регресії.
• Некоректна структура.

📜 Зберігати ТС можна в TMS, Mind Map, в коді (наприклад BDD підхід).


🧑🏼‍💻 Олексій Бакунін, «Test Documentation That Updates Itself: AI-Augmented QA in Practice»

🥲 Проблеми документації в стартапах:
• Її зазвичай немає, бо є брак ресурсів, швидкі зміни продукту, немає окремого часу на документацію.

💪🏼 Виклики впровадження АІ для документування:
• Проблема контексту - бо давати його багато дуже дорого.
💡 Рішення - RAG (тут теж існує проблема retrieval, але її можна вирішити різними техніками)

• Проблема контролю - треба мати можливість перевірити роботу ЛЛМ.
💡 Рішення: згенеровані тексти потребують апруву і тестова документація оновлюється тільки після QA review.

• Проблема формату - це має бути зрозуміло і для ЛЛМ і для нас.


🧑🏼‍💻 Павло Сафонов, «Артефакти автоматизатора»

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

💡 Артефакти не повинні бути ціллю - вони повинні підтримувати та покращувати процес.

1️⃣ Артефакт: стратегія автоматизації тестування.

❔Має відповідати на питання:
• Яка мета автоматизації?
• Який проміжок часу охопити?
• Які способи досягнення?
• Які ресурси є?

Створення стратегії - це відповіді на правильні питання оформлені в документ.

2️⃣ Артефакт: матриця вибору інструментів.

Допомагає зробити обʼєктивний вибір між кількома варіантами інструментів.

Є прості матриці, є складні на велику кількість критеріїв.
Залежить від потреб.

3️⃣ Артефакт: тестові скрипти.

✨ Принцип FIRST:
1. Тест має бути швидким.
2. Тест має бути незалежний та ізольований.
3. Тест має бути повторюваний та детермінований.
4. Тест має бути скмоперевірний.
5. Тест має бути своєчасний.

4️⃣ Артефакт: тестовий фреймворк.

Наприклад: cypress, webDriverIO, playwright-test.

5️⃣ Артефакт: readme.md file.

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

📂 Культурні артефакти:
• DoD.
• Quality manifesto.
• Code conventions.


Останні 3 вижимки будуть завтра, як і мої відгуки!
Тому наберіться терпіння 😁
Всім спокійного вечора!