Estadísticas de telegram channel - @motherofqa

Зазвичай у цьому каналі Ви бачите контент націлений лише на тестування, але сьогодні я принесла Вам дещо потенційно цікаве ✨🤔 Рано чи пізно у людей, які люблять ділитись інформацією зʼявляється думка про створення власного продукту… Зізнаюсь, що і я не виняток, оскільки я люблю навчати людей, ділитись своїми знаннями, досвідом, надихати та розуміти, що я роблю вклад в чийсь розвиток та карʼєру! Нещодавно я дізналась від колег, які є бізнес - консультантами, що вони збираються допомогти таким ж людям як і я на цьому шляху! Мені видалось це цікавим, то ж, вирішила поділитись з вами, оскільки частині аудиторії це все ж може бути актуальним! 🚨 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. 💔 - не співпрацюємо взагалі. 🗿 - у нас немає БА.

Інсайти тест менеджера, чи як сказати? 😁Нещодавно ми проходили тему «Test process improvements» і там були запропоновані різноманітні моделі покращень - зокрема і TPI Next. Я чула про цю модель, але застосувати чи толком розібратись мені з нею так і не вдалось доооо… цього тижня))) Я прослухала багато інформації про неї та про інші моделі, проте одне мене зачепило найбільше….🤔 Мені завжди було цікаво, а як же знайти ті проблеми в процесах, як зрозуміти що покращувати (окрім тих зон де дійсно болить і це видимо), як почати діяти? Звідусіль ж кажуть робіть покращення, робіть покращення… а де ж їх робити? Як? І найголовніше для чого? 🫣 І отут я почула про TPI Next і один з його темплейтів «Key areas», який можна застосувати для аудиту свого проєкту 🔑 Цей темплейт має 16 key areas, по яких можна оцінити свій проєкт, побачити де просідає, де все гуд і саме так знайти ті покращення та почати до них рухатись… 💡Бо саме це - перший крок до покращень, бо саме це - найважче зробити. Тому так - я вже з нетерпінням хочу спробувати це застосувати і так - це один з моїх інсайтів. А ще залишаю Вам фул посилання на всі інструменти ✨❔А Ви вже застосовували цей темплейт? 🔥 - так. 🤔 - ні. 😱 - вперше чую про це.

Такс друзі, принесла Вам новий екстеншн 😄Бачила і тестила схожі на ринку, але не користувалась з міркувань безпеки на поточних проєктах, а цей мені принесли для тесту - то ж хочу поділитись з Вами! 🔎 Кажуть, що він допомагає робити баг репортінг більш заощадливішим по часу та зручнішим. Все що Вам потрібно - це зробити скрін або рекордінг і ця тула автоматично зберігає всі технічні деталі для девів - інформація про девайс, розширення, інформація з консолі, нетворку, а також вся послідовність дій по коду (так і примітивну автоматизацію зробити можна 😅). 🛡️ Щодо security - то запевняють, що тула відповідає всім security стандартам - документацію залишу тут також.⛓️‍💥 Скажу відверто - з документацією я ще не ознайомлювалась, проте сам екстеншн вже спробувала. Виглядає доволі зручно, а також має інтеграцію з Jira та Linear - що робить цю тулу ще зручнішою.Хочу ознайомитись з нею трохи детальніше, бо як на мене, вона має всі шанси стати топом на ринку 🔥❔А як Ви вважаєте? Норм чи стрьом? 😁❤️ - норм. 🗿 - стрьом.

Всім вівторкового вечора! Сьогодні той рідкісний випадок коли я потрапила на лайв вебінар у Суворій спільноті! То ж в честь цього - вижимка «з-під ножа» як то кажуть 😁Сьогодні говоримо про візуалізацію наших результатів для бізнесу та інших стейкхолдерів. То ж, поїхали! 👩🏼‍💻 Олена Герасимова, «Make it Visible: Чому кожен QA має говорити мовою даних»💡 Проблема це коли ми не розуміємо який рівень якості має продукт. • Відповіді на словах не працюють - вони забуваються. • Складно довести реальний обсяг роботи QA. • Складно показати ризики до релізу. • Незрозуміло який рівень покриття. • Неможливо зрозуміти чи покращуємо ми якість. 🔎 Невидимий обсяг роботи QA неймовірно великий. 💡 Треба вводити метрики і візуалізувати їх для відображення всіх результатів команді.❗️Чарти мають відповідати конкретному запитанню.📈 Line/ trand chart: • показуємо зміни з часом. • відстежуємо динаміку і прогрес. • аналізуємо тренди.📊 Bar chart: • порівнюємо категорії. • показуємо розподіл.🥧 Pie chart: • показуємо пропорції. • частки одного цілого.🔥Heatmap chart: • ризикові зони. • концентрація дефектів. • стабільність модулів.🌆 Scatter Plot chart: • шукаємо закономірності або «кластери» проблем.☢️ Radar chart: • оцінити якість комплексно. • побачити сильні та слабкі сторони. • показати баланс, а не абсолютні значення.❗️ І памʼятаємо - дані без візуалізації не приймаються.❔А Ви візуалізуєте результати своєї роботи? 🔥 - так. 🥲 - ні.

