| Mother of QA |

Понеділка продуктивного!!! Лише вчора мала нагоду переглянути минуло-тижневий вебінар, який мені дуже відгукнувся і хочу поділитись із Вами! 🤌🏼 Трішки передісторії: Моя дорога в ІТ почалась через стартап. Це був український стартап, де розробка велась над CRM системою. Тоді я ще не мала досвіду і здавалось, що все що говорили на курсах просто теорія, яка звʼязку з реальністю немає, бо про ніякі тест плани, тест кейси і тд. мова там і не йшлось) Потім звісно я отримала дуже різноманітний досвід, і повертаючись до цього першого - зрозуміла, що мабуть саме робота в стартапі дала мені оцю ранню самостійність, тайм менеджмент та навички планування в хаосі. Ну а що нам розповіли про стартапи, давайте дивитись 👇🏼🧑🏼‍💻 Олексій Іващенко, «QA в продуктовому стартапі: як забезпечити якість і не втратити себе»💭 Стартап це: • експерименти понад плануванням. • обмежені ресурси. • малі команди. • мінімум процесів. • максимум невизначеності. 💡 Основна ціль стартапу: знайти Product Marked Fit і масштабуватись. ⏰ Коли туди шукають QA? • Проблеми з якістю. • Складність продукту. • Регуляції. • Толковий менеджмент. 💪🏼 Стартап дуже мапиться на Agile manifesto. ✨ Автоматизація має бути ризик-орієнтована і орієнтована на клієнта та реальні дані.🚣🏻 Метрики в стартапі: 👉🏼 Якість: • Bug escape rate. • Time to defect. • % автотестів на критичні флоу. • Lead time for changes. 👉🏼 Делівері: • Tests run duration. • Deployment frequency. • Time to market. 💡АІ - це множник (якщо у вас хаос то він його примножить). 👍🏼 Що гарного в стартапах? • Гнучке ухвалення рішень. • Можливості для навчання. • Прямий вплив на процеси та продукт. • Зростання разом з компанією. 👎🏼 Що поганого у стартапі? • Процесів не існує. • Високий тиск. • Виконання багатьох ролей. • Невизначеність і зміна пріоритетів. • Нечіткий карʼєрний шлях. • Баланс між роботою та особистим життям.🔥 Як не втратити себе? • Моніторити вигорання. • Ставити межі. • Не брати відповідальність за весь продукт на себе. • Не сприймати хаос як свій факап. • Тримати баланс. ❔ Як потрапити у стартап? • Знати англійську • Софт скіли• Нетворкінг • Прямі контракти • «Модні технології»❔А Ви працювали у стартапі? 👾 - так. 🌚 - ні.

Ви знаєте, що час від часу я сюди пишу не тільки про тестування, а й про особисті досягнення, навчання поза роботою і тд. 💭І сьогодні один з таких днів, коли хочу поділитись чимось що опосередковано дотичне до роботи!🏆 Цього місяця я завершую курс тест менеджера, проте попереду ще довга підготовка до здачі, також мене ще чекає курс API OWASP TOP 10 і в кінці лютого я починаю нове навчання! 📚 Це навчання буде повʼязане з експертністю та про те, як її масштабувати! Якщо чесно, я давно думала про це і відверто кажучи налаштована завжди до таких навчань скептично… Але цього року я хочу відкривати для себе нові горизонти, тому все ж наважилась! 💪🏼 Я - як ІТ-виця, постійно навчаюсь, накопичую досвід, розбираю складні кейси і дуже хочу цим ділитись правильно! ❔ В звʼязку з цим я постійно ставлю собі одне питання: «Як системно упакувати знання?»💡 Тут як раз і мені трапився курс про те, як правильно будувати свій експертний продукт! Тому найближчі два місяці буду ділитись з Вами:• що з цього реально має сенс. • що виглядає як маркетингова теорія. • що можна адаптувати під IT-контекст. А там вже разом зробимо висновки ✨ Ліночку на навчання залишу тут - можливо Вас теж зацікавить!

