🙄Типова проблема на проєкті — Scrum дає часові рамки й ролі, але не дає структури для контролю якості. Саме цю прогалину заповнюють Testing Quadrants, роблячи тестування видимою, розподіленою і регулярною частиною кожного спринту, а не «фазою наприкінці». Цей топік перекочував у сертифікацію ISTQB Foundation Level з ISTQB Agile Tester, де також розглядається.🤓 Testing Quadrants — модель тестової стратегії, яка допомагає командам побачити повну картину покриття, вона дає систему координат: де ми є, де сліпі плями, що варто закрити в наступному спринті. Цікаво, що за рахунок осей моделі - це спрацює як для команд з максимальною автоматизацію чи навіть без тестувальників, так і для помірної участі shift-left підходів та їх комбінації з мануальним тестуванням.У моделі Testing Quadrants тести можуть бути орієнтовані на бізнес або на технології. Тести також можуть підтримувати команду (тобто скеровувати розробку) або критикувати продукт (тобто вимірювати його поведінку відповідно до очікувань). Поєднання цих двох точок зору визначає чотири квадранти:🟧 Q1 (орієнтований на технології, підтримка команди). Цей квадрант містить компонентні тести та тести інтеграції компонентів. Ці тести мають бути автоматизовані та включені в процес CI.🟨 Q2 (орієнтований на бізнес, підтримка команди). Цей квадрант містить функціональні тести, приклади, тести користувацьких історій, прототипи користувацького досвіду, тестування API та симуляції. Ці тести перевіряють критерії приймання і можуть бути ручними або автоматизованими.🟩 Q3 (орієнтований на бізнес, критика продукту). Цей квадрант містить дослідницьке тестування, тестування зручності використання та приймальне тестування користувачів. Ці тести орієнтовані на користувача і часто є ручними.🟦 Q4 (орієнтований на технології, критика продукту). Цей квадрант містить smoke-тести та нефункціональні тести (крім тестів зручності використання). Ці тести часто є автоматизованими.💡Розуміння осей моделіДві осі — це не просто класифікація, а спосіб мислення про мету тесту. Вісь "підтримка команди / критика продукту" часто плутають — важливо розуміти, що "підтримка" означає скеровування розробки (тести пишуться до або під час коду), а "критика" — оцінка вже готового продукту.⚠️ Типові пастки на іспиті ISTQB Foundation Level☑️ Q1 і Q4 обидва технологічні, але мають різну мету — Q1 будує якість, Q4 вимірює її☑️ Usability testing завжди в Q3, а не Q4 — навіть попри те, що це нефункціональне тестування. Це класичне питання-пастка☑️ Автоматизація не є обов'язковою для Q2 — тести можуть бути ручними🧐Початкову ідею та структуру Testing Quadrants розробив Браян Марік (Brian Marick) у 2003 році. А згодом її доопрацювали, розширили та популяризували Ліза Кріспін (Lisa Crispin) та Джанет Грегорі (Janet Gregory) у книзі "Agile Testing: A Practical Guide for Testers and Agile Teams" — радимо тим, хто хоче заглибитися у тему. Або велкам на наш курс підготовки до ISTQB Foundation Level — Олександра детально пояснює не лише й теорію, а й як це застосовується у командах на практиці з реальних проєктів.
🇺🇦Сьогодні поговоримо про ISTQB Board в Україні.Нагадаємо, що ISTQB є децентралізованою організацією, яка має національні представництва у 70+ країнах світу, (а самі іспити можна скласти у 130+ країнах).🇺🇦 Що ми знаємо про українське представництво ISTQB — USQB?✅ Сайт тут ✅ Воно засноване у 2006 році, тож цьогоріч святкує своє 20-ліття 💫(тоді як сам ISTQB у такому вигляді, як ми його знаємо сьогодні, сформувався у 2002) ✅ З моменту заснування USQB очолює Олександр Тарасенко — Quality Consultant (Miratech)💡Сьогодні вітаємо важливий апдейт USQB — до складу нашої національної борди долучилася Рамела Басенко🎉Якщо ви коли-небудь шукали матеріали про ISTQB українською, то точно мали бачити її статті та вебінари — Рамела зробила відчутний внесок у популяризацію сертифікацій у нашій країні. Крім того, вона одна з небагатьох в Україні має сертифікат ISTQB Expert Level🔥📕 Найближчим часом чекаємо від Рамели на вихід повного україномовного силабусу Foundation Level — він уже перекладений і на стадії узгодження💫Ви часто запитуєте, чи можна складати іспити українською і наразі відповідь ні. Але офіційний україномовний силабус — це перший крок і до іспиту українською🇺🇦
🤓 False-positive result і false-negative result — ці поняття часто плутають, тож давайте розберемо їх… на прикладі тесту на ковід.Уявіть, що ви здали експрес-тест на ковід. Всі ми знаємо, що вони не дуже надійні і якщо є сумніви, то краще перездати тест в лабораторії. Так от:👉 припустимо, експрес-тест показав positive результат (ковід є), а лабораторія показує, що ковіду насправді у вас немає. Виходить, це був false-positive result. В роботі тестувальника це зустрічається, приміром, коли ви заводите баг-репорт (типу баг є), а програміст пише “Can't reproduce”, через те що "баг" насправді був пов'язаний з якимись невірними конфігураціями саме на QA Environment або ви випадково тестували на покорапченому об'єкті. Тобто ви проблему бачите, але насправді її немає.👉 припустимо, експрес-тест на ковід показав negative результат (ковіду немає), а у вас всі симптоми. Лікар призначає тест в лабораторії, і він — о диво! — показує, що ковід є. Виходить, це був false negative result. В роботі тестувальника це буває, коли баги ховаються одне за одного. Приміром, у вас в формулі використовується два значення змінних, які розраховуються системою. Кожна з них повинна мати позитивне значення. Ви тестуєте вже розрахунок фінальної формули. Якщо тільки одна зі змінних буде в процесі розрахована від'ємною (що є помилкою), то ви це побачите. Якщо ж обидві — то мінус на мінус буде + і у фінальних розрахунках ви цього не побачите (типу багу немає). Хоча проблема є.🤓Ну що, стало зрозуміліше?⚠️ Зверніть увагу, що в автоматизації ще легше заплутатись. Бо "червоними" будуть тести з реальними багами та false-POSITIVE, а зеленими будуть — успішні тести та false-NEGATIVE.Дивимось ще раз на картинку і збираємо сльози в долоньку🥲Пишіть у коментарях до цього допису свої приклади false-positive result і false-negative result, щоб закріпити теорію практикою👇
😎Сьогодні поговоримо про іспит сертифікації ISTQB Agile Tester.✅ Для тих, хто думав його скласти , маємо гарну новину: цей іспит легший ніж Foundation Level 4.0. За нашими відчуттями він потребує підготовки в 2 рази менше, хоча має ту саму структуру: 40 питань, 75 хв, 65% — прохідний бал.💡Цікавий факт: найважчим в іспиті є задачі з Exploratory Testing на основі user story.То навіщо йти на курс ISTQB Agile Testing, якщо все, ніби просто?🔻Один з основних мінусів цієї сертифікації — вона практично не надає кейсів і більше концентрується на культурі, підходах і техніках.🟠 Рівень сертифікації — ті, хто тільки знайомляться з Agile і хочуть зрозуміти, як там організувати тестування нормально.🟢 Рівень курсу — Middle & Lead тестувальники, які вже по шию в Agile і хочуть НАРЕШТІ організувати його нормально. Тому на курсі ISTQB Agile Testing ми фокусуємося саме на практичних аспектах і кейсах (70% практики — це не красива фраза, а основа цього курсу).Під час навчання ми працюємо з усіма вашими “так історично склалося...” годинними дейліками, хаосом, замаскованим під канбан, оцінюванням у собаках сторі поінтів та іншими викликами реальних проєктів.💫 Для перших 10 учасників діє спеціальна Lucky price: внесіть від 30% оплати протягом 3 днів після реєстрації — і зафіксуйте найнижчу ціну на курс.🎯ДЕТАЛІ ТА РЕЄСТРАЦІЯ
🔥 Hot news — вийшла оновлена версія сертифікації по АІ — ISTQB Certified Tester AI Testing 2.0!Що змінилось:📐 Структура скорочена з 11 до 7 розділів🎯 Тема «АІ для тестування» — тепер повністю покривається окремою сертифікацією CT-GenAI🔴 Покриття GenAI та LLM стало глибшим: розглядається через exploratory testing, red teaming, специфіку тестування генеративних моделейОновлена версія сертифікації дає системне розуміння тестування AI-рішень і закриває ключові практичні компетенції:🔸 розуміння відмінностей AI-систем від традиційних (ймовірнісна поведінка, недетермінізм, відсутність стабільних oracle)🔸тестування в межах повного ML lifecycle: від підготовки даних і валідації моделей до деплойменту та моніторингу🔸застосування спеціалізованих підходів: статистичне тестування, risk-based testing, робота без чітко визначених expected results🔸 ідентифікація та контроль ризиків: bias, model drift, проблеми якості даних, вразливості моделей🔸оцінка якості AI-систем за специфічними атрибутами: robustness, explainability, controllability (відповідно до ISO/IEC 25059)🔸практичні підходи до тестування генеративного AI та LLM.Попередню версію сертифікації можна складати ще протягом року — до 21 квітня 2027 року. Але, на наш погляд, є сенс одразу опановувати більш актуальну версію.Ділимося з вами новим силабусом, над яким працювали:🔹Alliance for Qualification, 🔹Artificial Intelligence United, 🔹Chinese Software Testing Qualifications Board, 🔹Korean Software Testing Qualifications Board Будемо раді почути вашу думку про оновлення та власний досвід роботи з АІ на проєктах: чи наразі нові технології полегшують життя чи навпаки — додають головної болі?
🔥ISTQB Agile Testing — відкриваємо реєстрацію на курс, що стартує 17 червня 2026 року! ⚡️Ви маєте можливість не лише успішно скласти сертифікацію ISTQB Agile Tester, а й навчитися ефективно застосувати Agile-підходи на ваших проєктах завдяки зірковій колаборації тренерів:🌟Артем Биковецьвідповідає за практичність та глибоке занурення у практику Agile🌟 Олександра Ковальова ділиться перевіреними лайфхаками, що допоможуть скласти сертифікаціюЧому цей курс особливий🔥Єдина в Україні фахова підготовка до ISTQB Agile Tester🔥Максимально ефективний баланс практичних кейсів та теорії🔥Унікальне поєднання експертизи топових експертів з Agile та ISTQB🔥Добірка перевірених на практиці Agile-артефактів для роботиНавчання точно буде цікавим і корисним, якщо ви:✅давно хотіли розібратися, як Agile-підходи працюють в реальності, а не в "лабораторних умовах", ✅прагнете вдосконалювати продукт та деліверити ефективніше,✅працюєте у хаосі задач і хочете це виправити,✅налаштовані розібратися з Agile краще за свого Scrum-майстра і мати сильні аргументи в дискусіях,✅шукаєте спосіб набути адаптивного мислення, щоб залишатися конкурентними.Організаційні деталі📆Старт: 17 червня👨💻Формат: 3 заняття на тиждень (2 відеозаписи + 1 пряма трансляція для розбору запитань)⌛️Розклад прямих трансляцій: 17 червня, 24 червня, 1 липня, 8 липня, 15 липня, 22 липня. Точний час поки уточнюється (вечірні години)🎁 Бонус: практичний воркшоп з Артемом наприкінці курсу (дата уточнюється)💫 Перші 10 учасників, які внесуть мінімум 30% оплати протягом 3 днів, отримають спеціальну Lucky price на курс, тож поспішайте!🎯ДЕТАЛІ І РЕЄСТРАЦІЯ
🔥Останні 10 місць лишилося на практичний тренінг Олександри Ковальової Test Design Techniques: Black Box Core, що стартує вже 21 квітня!Під час занять ви не лише зануритеся у специфіку кожної техніки, а й на практиці розглянете:🍭 як по специфікації або user story визначати, яку техніку обрати🍭 все про глибину та види покриття тестами всередині техніки🍭 які саме види дефектів виявляє кожна техніка🍭 як комбінувати техніки для максимальної ефективності покриття🎁 Бонус цього практикуму — overview Metamorphic Testing — техніки тест дизайну, що додалася у 2025 році в оновленій сертифікації ISTQB Advanced Test Analyst 4.0⚫️На вас чекає:✅ 8 відеозаписів з теорією та інсайтами senior рівня по кожній техніці✅ розбір прикладів для підготовки до самостійного виконання✅ 3 комплексних завдання на розвʼязання практичних задач✅ ревʼю домашніх завдань та детальний розбір на прямих Q&A сесіях✅ 2 тести з задачами на перевірку засвоєних знань✅ можливість ставити запитання тренерці в чаті та на прямих трансляціях✅ темплейти, книги, стандарти та додаткова література🎯ДЕТАЛІ ТА РЕЄСТРАЦІЯ
🤓 Ділимося овервʼю 6 книжок з автоматизації для тестувальників на різних рівнях — від перших кроків до проєктування систем. ✨ Щось свіже-актуальне📕Software Testing with Generative AI — Mark Winteringham (2024)Найактуальніша книга підбірки. Winteringham показує, як інтегрувати GenAI в реальний процес тестування і автоматизації — від генерації тест-кейсів до аналізу результатів. Деякі інструменти вже встигли оновитися, але ідеї та підходи залишаються в силі. Якщо ви ще не думаєте про AI у своїй роботі — ця книга змусить почати.📕Contract Testing in Action — Marie Cruz, Lewis Prescott (2025)У мікросервісній архітектурі інтеграційні тести між сервісами — дорогі і повільні. Контрактне тестування вирішує цю проблему: кожна сторона перевіряє свою частину домовленості ізольовано, без підняття всієї системи. І якщо команда backend раптом змінила API — контрактний тест впаде одразу, а не десь на рівні e2e за годину. Найпопулярніший інструмент для цього — Pact, якому і присвячена ця книга. Cruz і Prescott розбирають реальні сценарії для веб, мобайлу та message brokers — покроково, з ілюстраціями і прикладами коду. Дуже практична і одразу застосовна.🌱 Для початківців у automation📕 Test Automation Engineering Handbook — Manikandan Sambamurthy (2023)Книга структурована на три чіткі частини: фундаментали автоматизації, практична реалізація для веб, мобайлу, API і перформансу, і нарешті — інтеграція з CI/CD та типові проблеми. Читачі особливо відзначають практичні блоки про метрики автоматизації (ефективність, покриття, стабільність), критерії вибору інструментів, приклади коду на GitHub, а також розбір типових антипатернів і пасток. Для початківця окремим плюсом стане те, що базові речі — git, налаштування VS Code, вибір середовища розробки — теж пояснюються покроково, без припущення що ти це вже знаєш. Саме тому це книга для тих, хто переходить з мануального тестування або тільки будує свою першу систему автоматизації — і хоче зрозуміти загальну картину, а не окремі інструменти.🏛️ Безсмертна класика📚Clean Code та Clean Architecture — Robert C. MartinДва рівні одного автора — залежно від того, де ви зараз. Clean Code — обов'язкове читання для кожного, хто пише тести: іменування, структура функцій, читабельність і рефакторинг. Бо тестовий код — це теж код, який хтось підтримуватиме після вас.Clean Architecture — для тих, хто вже думає про побудову фреймворків для автоматизації і хоче розуміти, як правильно розділяти відповідальності та керувати залежностями.Починайте з Clean Code, повертайтесь до Clean Architecture, коли відчуєте, що переросли окремі тести і починаєте проєктувати систему.🔩 Для хардкорних інженерів📕Your Code as a Crime Scene, Second Edition — Adam Tornhill (2024)Більшість книг з якості вчать що тестувати. Ця — де шукати проблеми ще до того, як вони з'являться. Tornhill запозичує техніки криміналістики і застосовує їх до кодової бази: аналіз Git-історії, hotspots у коді, патерни змін з часом — все це допомагає знайти проблемні місця ще до того, як вони стають багами. Для автоматизатора особливо цінна як інструмент прийняття рішень: куди направити тестове покриття в першу чергу, де технічний борг найнебезпечніший, і які модулі потребують найбільшої уваги. Читається як детектив — і змінює те, як ти дивишся на свій проєкт.Діліться у коментарях, які книжки з автоматизації радите ви самі👇
🤓Ми вже розповідали вам про Metamorphic Testing (МТ) — одну з цікавих новинок серед Black Box технік тест-дизайну.🔧 Нагадаємо: Для застосування МТ потрібні Metamorphic Relations (MR) — властивості системи, що описують, як зміна вхідних даних (inputs) має впливати на результат (outputs). На основі одного тесту автоматично генеруються наступні "follow-up" тести за простим принципом: якщо ми змінимо вхід → як має змінитися результат?Ключова особливість МТ — здатність працювати в умовах, коли Expected Results заздалегідь невідомі. Перше, що спадає на думку, — AI-тестування. Саме там ми неминуче стикаємось із відсутністю чіткого expected result: модель, на якій працює AI-компонент, приймає рішення самостійно на основі MR — а подекуди ще й навчається та формує нові MR без втручання людини.Але не АІ єдиним. 💡 Олександра провела експеримент, в межах якого змогла використати нову техніку:▪️в фільтрації та рекомендаціях в e-commerce▪️в ранжуванні та сортуванні▪️в рекомендаціях та формуванні стрічки для соц мереж (це був єдиний, але цікавий кейс з прямим використанням для AI testing)▪️для складного UI (dashboards / analytics)▪️в побудові гео маршрутів▪️в складних калькуляціях▪️в mobile testing▪️в accessibility testingЦе прям very excited 🤩Гарна новина для учасників практичного тренінгу Test Design Techniques: Black Box Core — ми підготували для вас overwiev, що допоможе сформувати чітке розуміння Metamorphic Testing та його можливостей.
🔥 Лишилося менше 10 місць у групі підготовки до ISTQB Advanced Test Automation Engineer, що стартує вже 9 квітня!Автоматизація часто виглядає як якась магія навмання: написав тест — запустив — помолився, щоб не впав, ну і добре. Після цього курсу автоматизація стане інженерією: прогнозованою, керованою і такою, яку не соромно підтримувати через пів року (так, саме тоді, коли "ніхто вже не пам’ятає, чому тут так"). Наша мета — не просто "навчити інструменту", а змінити спосіб мислення.❤️🩹 Які болі закриває курс🩹Хаос у фреймворку: "у нас тут PageObject, але… не зовсім, а там ще — ну тому, що так треба, зробили, бо історично склалось". Після курсу з’явиться структура, патерни, правила, рев’ю підхід саме для тестового коду.🩹Автоматизація, яка з’їдає час: замість "ще 50 тестів" — фокус на цінності. Менше тестів, але точніших, швидших, з адекватним покриттям ризиків.🩹Як пояснити менеджеру, чому "зробити автотести" — це не одна кнопка. Після курсу ви зможете розкласти по поличках: план, етапи, критерії готовності, ризики, підтримка.⚙️Як це буде:📆 Старт 9 квітня⌛️ Тривалість курсу: 2 місяці💡 Розклад: понеділок та четвер, 18:30-20:30 (Kyiv time).🎥 Формат: прямі трансляції та відеозаписи. Всі заняття записуються та доступні учасникам в будь-який час.📌ДЕТАЛІ ТА РЕЄСТРАЦІЯ
TGLIST.COM.UA