Сміх сміхом, а вижимка тут як тут 😁Рік у спільноті як завжди почався з вебінару, але то ще було свято, то ж я пропустила і пішла дивитись запис. На вебінарі ми розглянули багато практичних кейсів- фейлів, багато метрик, ситуацій і тд. Але як на мене - та інформація не для вижимки. То треба почути, побачити і зрозуміти, проте пару поінтів для роздумів все ж залишу 👇🏼👩🏼‍💻 Марина Дідковська, «The Dark Side of AI Metrics»🥲 Через АІ зʼявляється багато вайб кодінгу. І це погано впливає на якість продукту, бо…… якщо система навчилась генерувати на коді з помилками - то вона сама буде кодити з помилками.💡 Очікуваний результат більше не статичний чи повністю визначений. Поведінка агента постійно розширює місце для валідних результатів.📏 Метрик для АІ багато, але для кожного типу продукту, агенту і тд - треба буде обирати.❓ Питання не «що» міряти, а «нащо». Метрики - це лише цифра , вони не сигнал якості.💡 Дашборди мають бути не точкові, а трендові.❔А підкажіть но, у кого з Вас є досвід тестування АІ у будь-якому вигляді? 🔥 - я. ❤️ - не я.

Христос Народився! Друзі, Вітаю Вас з Різдвяними святами та прийдешнім Новим Роком! 🎄Нехай все задумане збувається, нехай всі Ваші плани та мрії знайдуть свою реалізацію в новому 2026 році 🫶🏼Бажаю наснаги, натхнення та карʼєрного росту! 🌟І паралельно хочу поділитись тим, як проходить мій Тест Менеджерський курс! 😁Незважаючи на свята та відпустку - я продовжую навчатись та вдосконалювати свої навички! І ось нещодавно пройшла тест по топіку ризиків (здається він найбільший та найважчий у всій сертифікації) 😱Я дуже прокрастинувала цей тест і боялась його складати, бо дійсно ця секція давалась для вивчення важкувато… 🧾 Але під час складання різноманітних тестів, я завжди керуюсь одним правилом - йти складати з тими знаннями, які я вже маю, не повторюючи нічого. ❔Чому так? Такий підхід дає мені можливість зрозуміти, яка інформація вклалась у мою голову, а яка ні. Після тесту я завжди аналізую, що мені було важко, чому я обрала ту відповідь, а не іншу, що я не зрозуміла і тд… 🔁 І вже після цього я йду і довчаю/ повторюю всю інформацію. Не знаю, чи підійде такий підхід Вам, проте раджу спробувати, принаймні раз, кожному - бо мені він допомагає чудово. ❔А Ви пробували так навчатись? 🔥 - так, використовую. 🥲 - так, але не підійшло. ❤️ - ні, треба спробувати. 🗿 - ні, мені не підійде.

Всім привіт друзі! Наприкінці року - 2025 підсипав мені багато випробувань, то ж я трішки випала з каналу, але сьогодні мала можливість подивитися доповідь у Суворій QA community і мова йшла про performance review 🔍 👩🏼‍💻 Ірина Костюк, «How to navigate performance reviews and the art of giving and receiving feedback». 🎯 Ціль перформансу - це вирівняти індивідуальні зусилля, щоб досягнути цілей організації. ❗️Performance review і salary review ревю - це різні речі. Потрібно їх сепарувати. ✅ Performance review - це: • Структурована формальна розмова. • Інструмент вирівнювання. • Чекпоінт для розвитку. • Шанс відкалібрувати очікування. ❌ Це не: • Список помилок. • Не екзамен. • Не персональна оцінка. 🧾 Перед перформанс ревʼю готуємо: • Ключові досягнення. • Метрики та пруфи. • Челенджі та чого навчились. • Приклади співпраці. • Досягнені цілі. • Питання до менеджера. ❓Які питання задавати? • Які плани компанії на розвиток, на що буде фокус? • Які можливості для розвитку є? • Які скіли можна розвивати? • Яка частота фідбеку? • Які очікування менеджерів щодо QA ролі? ❤️ Перформанс ревю це шанс бути почутим.❓ Як давати фідбек? ✔️ SBI model: • Ситуація - описуємо ситуацію. • Поведінка - обʼєктивно описуємо поведінку. • Вплив - обговорюємо та описуємо як ситуація впливає на інших. ✔️ COIN model: • Контекст - описуємо ситуацію. • Спостереження - описуємо обʼєктивні факти, що спостерігали без засудження. • Вплив - описуємо як це впливає на роботу, команду і тд. • Наступні кроки - пропоновані дії як змінити чи вдосконалити поведінку. ❓Як отримувати фідбек? • Слухаємо повністю. • Робимо паузу перед тим як реагувати. • Задаємо уточнюючі запитання. • Саморефлексія. • Сепаруємо емоції від повідомлення.❔А як у Вас з performance review, любите цей процес? ❤️ - так. 👎🏼 - ні. 🗿 - у мене немає такого. 👍🏼 - нейтрально відношусь.

У четвер відвідала вебінар, на який запрошувала і Вас про нову еру технік тест дизайну 🔥Там було ну дуже багато класної інформації! Звісно що, вижимати її всю я не буду - натомість запрошую Вас переглянути самим і задонатити!!! Але дам Вам декілька тез, які можуть Вас зацікавити 🥰🚀 Поїхали: 🛠️ Техніки тест дизайну які ви знаєте - це базова база. ⚒️ Техніки тест дизайну були створені як милиці для інженерів. 🛠️ Існує лише дві техніки які зменшують кількість тестів - EP і Pairwise, і обидві вони засновані на припущеннях.🛠️ Класи еквівалентності можна використовувати без граничних значень, а граничні значення не можна без класів еквівалентності. І ще класи еквівалентності можуть бути взагалі без граничних значень.🛠️ У Black Box тепер 3 розділи:• Data based test techniques • Behavioural based test techniques • Rule based test techniques🛠️ Коли у нас є верифікація і немає валідації - можна трошки 💩. Коли у нас багато валідації, але немає верифікації можна дуже сильно 💩. 🛠️ CROWD testing входить до experience based. Техніка гарно підходить під бета тестування.🛠️ ISTQB вважає, що тестувальники з рівня мідл мають обовʼязково займатись defect prevention.Та от справи! Лінк на запис тут! І головне не забувайте донатити!