| Mother of QA |

DoR немає в Scrum. Є тільки DoD. Саме так, це твердження правильне. Якщо відкрити Scrum Guide, то Definition of Ready Ви там не знайдете. Натомість є Definition of Done - такий собі список активностей до кожної задачі в спринті, щоб вона вважалась завершеною. ❔То ж звідки ростуть ноги? На мою субʼєктивну думку DoR виникла як звичайна командна практика. Команди почали використовувати її, щоб домовитися: «Коли задача підготовлена, щоб ми могли взяти її в роботу?» 🎒 Наприклад: acceptance criteria повні, дизайн завершений, зрозумілі залежності, команда розуміє scope тощо. ❗️Але використання DoR може лімітувати нас, а працюючи за Agile, ми маємо бути достатньо гнучкими, щоб підхоплювати задачу навіть без «вилизаної» документації, дизайнів та критеріїв. З чим власне Ви і так стикаєтесь щоразу на своїх проєктах 😅 Тому використання DoR звучить не дуже гнучко в цьому контексті. ⚠️ Варто памʼятати про важливий нюанс: DoR може бути, а може й не бути. DoD - обов’язковий. І таки знаєте, якщо DoD я ще бачила, то DoR — ніколи 😅 ❔А як у Вашій команді - є Definition of Ready? А якщо ні, то чи бачили Ви їх коли-небудь? ⚡️ - є. 👍🏼 - немає, але бачив (-ла). 😢 - немає і не бачив (-ла).

Всім продуктивного понеділка! Випадаю частково зараз з каналу, бо сезон овочів, фруктів та ягід вже настав 🌶️🍒🍅 А це для мене важливий сезон заготівлі продукції 🤤 (хто ще не знає чому - забігайте сюди) 🫙 Ну а поки я збираю врожай - несу Вам коротку вижимку з минулотижневого вебінару у спільноті! 🔥 Говорили ми про те, як же ж тестувальники непомітно перетворюються на БА 👇🏻 👩🏼‍💻 Марія Терлецька, «Вітаємо! Ви тепер ще й Business Analyst. Як вижити QA без виділеного BA» ❔Ви поставили замовнику правильне уточнююче питання по вимозі? ❔Ви пояснили девелоперу як має працювати бізнес логіка? ❔ Ви вирішувати це баг чи фіча і фактично ухвалили рішення? Вітаю, після ухвалення рішення - тепер Ви БА! 🕸️ ❗️Простого QA не існує - є QA, який ще не бачив повного списку того, що вже робить. ❗️ Проєктів без бізнес аналізу не існує - хтось все одно це робить. ⚠️ Аналіз ніколи не зникає - він просто змінює assignee. ✅ Відсутність БА здорова ситуація коли: • Невеликий продукт із простим доменом. • Зрілий ПО, який знає бізнес і має право вирішувати. • Мала команда (від 5-10 людей). • Досвідчений QA, який уміє ставити питання до вимоги. • Процес, де домовленості фіксуються самі собою. 💡Проблема починається тоді - коли немає відповідального за аналіз. Немає людини яка ухвалює рішення. 💡Аналіз передається не посадою, а фразами: уточни вимоги, запитай клієнта, розберися, напиши задачу, поясни деву і тд. ❗️Найдорожчий баг проходить усі тести, бо код правильний - але неправильною була домовленість. ⚒️ 5 інструментів, які працюють: 1. Навіщо? Починайте з цілі. 2. Таблиці рішень. 3. Моделі станів. 4. Негативні сценарії. 5. Письмова фіксація. 💡Шість опор до тесту вимоги: • Хто? • Що? • Коли? • Навіщо? • А якщо ні? • Як розуміємо (критерій успіху)? 🎒 Survival kit: • Питай, яка була мета. • Усе усне - письмове того ж дня. • Реєстр відкритих питань. • Не беруть задачу без АС • Ставте питання ДО естімейту. ❔ А Ви вже виконуєте роботу БА у себе на проєкті? Чи ще ні? 😁 🤓 - так. 🌚 - ні. 🥲 - частково.