Вечора доброго! Тиждень добігає кінця і вирішила з Вами поділитись вихимкою з доповіді яку прослухала у вівторок у Суворій спільноті. Говорили ми про конфігураційне тестування! 👩🏼‍💻 Катерина Іванченко, «Конфігураційне тестування: як покривати складні комбінації і мінімізувати ризики»⚒️ Конфігураційне тестування дуже важливе, оскільки воно чинить реальний вплив на користувачів. ✨ Ми можемо почати розбиратись з цим за допомогою техніки Classification Tree. ❔Які параметри варто враховувати? • Платформи. • Локалізація. • Браузери. • Ролі користувачів. • Версії апки. • Розміри екрану. 💭 Для того, щоб зрозуміти максимальну кількість наборів, які будуть пересікатись принаймні раз - нам потрібно перемножити між собою значення кожного класу. ❔Наприклад: 3 види платформи х 2 види браузера х 2 види мови = 12 унікальних комбінацій. 🔥 Переваги техніки: • Візуалізація складності. • Ефективна пріоритезація. • База для команди. 📜 Двокомпонентний підхід до пріоритезації: • Аналіз статистики користувачів. • Аналіз ризиків та дефектів. 💡План впровадження конфігураційного тестування: • Збір інформації. • Classification tree. • Фільтрація комбінацій. • Пріоритезація. • Планування ресурсів. • Регулярний перегляд та повторення. ❔Що дає систематичне конфігураційне тестування? • Покриття аудиторії. • Зменшення ризиків. • Швидкість релізів. • Ефективність ресурсів.Чекаю Ваш лайк за мої старання 🫶🏼

🧤 «Натягування» StoryPoints на години. В чому ж проблема? 🧤Вчора в чатику по підготовці до сертифікації побачила питання, в якому запитували про проблему такого «натягування» і зрозуміла, що хочу написати про це невеличкий reminder! Мабуть цю тему піднімали вже купу разів, але підняти «купу-перший» не завадить, адже як показує практика не всім це може бути очевидно, або ж не всі ще про це чули… 💡 StoryPoints - історично є абстрактною одиницею, він використовується для того, аби оцінити складність задачі, не її час. Для цього придумали оці всі визначення StoryPoints у розмірах футболок, породах собак і тд. (адже команда заздалегідь домовляється, що для них розмір S по складності і що L). 🫣 Натягування на нього будь-яких вимірних одиниць (години, дні, хвилини) просто немає сенсу. Бо коли Ви робите це - Ви по суті використовуєте оцінку в людино-годинах, проте з назвою StoryPoints. 📜 В свій час, коли я пішла на свою першу роботу, я вперше стикнулась з такою ситуацією. Тоді мені здавалось що це абсолютно нормально, але тепер, маючи більше досвіду та інформації і рефлексуючи до цих спогадів знову - я розумію, що тоді ми просто оцінювали людино-годинами, використовуючи техніку «Пальцем в небо», а потім жалілись, що Agile не працює і оцінки неточні 😁 Але головне, що все це було «під соусом» StoryPoints.❔А у Вас були такі ситуації? 😁 - неодноразово. 🏆 - ні разу. 🤪 - ще не бачив (-ла) трушних StoryPoints.

✅ «Правильно чи не правильно» ❌п.с. зараз буде трошки моїх рефлексій ✍ 💻 На одній з трансляцій під час навчання ми згадали доволі цікаву річ (здається Адам Роман писав в одній зі своїх книг), що коли Ви бачите у відповідях до питання на іспиті ISTQB «must», «all the projects» і тд. - то з більшою долею ймовірності ця відповідь неправильна. Оскільки йде узагальнення. ❗️А як ми памʼятаємо - testing is context dependent. То ж, про узагальнення мова йти не може. 📜 Потім побачила пост на просторах Лінкедіну з використанням стверджень «правильно / не правильно» і зрозуміла, що у нашій професії немає такого. Є лише контекст.❗️Контекст, який формує правила, команда яка пристосовує все під себе. І байдуже чи відповідає це книжці чи ні - головне, щоб це ПРАЦЮВАЛО. ✔️ Якщо це працює і це «як книжка пише» - ідеально. ✔️ Якщо це працює, але не «як книжка пише» - це чудово. ❌ Якщо це не працює ніяк - тоді ми маємо проблеми. І байдуже чи «як книжка пише» чи ні.💡 То ж, запамʼятайте, коли десь на курсах, конференціях, дописах, хтось Вам каже що «так робити неправильно» - це не означає, що Вам потрібно сліпо вірити цим словам і йти все змінювати у своїх проєктах. ❗️Ні! Це лише означає що Ви можете послухати інший досвід і отримати інформацію про інші можливості. Але перш ніж нести покращення - проаналізуйте чи це релевантно для Вашого контексту і чи спрацює це у Вас. ✨ Памʼятаємо, контекст перш за все! А впровадження - «з головою» ✨*п.с. важливо уточнити, що тут йдеться мова саме про практичні речі, не про сталі теоретичні поняття, у яких ми точно можемо сказати - це правда або ні.

