Для якого тестування не потрібні тест-кейси?Не всі типи тестування потребують заздалегідь прописаних тест-кейсів. У деяких підходах акцент робиться на гнучкості, дослідженні та творчості. Наведу приклади:1. Ад-хок тестуванняСпонтанне тестування без документації. Тестер покладається на свій досвід, інтуїцію і здоровий глузд.2. Дослідницьке тестування (Exploratory Testing)Тестування відбувається в процесі вивчення продукту. Плани і ідеї створюються на льоту, залежно від результатів попередніх дій.3. Сесійне тестування (Session-Based Testing)Планується лише мета сесії, обсяг і час. Детальні кроки фіксуються вже після або під час виконання, а не до.4. Smoke Testing / Sanity TestingМоже проводитися без детальних кейсів — достатньо списку основних функцій для швидкої перевірки.5. Парне тестування (Pair Testing)Тестування проводиться в парі — один тестує, інший фіксує спостереження. Часто — без готових кейсів.Такі підходи особливо корисні на ранніх етапах розробки, при швидких змінах продукту або коли потрібно оперативно знайти проблеми.#AllAboutQA
🔍 Хочеш працювати з даними, але SQL досі здається магією?Пора розібратись👇📢 Старт курсу "Практичний SQL" від QALight вже 7 травня!💻 Для тих, хто не хоче просто “вивчити команди”, а хоче реально вміти працювати з даними.Цей курс для тебе, якщо ти: 🔸 QA, який хоче ефективно шукати баги в базі🔸 Бізнес-аналітик, якому потрібні чіткі вибірки без допомоги девелоперів🔸 Junior-розробник, який хоче впевнено працювати з бекендом🔸 Переходиш в IT і шукаєш корисні знанняЩо ти навчишся робити упродовж курсу?✅ Шукати, фільтрувати й обробляти дані ✅ Писати запити, які витягують потрібне з сотень тисяч рядків✅ Об'єднувати таблиці, будувати підзапити й створювати свої бази✅ Впевнено користуватись SQL Server Management Studio✅ І найголовніше — розуміти, ЩО ти робиш і ЯК це працюєЧим цей курс відрізняється від ютубу?🔹 Ти працюєш з живою базою, не просто читаєш теорію🔹 Кожна лекція — це практика🔹 Розбираємо реальні кейси, які трапляються на співбесідах та на проєктах🔹 Тренер відповідає на твої запитання, а не бот. Є можливість уточнити все, у чому сумніваєшся🧠 Якщо ти не знаєш SQL у 2025 — ти втрачаєш шанс на більшу ЗП, проєкти та кар'єрний ріст.🎓 Старт курсу — 7 травня⏳ Кількість місць — обмежена🌐 Формат — живі лекції у форматі онлайн, доступ до записів та матеріалів після лекцій. 📞 Хочеш встигнути? Реєструйся: https://qalight.ua/kursy/tech-skills/sql/
Підготовка до регресії перед релізом: що врахувати?Регресійне тестування — це один із ключових етапів перед релізом, який дозволяє впевнитися, що нові зміни не зламали вже працюючий функціонал. Щоб регресія була ефективною та не перетворилася на безкінечний марафон, важливо правильно до неї підготуватися.Що включає підготовка до регресії? 1. Актуалізація тест-кейсів • Перевірка й оновлення тестової документації. • Видалення застарілих тестів, додавання нових згідно останніх змін. 2. Визначення зони покриття • Повна регресія чи вибіркова? • Визначення критичного функціоналу, який обов’язково тестувати. 3. Підготовка тестових даних та оточення • Наявність стабільного стенду. • Підготовка або відновлення тестових даних. 4. Автоматизація • Використання автотестів для пришвидшення процесу. • Перевірка актуальності та стабільності автотестів. 5. Розподіл ресурсів • Планування участі команди (мануальне тестування, автотести, рев’ю). • Врахування залучення бізнес-аналітиків або девелоперів для швидкого уточнення питань. 6. Ризик-менеджмент • Визначення найбільш ризикових зон. • Пріоритезація тестування.Оптимальні терміни проведення регресіїВсе залежить від: • Обсягу змін (feature, багфікси, рефакторинг). • Розміру та складності проєкту. • Наявності автоматизації. • Кількості учасників тестування.Як вирахувати термін регресії? 1. Оцінка кількості тест-кейсівПорахувати загальну кількість тестів, які потрібно виконати. 2. Оцінка часу на виконання одного тестуВ середньому це 3-10 хвилин на мануальний тест (залежить від складності). 3. Формула для мануальної регресії:(Кількість тестів х Середній час на тест) / Кількість тестувальників = Орієнтовний час 4. Врахувати буфери: • На багфікси. • На непередбачувані затримки. 5. Автотести:Якщо автотести покривають більшу частину функціоналу, їх запуск планується паралельно або до старту мануальної частини.Приклад: • 200 тест-кейсів • Середній час: 5 хв • 3 тестувальники(200 х 5) / 3 = ~333 хв (~5,5 годин)З буфером — 1 робочий день.Рекомендації: • Плануйте регресію мінімум за 1-2 дні до релізу, щоб був час на виправлення критичних багів. • Використовуйте ризик-орієнтований підхід, якщо часу мало. • Регулярно оновлюйте автотести — це інвестиція в швидкість майбутніх регресій.P.S.Грамотна підготовка до регресії — запорука спокійного релізу без нічних гарячок!
Рефайнмент Беклогу: Не нудна зустріч, а ключ до ефективності! 🧐✨Часто чуєте про "рефайнмент" або "грумінг" беклогу, але не до кінця розумієте, що це і навіщо? 🤔 Давайте розбиратися!Рефайнмент (Product Backlog Refinement) – це регулярна активність (не обов'язково формальна зустріч!), мета якої – підтримувати беклог продукту в актуальному, зрозумілому та готовому до роботи стані. Це не планування спринта, а підготовка до нього!🎯 Головна ціль рефайнменту:Перетворити ідеї та вимоги з беклогу на чіткі, оцінені та готові до реалізації елементи (User Stories, Tasks), щоб команда могла взяти їх у наступний спринт без зайвих запитань та затримок.Що відбувається під час рефайнменту:Обговорення: Команда детально розбирає елементи беклогу (зазвичай ті, що плануються на найближчі спринти).Уточнення: Виявляються незрозумілі моменти, ставляться запитання Product Owner'у/аналітику.Декомпозиція: Великі User Stories розбиваються на менші, більш керовані завдання.Додавання деталей: Прописуються критерії приймання (Acceptance Criteria), технічні деталі, можливі залежності.Оцінка: Команда дає попередню оцінку складності/обсягу роботи (напр., у Story Points).Пріоритезація (опціонально): Product Owner може уточнити пріоритети на основі обговорення.👥 Хто бере участь? Це командна робота!Product Owner (PO) / Власник Продукту: Головний ініціатор. Пояснює бізнес-цінність, відповідає на питання "Що?" і "Навіщо?", встановлює пріоритети.Команда Розробки (Development Team): Інженери, QA, дизайнери (всі, хто реалізує). Відповідають на питання "Як?", виявляють технічні складності, залежності, оцінюють роботу.Scrum Master / Фасилітатор (часто): Допомагає провести зустріч ефективно, слідкує за часом, усуває перешкоди в обговоренні.Бізнес-аналітик (BA) / Системний аналітик (SA) (за потреби): Допомагає PO у формулюванні вимог, уточнює деталі, готує документацію.Представники інших команд/стейкхолдери (рідко, за потреби): Якщо є сильні залежності або потрібна експертиза ззовні.📈 Навіщо це потрібно?Зменшення невизначеності: Команда краще розуміє, що потрібно зробити до початку спрінта.Покращення планування: Більш точні оцінки та реалістичні плани на спринт.Швидший старт спрінта: Команда витрачає менше часу на уточнення вимог під час планування.Підвищення якості: Заздалегідь виявлені проблеми та залежності дозволяють уникнути помилок.Краща комунікація: Сприяє спільному розумінню цілей та завдань між PO та командою.❗️ Рефайнмент – це не разова акція, а постійний процес! Регулярно приділяйте час (зазвичай кілька годин на спринт) на цю активність, і ваш беклог завжди буде у бойовій готовності! 💪
Тестові оточення: які бувають і навіщо кожне потрібне?Щоб якісно протестувати продукт, недостатньо просто «запустити автотести». Важливо розуміти, де саме це відбувається. Саме для цього і використовуються тестові оточення.Можливі варіації в назвах та кількості, але можна відокремити основні типи, які варто знати QA:1. Local (локальне)Тестування відбувається прямо на комп’ютері розробника або тестувальника.Використовується для:– швидкої перевірки нових змін;– розробки та налагодження автотестів.2. DEV (development)Оточення для розробників. Може бути нестабільним, часто оновлюється.Використовується для:– перевірки нових фіч під час розробки;– інтеграційних тестів;– тісної взаємодії QA + Dev.3. QA / TEST / STAGEОфіційне тестове середовище для ручного та автоматизованого тестування.Використовується для:– повного циклу тестування;– регресії;– прийомки перед демо.Тут дані максимально наближені до реальних, але без впливу на прод.4. UAT (User Acceptance Testing)Може бути підготовлено окреме оточення для приймального тестування замовником або бізнесом.Використовується для:– перевірки функціоналу з точки зору користувача;– демонстрації нових можливостей. 5. PRE-PROD / STAGINGМайжекопія продакшену.Використовується для:– фінальної перевірки перед релізом;– smoke-тестів;– performance-тестування.6. PROD (Production)Реальне середовище, з яким працюють користувачі.Використовується для:– моніторингу;– перевірки фіксів після релізу (post-release validation);– дуже обережного тестування (якщо дозволено).Висновок:Тестові оточення — це як «пісочниці» з різним рівнем ризику. Чим ближче до продакшену — тим обережніше треба грати. Вміти правильно використовувати їх — дуже важливо для будь-якого QA.
🧩 Помилка в консолі — фронт чи бек? Як зрозуміти тестувальнику?Класика: відкрив F12, щось червоне в консолі, щось не працює. І ти стоїш із цим error'ом — наче з гарячою картоплиною: кому його передати? 🤯Розбираємось, як швидко зрозуміти, де причина — фронт чи бекенд 👇🔍 1. Подивись на тип помилки.TypeError, ReferenceError, Cannot read property...→ Фронт. Це JS-помилки в браузері, часто через поганий рендер, null, неправильну логіку у фронті.Failed to fetch, CORS error, NetworkError, timeout→ Може бути бек або мережа. Часто — бек не відповідає або не віддає правильний CORS-заголовок.🌐 2. Перевір вкладку Network (в Chrome DevTools).Запит має статус:▪️ 4xx (наприклад, 404, 403) → часто проблема на фронті: неправильний шлях, відсутній токен.▪️ 5xx (500, 502, 503) → це вже бекенд, сервер не впорався.▪️ 200, але дані дивні або null → можливо, фронт щось не так обробив.👉 Якщо відповіді взагалі немає — перевір, чи сервер живий, чи є VPN/інтернет.🧠 3. Читай stack trace.Якщо в консолі є шлях типу main.js:156 або App.jsx:48 — це фронт.Якщо в response від API є json з полем message, error, stack — часто це бекенд сам передає помилку.🛠 4. Спробуй повторити запит вручну (Postman або curl).Якщо помилка повторюється — справа в бекенді.Якщо там все ок, але UI ламається — проблема у фронті.💡 Практика = досвідЗ часом ти навчишся за 10 секунд по консолі та Network вкладці розуміти, що зламалось і куди бігти. Не соромся писати в команду уточнення типу:“Отримую 500 при POST на /api/orders. Чи є проблема на бекенді?”📦 Тестувальник, який розбирає консоль — це вже пів девелопера 😉...чи чверть, якщо розробник дуже високий 😂
🎬 Ця історія могла завершитись провалом. Але стала квитком в ІТ.🎙 LIVE-інтерв’ю: Випускник VS Тренер QALight😳 Уяви:Ти готуєшся до співбесіди. Знаєш усе.І тут… зависаєш на легкому SQL-запиті. Тиша.І раптом:“Ти не витримаєш напругу на проєкті.”❌ Все. Фінал?👉 Ні. Це був лише початок.У суботу ми покажемо реальну історію людини, яка: – хотіла здатися– боялася не виправдати очікування– потонула в потоці знань– пройшла 21 співбесіду за місяць– і все одно дійшла до мети💡 Ти почуєш:— Як вчитися, щоб не згоріти на півдорозі— Чому навчання в QALight відкриває двері в реальне IT— І як стати тим, кого хочуть наймати, навіть після факапів🎙 Випускник VS Тренер QALight — розкажуть усе, про що зазвичай мовчать.🎯 Без прикрас. Без “успішного успіху”.Просто чесно, відверто. 🔥БОНУС! Цієї суботи до діалогу приєднається карʼєрний менеджер з досвідом понад 5 років Лев Волевський. Він провів понад 3 тисячі співбесід і точно зможе порадити, як стати кандидатом, якому надішлють офер. Розмова, яка зруйнує міфи і включить реальність.🟢Коли? У суботу, 12 квітня, о 18:00 у прямому ефірі!📍Посилання на реєстрацію: https://testing.qalight.com/?page_id=661&et_fb=1&PageSpeed=off
🧪 Тестові дані: що готувати заздалегідь і чому це важливо?Успішне тестування часто залежить не лише від сценаріїв і чеклістів, а й від готових тестових даних. Бо коли знайдено баг, але ти 20 хв. створюєш акаунт вручну та готуєш дані — це вже не дуже 😅Отже, які дані тестувальник зазвичай готує заздалегідь? 👇📌 Типові приклади тестових даних:Користувачі з різними ролями– admin, manager, guest, readonly– Перевірка доступів, відображення, авторизаціїАкаунти з особливими станами– Підтверджений/непідтверджений email– Тимчасово заблокований користувач– Преміум-тариф / без підпискиТранзакції / замовлення– Оплачені, скасовані, в очікуванні– З різними валютами, сумами, помилкамиДокументи / файли– З різними форматами, розмірами, назвами– Вірні й зламані (для негативних кейсів)Продукти / товари– В наявності / немає на складі– Зі знижкою / без, із варіаціями– Видимі / прихованіAPI-токени, ключі, сесії– Валідні, прострочені, з різними правами– Тестові JWT або OAuth-токениПовідомлення / нотифікації– Прочитані / непрочитані– З різними типами: помилка, успіх, інфоІсторія дій (лог)– Для перевірки аудиту, фільтрів, звітів– Коректна дата/час, джерело, IP🛠 Як зручно з цим працювати?✅ Використовуйте фабрики/фікстури (наприклад, у Pytest, FactoryBoy)✅ Робіть SQL-дампи з тестовими наборами✅ Готуйте мокові дані для автотестів✅ Попросіть девів або devops створити "тестові сценарії" для БД📦 Готові тестові дані = готовність до реального світуЦе зменшує час на ручне налаштування, дозволяє швидше ізолювати баги та працювати більш стабільно.
🧾 ADR для тестувальника — навіщо це тобі?ADR (Architecture Decision Record) — це документ, у якому команда фіксує важливі архітектурні рішення про систему: що вирішили, чому, які були альтернативи.На перший погляд здається, що це тільки для архітекторів і девелоперів. Але ні! Для тестувальника ADR — це дуже корисний документ 🗝🔍 Навіщо тестувальнику читати ADR?✅ Розуміння архітектури– Знаєш, чому обрали певний підхід: наприклад, REST замість GraphQL або Redis для кешу.– Це дає контекст для створення тест-кейсів, перевірки сценаріїв відмов, продуктивності тощо.✅ Покриття ризиків– ADR часто описують компроміси — наприклад, «не підтримує офлайн-режим».– Це сигнал: треба протестити edge cases або попередити бізнес.✅ Формування тест-стратегії– Рішення впливають на рівень тестування (UI/API), середовище, мокові сервіси.– Якщо впроваджується нова бібліотека або сервіс — ти вже знаєш, що і де може впасти.✅ Підготовка до змін– Коли архітектура змінюється, ADR допомагає зрозуміти, чому саме і що слід ретестити.🧠 Як працювати з ADR📖 Читайте нові ADR — або підписуйтесь на зміни у репозиторії.✍️ Коментуйте — якщо бачите потенційні проблеми для QA (наприклад, недокументований API).🧩 Використовуйте у тест-плані — додавайте витяги з ADR як аргументацію.🔄 Піднімайте ADR самостійно — якщо тестувальник виявив проблему на архітектурному рівні — це не табу.💡 ADR — не тільки для розробників. Це must-have інструмент і для QA, який хоче бачити всю картину й робити тестування усвідомлено, а не «на око».
🔍 Outline vs Confluence — що обрати для документації?В сучасних командах розробки важливо мати зручне місце для документації, обміну знаннями та співпраці. Два популярних інструменти для цього — Outline і Confluence. Порівняю їх за ключовими параметрами 👇🧠 Простота використанняOutline — мінімалістичний, швидкий, схожий на Notion. Ідеальний для команд, яким важливо просто й швидко документувати знання.Confluence — потужніший, але складніший. Має більше можливостей, але UI іноді перевантажений.🛠 ІнтеграціїConfluence легко інтегрується з Atlassian Jira, Bitbucket та іншими інструментами Atlassian.Outline підтримує GitHub, Slack, Zapier тощо, але інтеграцій менше.📁 Організація знаньOutline — структура на базі колекцій та документів, дуже зрозуміла.Confluence — сторінки, простори, дерева — гнучко, але з часом може стати хаотично.🔐 Безпека та контроль доступуConfluence — потужні ролі, права, SSO, корпоративний рівень безпеки.Outline — простіший контроль доступу, але достатній для більшості невеликих і середніх команд.⚡️ ШвидкодіяOutline — працює дуже швидко, з мінімальними затримками.Confluence — може бути повільнішим, особливо у великих інстанціях.💰 ВартістьOutline▪️ Безкоштовно з відкритим кодом (self-hosted)▪️ SaaS-версія: від $10/користувача/міс.▪️ Ідеально для команд, які хочуть заощадитиConfluence▪️ Безкоштовно до 10 користувачів▪️ Платні тарифи: від $5.75/користувача/міс (Cloud)▪️ Дорожче в Enterprise-сегменті, але дає потужні корпоративні можливості✅ Що обрати?- Якщо стартап або шукаєш простіше — підійде Outline.- Якщо середній/великий бізнес і потрібна повна інтеграція з Atlassian — обирайте Confluence.
TGLIST.COM.UA