Quality Characteristics: Security VS Safety У листопаді 2023 року було оновлено стандарт ISO/IEC 25010 який описує quality characteristics of a product. І в цьому оновлені додали нову на той час характеристику Safety. Проте і зараз я часто бачу, що на багатьох курсах та ресурсах використовують ще стару табличку з 2011 року, де цієї характеристики немає. То ж, підозрюю, що про неї можуть не знати! ❗️Варто зауважити, що окрім Safety, є ще й Security - і це не реплейсмент, це різні речі. 🗡️ Security - це безпека продукту. Його захист від сторонніх втручань. ⛑️ Safety - це безпечність продукту для тих, хто ним користується. На одному з курсів, тренерка Саша Ковальова приводила дуже класний приклад з кактусом. 🗡️ Якщо ми намагаємось протикнути кактус олівчиком, намагаючись обійти і не зачепити захист голочок - це перевірка Security. ⛑️ Якщо ми взяли кактус і покололись - це перевірка Safety. І це критично важливо для розуміння та тестування інших саб-характеристик. А взагалі поритись і зрозуміти відмінності між характеристиками та саб-характеристиками надзвичайно цікаво! Дайте сердечка, якщо хочете quick note 🫶🏼

Прийшла до Вас із ще одним крутезним анонсом! 😍 📣 Сувора QA Конференція #002 «AI в тестуванні» 📅 28 вересня – 2 жовтня, онлайн (5 днів) Минулого разу я виступала на цій конференції і скажу Вам, що це зовсім інший формат і він відчується як ковток свіжого повітря! А ще мені дуже подобається, що ця конференція вузьконаправлена і всі доповіді навколо однієї теми 🔥 це прям кайф, бо немає розфокусу і можна копати в конкретну тему дуже глибоко і з різних поглядів та досвідів! Минулого разу ми говорили про документацію, а в цей раз будемо говорити про те, про що зараз чути з «кожної праски»: як AI змінює тестування і що з цим робити на практиці 🤖 📝 Програма сформована на 90%. 🗓️ Розклад і всіх спікерів можна подивитись на сайті. Реєстрація тут Ну і я не з пустими руками, бо з моїм промокодом Ви можете отримати знижку 20% 🤩 Мерщій забирайте: motherofqa

Середина тижня підкралась непомітно… І так само непомітно підкрадаюсь я з вівторковою вижимкою 😁 Цього разу виступав сам оунер спільноти Артем і говорили ми про людську нейромережу… А що це означає, дивіться внизу 👇🏻 🧑🏼‍💻 Артем Григоренко, «Людська нейромережа: те, що жоден AI не замінить у твоєму професійному рості». ❗️Проблема: Синдром самотнього QA • Немає з ким обговорити підходи. • Сусідні команда наступає на ті самі граблі. • Зняння помирає в силосах. • 20 QA в компанії і вони працюють не як організм. ⭕️ Три кола росту: • Squad - команда, де ми виконуємо наші задачі, тут ми отримуємо контекст і практику. • Internal - тут ми отримуємо масштаб та узгодженість. Вони можуть бути у такому вигляді: 🧷 Гільдії - там де збираються всі QA компанії. 🧷 Comunity of Practice - збираються спеціалісти в домені. 🧷 Center of Excellence - збираються лідери та обговорюються різні стратегії. • External - це загальні QA комʼюніті, мітапи, конференції, вебінари і саме вони надають нам свіжий погляд, тренди, weak ties. 🫱🏻‍🫲🏼 Weak ties: Це знайомі, не друзі. Колеги з інших команд, компаній, спільноти, з якими ми спілкуємось нерегулярно. Вони приносять у наше життя нову інформацію, бо наше близьке коло знає те саме, що й ми. Нова інформація приходить лише каналами поза цим колом. 💭 70% пропозицій роботи приходять через weak ties. 1️⃣ Guild - широта. 2️⃣ CoP - глибина. 3️⃣ CoE - мозковий центр компанії. 🔥 Перетин трьох складових = цілісне зростання. ❕АІ потужний, але потребує людського супроводу. ❕ АІ вчиться на людських даних. ❕ АІ робить помилки - люди валідують. ❕ АІ не має контексту - люди його надають. ⛑️ Хаос + АІ = швидший хаос. ⛑️ Структура + АІ = зростання та масштабування структури. ❔Чому спільноти вмирають? • Монолог одного. • Зустрічі без результату. • Вигорання лідера. • Немає нових голосів. • КРІ зверху. Чекаю Ваших серденьок і активності ❤️ всім гарного вечора!