Раночку продуктивного 🏆Вчора була на традиційному вебінарі і говорили ми про інтеграцію МСР з Testrail. Женя показував нам приклади, плюси, мінуси та різні нюанси, якщо раптом хтось захоче собі таку приколюху😅 Вижимка скоріш за все буде Вам не дуже зрозуміла, але я намагалась дати щось корисне без втрати контексту 😁🧑🏼‍💻 Євген Пасєка, «МСР i Testrail: біль чи інновація»✨ Model Context Protocol (MCP) - відкритий протокол, який дозволяє будувати захищені двосторонні інтеграції між LLM застосунками та зовнішніми джерелами даних. ❗️Краще не використовувати зовнішній МСР сервер і не передавати туди секʼюрні дані, якщо не маєте сервера в компанії, бо це не дуже безпечно. 💡 МСР заберзпечує уніфіковане АРІ, яке буде передавати в певному форматі нашій LLM аплікації всю інформацію.💡Інтегровуємомь ми саме з LLM, а не з АІ. Бо LLM - це лише підмножинна і доволі маленька у цілій структурі АІ.🧑🏼‍💻 Будь-яку LLM ми вчимо на даних. Якщо у LLM немає достовірної інформації, яку вона може співставити і контролювати, то жоден тул нам не допоможе. ❗️Важливо розуміти на чому була навчена LLM. 💡Головний міф - якщо ми довго спілкуємось з LLM і постійно її поправляємо, то вона навчається. Але це так не працює.🏆 Ідея була зробити трьох кроковий аналізатор тест кейсів. ❗️Кожну сесію LLM починає з чистого листа.❗️Контекст LLM не резиновий. ❌ Критичні камені спотикання: • Треба розуміти на які частини ділити інформацію. • АРІ ліміт рейт. • Зависання процесів. • Потрібно очищувати процеси. • Тимчасове блокування запитів до сервісів які не відповідають. • Ретрай механізми при втраті інтернету і тд.✨ Інтегрувати можна будь-який тул з МСР і скоріш за все, проблеми будуть ті ж. ❔Хотіли б собі таку інтеграцію? ❤️ - так. 🗿 - ні.🏆 - вже маємо.

Вечора доброго! Вчора переглянула вебінар, який відбувся у вівторок, а тепер несу Вам вижимку 😅Говорили про мобільне тестування, а саме про покупки всередині додатку! Поїхали! 👩🏼‍💻 Анастасія Брижа, «In-App Purchases під мікроскопом: як тестувати покупки в iOS та Android»📌 IAP - це можливість купувати контент всередині мобільного застосунку. 🖇️ Покупки можуть бути: • Consumables - використовуються одноразово. • Non- consumables - купуються один раз і доступні назавжди. • Auto - renewable subscriptions - регулярний доступ за плату. • Non-renewing subscription - доступ на обмежений період. 🪄 Маркетингові інструменти: • Introductory Offers for subscription - ті, хто ніколи не мали підписки. • Promotional Offers for subscription - ті, хто вже мали підписку, але пішли або хочуть піти. • Subscription Offer Codes - використовуються як вибачення за неприємності. • Family sharing - дозволяє ділитись підпискою між членами родини. 📦 IOS групи підписок - може бути лише один тариф зі списку тарифів одночасно. Сама скасовує стару підписку при переході на іншу. В Android потрібно реалізовувати додаткову логіку для цього. ⬆️ Upgrade - зміна відбувається одразу, невикористана частина повертається з минулого тарифу, нова сплачується за новою ціною. ⬇️ Downgrade - поточна дорожча підписка діє до кінця оплаченого періоду і тоді відбувається перехід. ↔️ Crossgrade - зміна того ж рівня тарифу. Новий тариф вступає в силу на наступний renewal date (якщо різна тривалість тарифів). 💡Android доволі гнучкий у цьому плані. І розробник сам може обрати логіку із наявних. ❔Що тестувати? • При переході на тарифи не має бути паузи. • Коректне оновлення дати передплати. • Якщо юзер змінив план на одному девайсі то на іншому теж має оновитись. ❗️Усім, що стосується цін, грошей і тд. - керує стор.5️⃣ етапів будови флоу: 1️⃣ Конфігурація продуктів на Paywall в додатку. 🔎 Тестуємо: • Що наші юзери отримують правильні ІДшки продуктів. • Обробку кейсу коли бекенд недоступний. • Биті ІДшки. • UI paywall на відповідність всім нормам стору. 2️⃣ Створення ордеру на нашому сервері. 🔎 Тестуємо: • Різні негативні сценарії зʼєднання, таймаути, недоступний сервер. • Все, що може піти не так. 3️⃣ Ініціація покупки на стороні стору. 🔎 Тестуємо: • Обробка помилок. • Коли користувач не завершив покупку.4️⃣Валідація чеку на сервері. • Unified app receipt (Storekit 1) - base64 string, яка містить в собі всю історію покупок в додатку, яку можна перевіряти на сервері. • JWS transactions (Storekit 2) - концентрований на одній транзакції. 5️⃣ Закриття покупки обома сторонами.Протягом доповіді було ще дуже багато різних деталей і це було дуже цікаво! Раджу кожному подивитись!❔А тепер підкажіть мені, а хто працює зараз з IAP? 🏆 - я. 🧑🏼‍💻 - не я, але працював (-ла). ✍🏼 - не маю досвіду.