Mother of QA буде, а Ви? 🔥 Party Hard #12 — це не лише про доповіді. Це про людей, які будують: продукти, команди, кар’єри й нові знайомства. Цього разу фокус — на інженерах та людях, що будують продукти. А ще — препаті в п’ятницю, афтерпаті після конфи та недільний сніданок 🫶 Це мабуть ті теплі традиції, які відрізняють Party Hard від інших конференцій 🥹 Цього тижня ми побачимо перші анонси спікерів і тем - то ж, слідкуйте 💫 📅 19 вересня, Львів · Lem Station 🎟️ Квиточки тут п.с. а це доречі фотки зі всіх Патіхардів на яких я була 🥹 їх було аж 7!!!

Понеділок день важкий і він майже добігає кінця! ⏱️ Ну а я добігаю до Вас аби дати пояснення по питанню вище! ☝️ Більшість людей відповіла правильно, проте декілька панів та панянок загубились, або ж зрозуміли питання не так 📝 То ж, йдемо розбиратись разом 🫶🏼 ❓«Якщо в одному еквівалентному класі покрити декілька значень - чи означає це, що покриття збільшилось?» Відповідь - Ні, і ось чому… 💭 Уявіть, що у Вас є клас еквівалентності: від 1 до 10. Тобто, у цей клас входять наступні значення: 1,2,3,4,5,6,7,8,9,10. 🔎 В одному тесті ми протестували значення 2 - все відпрацювало добре. В іншому значення 5 - все знову відпрацювало добре. ❔Але чи можемо ми бути впевнені в тому, що протестувавши 9 - також все буде добре? Звісно, що ні. ❗️Бо техніка EP перевіряє припущення. • Припущення, що девелопер не забув цей клас в коді. • Припущення, що якщо один представник класу спрацював добре, то інші спрацюють так само. І якщо в класі від 1 до 10 ми ще можемо протестувати всі значення, то уявіть, якщо у нас буде клас від 1 до 1000… що ж ми будемо робити тоді? 🫶🏼 То ж, ця техніка дає нам можливість скоротити кількість тестів, спираючись на припущення, що інші представники класу відпрацюють так само, як і той один перевірений. Якщо Ви додасте ще один тест на перевірку цього класу, чи зміниться наше припущення? Ні 🙅‍♀️ То ж, робити це не варто! Замість цього краще пошукати інші шляхи для підсилення нашого кавереджу 🔥

Всім спокійного майже пʼятничного вечора 🫶🏼 Несу Вам короткі тези з вівторкової доповіді у спільноті! Говорили ми про автоматизацію тестування веб-застосунків 📝 🧑🏼‍💻 Володимир Обрізан, «Типові помилки в автоматизації тестування веб-застосунків» 💡Деякі помилки можуть бути не помилками, тому що іноді все залежить від контексту. 💡 Технологія не винувата у помилках впровадження, якщо інженер не розуміє призначення та не розібрався як вона працює і у чому корінь проблеми, що вирішується. 💡Фреймворк не повільний, треба дивитись на тести. ❌ Помилка: запускати авто тести в хмарах. ❌ Помилка: вичерпне тестування всіх аспектів, намагання перевірити усе одним інструментом. ❌ Помилка: тестувати що попало. ❌ Помилка: тестувати дії оператора. ❌ Помилка: гнатись за супер-пупер архітектурою. ❌ Помилка: впроваджувати все підряд. ❌ Помилка: ігнорувати помилки. ❌ Помилка: не інвестувати в observability. ❌ Помилка: догматизм. ❌ Помилка: мислення, що автоматизатор не програміст. 💡 Нагородою за хорошу роботу - йде ще більше роботи. І ця фраза в чаті змушує задуматись. Найбільш цікавим в цій доповіді були реальні кейси доповідача та історії до кожного зі стейтментів! То ж, ця доповідь, одна з тих, де треба слухати і вижимка тут не допоможе! ❔А Ви поки підкажіть, чи погоджуєтесь з якимось з цих стейтментів? 👍🏼 - повністю погоджуюсь. 🤔 - частково погоджуюсь. 👎🏼 - не погоджуюсь взагалі.