Зазвичай у цьому каналі Ви бачите контент націлений лише на тестування, але сьогодні я принесла Вам дещо потенційно цікаве ✨🤔 Рано чи пізно у людей, які люблять ділитись інформацією зʼявляється думка про створення власного продукту… Зізнаюсь, що і я не виняток, оскільки я люблю навчати людей, ділитись своїми знаннями, досвідом, надихати та розуміти, що я роблю вклад в чийсь розвиток та карʼєру! Нещодавно я дізналась від колег, які є бізнес - консультантами, що вони збираються допомогти таким ж людям як і я на цьому шляху! Мені видалось це цікавим, то ж, вирішила поділитись з вами, оскільки частині аудиторії це все ж може бути актуальним! 🚨 3-го лютого проводитиметься безкоштовний вебінар на тему: «Покроковий алгоритм побудови експертного бізнесу-2026» 🚨👉🏼 Якщо Ви коли небудь задумувались над тим, що окрім найму, було б круто додатково заробляти на власній експертизі: консультувати, менторити, запускати курси, але маєте певні сумніви щодо цього - тоді цей вебінар буде Вам актуальним! ✅ На вебінарі автори обіцяють допомогти нам розібратись з:• що змінилось в сфері заробітку на експертності? • як за 2 місяці побудувати експертний бізнес завдяки системному маркетингу та автоматизації? - як штучний інтелект прискорює просування та продажі? 🎤 Спікери:• Надія Раюшкіна — 2 власні проєкти на 100 000$/рік. Вивела десятки експертів на дохід від 5000+ $/міс.• Тетяна Коробова — бізнес-консультант, будує ШІ-системи та заробляє на створенні AI-асистентів📅 Коли? • 3 лютого о 14:00 (Київ)🎥 Як прийняти участь? • Участь безкоштовна + буде запис. 👉 РеєстраціяЗвучить цікаво, то ж я обовʼязково відвідаю та залишу свій відгук! А кому теж цікаво - запрошую відвідати разом зі мною!

✨ QA який залучений наприкінці - не створює ніякого value, він лише намагається мінімізувати втрати ✨Фраза яку я почула декілька днів тому і, о Боже, яка вона влучна! 🎯❔ Чому? Думаю зрозуміло, але… Пояснюю…Практично кожен хто коли небудь приходить у сферу QA, рано чи пізно, стикається з манерою «котити бочку» за кінцеву якість продукту на QA, упускаючи при цьому всі інші ланки розробки. І я розумію чому так відбувається, бо часто, для замовників, користувачів, інших людей, яким бракує знань «внутряка» - тестування це така собі остання ланка, яка має створити магію і зробити продукт bug free. ⚠️ І часто ці люди не знають (або не хочуть знати чи розуміти), що саме погано написані вимоги, не враховані всі нюанси, погана архітектура, недостатньо аналізу і тд. і тд. - створюють всі подальші проблеми. ❌ Всі звикли думати, що володіння якістю лежить на тестуванні, хоча насправді це ownership розробників, бо саме вони створюють цей продукт. ❌ Всі звикли думати, що «якось буде», «потім виправимо», «тестувальники протестують», хоча насправді приділяючи більше часу ретельному аналізу - можна було б зекономити час на фікси. І насправді я розумію, чому на аналіз не хочуть приділяти багато часу та вважають це не дієвим, бо на аналізі не видно миттєвого результату, результат аналізу стає видимим на інших етапах. 👉🏼 Те що ви зараз читаєте - не щось нове для Вас. Це радше нагадування замовникам/ компаніям/ продуктам, що чим раніше Ви залучаєте нас - тестувальників, у процеси розробки, тим більше цінності ми можемо і будемо приносити! Бо коли нас залучають надто пізно, ми вже не можемо вплинути на зміну солюшену, логіки, не можемо врахувати різні нюанси - ми можемо лише репортити баги та боротися з наслідками. 🥲 Саме тому і зʼявився цей дурний стереотип про тестувальників, які «просто тикають на кнопочки та заводять баги» - бо якщо їх залучили запізно, то вони вже й не можуть зробити нічого іншого. ✨ То ж, хочете отримати справжню якість та цінність - залучайте тестувальників з самих початків і Ви здивуєтесь наскільки якісним та продуманим може бути продукт ✨

Дискусії, питання та все інше ще в процесі, а вижимка вже тут, і сьогодні ми говорили про колаборацію BA & QA, а також про цінність! Говорили про їхні ролі на кожному з етапів SDLC, колаборативні процеси та ще дууууже багато іншого! Дуже раджу подивитись! Посилання тут! А поки несу вижимку 🫶🏼👩🏼‍💻 Віра Федоренко, «Від вимог до цінності: як BA і QA разом створюють якісний продукт».✨ Очікування замовника - це те з чого починається будь який продукт. ❔Що входить в очікування? • Бізнес результат. • Функціональні очікування. • Якість та UX. • Процес розробки. • Вартість. 💡 Value - це ядро очікувань замовника. І воно є:• Фінансове. • Стратегічне. • Клієнтське. • Операційне. • Ризик- менеджмент.💡 Тест кейси, метрики, документація, фічі - не є прямою цінністю для замовника. Але це прямо впливає на неї.На будь-якому з етапів SDLC може втратитись ця цінність.ТОР 🔟 втрат цінності: • Цінність замінюють фічами. • «Навіщо» зникає. • Вимоги важливіші за результат. • Зробили = успішно. • Delivery важливіше за outcome. • Реліз без перевірки користі. • Міряємо активність, а не результат. • Немає зворотнього зв’язку. • Команда не відповідає за цінність. • Фідбек не впливає на рішення.💡Коли QA приходить тільки на тестування - він бачить проблему, але не може її змінити. Коли QA приходить раніше - він допомагає її НЕ створити.🔜 На етапі планування важливо розуміти: • Для кого цей продукт? • Яку проблему він вирішує? • В яких умовах він буде використовуватися? • Які ризики є ще до розробки?🔜 На етапі аналізу важливо розуміти: • Чи зрозумілі та однозначні вимоги? • Які припущення ми робимо? • Що означає «готово»? • Що буде якщо юзер зробить X замість Y. • Які негативні сценарії?🔜 На етапі дизайну важливо розуміти: • Як будуть працювати корнер-кейси? • Чивраховані нефункціональні вимоги? • Чи враховані залежності? 🔜 На етапі розробки важливо розуміти: • Які сценарії мають бути покриті юніт тестами? • Що зміниться в існуючій логіці? • Чи є ризик зламати суміжні фічі? • Що покриваємо автотестуванням?✨ Практики співпраці BA & QA: • Якісний онбординг. • Спільні review вимог. • Three amigos. • Example mapping. • DoR. • Change requests. • Risk-based testing. • Early test design.❗️Якість і цінність - це не те, що перевіряють наприкінці, а те, що створюють разом із самого початку.❌ Антипатерни: • Чому я маю думати за нього? • Головне, щоб працювало. • Якось буде. • Краще не лізти. • Мене про це не питали.❔А як у Вас із співпрацею з БА? 🏆 - дуже тісно співпрацюємо. ❤️ - бачимось тільки на refinements. 💔 - не співпрацюємо взагалі. 🗿 - у нас немає БА.