💡Документація яка є архівною і сильно неактуальною - є НЕ тільки не корисною, але й небезпечною. І Ви готові до цієї розмови. Звідусіль нам кричать про важливість документації, про необхідність її оновлювати, писати, просувати і тд. і тп. А зараз в еру АІ, здавалось би, з документацією проблем взагалі НЕ має бути. ❌ Але упс… їх стає ще більше. АІ- генерованої документації «хоч греблю гати», все застаріває, ніхто не підтримує те, що було згенеровано за 20 хвилин і в результаті ми маємо сотні сторінок безкорисного звалища документації. А стає вона небезпечною тоді, коли раптом стає потрібною. Бо от в один день нам потрібно переробити функціональність, або щось додати в неї, або прийшла нова людина і її треба заонбордити і ось тоді нам це «вилазить боком». В документації одне, на проді інше, в баг-репортах третє і «чорт ногу зламає» поки ми розберемось - як же ж воно має працювати! І так, це найгірший сценарій, бо не завжди і не всюди таке буде. Але let's be conscious і перед тим, як створювати документацію/ впроваджувати якийсь її вид/ оновлювати стару - покопирсайтесь в архівах, видаліть старе і непотрібне, відредагуйте або ж позначте це як «outdated» і аж тодіііі йдіть «плодити» нові сторінки у Confluence чи інших системах і буде Вам щастя 🫶🏼

Вечора доброго! 🔥 Вчора був день АІ 😁 у спільноті доповідь, у Паши Семпая вебінар - прям самі скоро станемо АІ 🤣 Вебінар Паші я дивлюсь у записі, а от на доповіді була вчора онлайн! То ж, давайте подивимось про що ми там говорили 👇🏻 🧑🏼‍💻 Євген Пасєка, «Human-in-the-loop: страх чи необхідність» 🧗🏼 Test Expertise складається з: • Бізнес контекст і цінність (Why?). • Стратегія, планування та пріоритети (When?). • Що тестуємо та покриття (What?). • Підхід методи та інструменти (How?). 🏃🏼‍♀️В гонитві за локомотивом технологій фокус більше зміщується з розуміння підготовки процесу - до того, щоб взяти інструмент використати його і отримати результат. ❔ АІ-assisted flow (етап Why?): 🤸🏼‍♂️ Активності: Він може аналізувати специфікації, тікети, PRD, попередні рішення, фідбеки і тд. ❌ Обмеження: застарілі або неповні специфікації, відсутній бізнес контекст, суперечливі вимоги, і тд. 🛂 Точки контролю: • Чи використані всі критичні джерела? • Чи немає взаємовиключних вимог? • Які питання залишаються відкритими? • Чи достатньо цього розуміння щоб рухатись далі? • Чи відділені факти від припущень? ❔ АІ-assisted flow (етап When?): 🤸🏼‍♂️ Активність: Пріоритезація активностей відповідно до плану, стратегії та графіку. ❌ Обмеження: неправильна пріоритезація, план не враховує організаційні або технічні обмеження, неправильна оцінка часу і тд. 🛂 Точки контролю: • Чи всі критичні припущення позначені? • Чи реалістичні оцінки? • Чи всі критичні залежності враховані? • Які питання залишаються відкритими? • Чому саме така стратегія запропонована? • Чи відповідають пріоритети бізнес цілям та ризикам? ❔ АІ-assisted flow (етап What?): 🤸🏼‍♂️ Активності: побудова скоупу, виділяємо тестові умови і тд. ❌ Обмеження: неповні/ суперечливі вимоги, пропущені негативні, граничні чи альтернативні сценарії, неправильно визначений тест скоуп, гепи і тд. 🛂 Точки контролю: • Чи всі вимоги покриті принаймні одним тестом? • Чи покриті всі критичні бізнес, негативні, альтернативні сценарії? • Чи правильно визначений in scope/ out of scope? • Чи немає гепів? • Чи відповідає рівень покриття ризикам і стратегії? ❔ АІ-assisted flow (етап How?): 🤸🏼‍♂️ Активності: Створення і виконання тестів, збір результатів, аналіз результатів та фіксація дефектів. ❌ Обмеження: недостатня observability, помилки під час генерації чи виконання, хибна інтерпретація результатів і тд. 🛂 Точки контролю: • Чи результати відтворювані? • Чи достатньо evidence? • Чи знайдені проблеми проаналізовані та адресовані? • Чи немає гепів? • Чи можна довіряти результатам виконання або потрібні додаткові перевірки? 💡 Якщо ми щось пропустимо, покладаючись на АІ - ця проблема буде тягнутись крізь всі етапи і важливо розуміти, що це буде наша відповідальність, а не АІ. 💡 Класна техніка pre-mortem, для того що передбачити потенційні проблеми при розробці задачі на етапі вимог. 💡 Без штучного інтелекту для нас частково світ був простим.. бо у більшості випадків ми отримували очікувані результати. У епоху АІ у нас більше складна ситуація. Важливо зазначити, що дуже багато цікавої інформації було сказано поза тим, що є у цій вижимці і воно надає значно більше контексту! Мабуть в наш час буде тупо запитувати чи користуєтесь Ви АІ інструментами 😁 Тому запитаю наскільки активно Ви їх використовуєте? ⚡️ - дуже активно, АІ інтегрований майже всюди . ❤️ - вирішую задачі точково. 🍌 - зовсім мало і обмежено.

Всім продуктивного понеділка! ❤️‍🔥 Якщо Ви забули, то я напамʼятаю! У мене триває збір на дружню банку! І за донат від 300 грн. - Ви маєте можливість прийняти участь у розіграші смаколиків, які виготовляє мій сімейний бізнес! А також, за донат від 1000 грн. - Ви все ще можете залетіти на вебінари по Claude Code від Паші Семпая 🔥 Або можете просто задонатити будь яку суму і підтримати наше військо! Я чекаю на ваші донати 👀

Всім привіт! Сьогодні принесла Вам дуже цікаву вижимку з традиційного вівторкового вебінару! А говорили ми про те, про що не говорять 😁 Дивимось 👇🏻 👩🏼‍💻 Інна Осінна: «Ідемпотентність. Речі, про які не говорять» 🪄 Ідемпотентність: N запитів -> 1 результат (один запис у БД). ❌ Ідемпотентність - це не однакова відповідь на кожен запит, не однаковий статус код, відсутність побічних ефектів. ✅ GET, HEAD, OPTIONS - ідемпотентні та safe (ті які нічого не змінюють у БД). ☑️ PUT, DELETE - ідемпотентні - бо вони всього лиш перезаписують існуючий запис, а не створюють його. ❔ PATCH - залежить від реалізації. ❌ POST - не ідемпотентний, бо створює кожен раз новий ресурс. І тут проблема: Бо ми маємо розрізняти retry і single request за допомогою Idempotency key. 📖 IETF RFC 9110. 🧗 5 рівнів перевірки: • Response • Database • Message queue • Email service • Webhook logs 💪🏼 Топ помили при реалізації: • Зберігаємо лише ключ, а не відповідь. • Немає валідації body для одного ключа. • Race condition при запису ключа. • Side effect поза транзакцією. • Сховище без TTL або занадто короткий. • DELETE віддає різні коди при повторі. • POST без idempotensy key. Також ми мали дуже класну демку на прикладі Stripe з використанням різних скриптів, тулів і тд. 🔥 Вебінар був дуже цікавий! Бо особисто я про ідемпотентність почула вперше (і востаннє) на курсі Інни 😁 Але вже зараз, почала помічати, що про це дізнається більша кількість людей і навіть стараються питати на співбесідах) Коли я востаннє шукала роботу, то мене про це спитали двічі (все ще мало, але хоча б хтось). ❔А Вас коли-небудь питали про ідемпотентність на співбесіді? 👍🏼 - так. 👎🏼 - ні. 👌🏼 - дуже рідко питають. 🌚 - сам (-а) вперше про це чую.