QA Простір
👩💻 QA Простір – спільнота для всіх, хто цікавиться тестуванням!
🔍 Розбираємо QA простими словами.
🔍 Розбираємо QA простими словами.
TGlist рейтингі
0
0
ТүріҚоғамдық
Растау
РасталмағанСенімділік
СенімсізОрналасқан жері
ТілБасқа
Канал құрылған күніNov 18, 2024
TGlist-ке қосылған күні
Mar 25, 2025Қосылған топ
Рекордтар
21.04.202523:59
154Жазылушылар02.04.202523:59
200Дәйексөз индексі17.04.202523:59
651 жазбаның қамтуы22.04.202503:34
0Жарнамалық жазбаның қамтуы26.03.202523:59
26.47%ER21.03.202518:44
52.13%ERR
25.03.202516:56
ЛОГИ У ТЕСТУВАННІ: ЩО ПЕРЕВІРЯТИ І ЯК НЕ ВТРАТИТИ СУТЬ?
“Подивись у логи” — фраза, яку тестувальник чує не рідше, ніж “Почисть кеш”.
❓Але що саме дивитись?
❓І як логи можуть допомогти у пошуку бага?
Розберемося разом.
👇👇
// ЩО ТАКЕ ЛОГ? //
📝 ЛОГ — це журнал подій, у якому фіксуються дії користувача, запити до сервера, відповіді, помилки та технічні деталі, які “не видно з UI”.
📎Залежно від платформи, є:
✏️Backend-логи (на сервері — що саме пішло не так).
✏️Мобільні логи (Logcat — Android, Console — iOS).
✏️Логи з інструментів (Postman, DevTools, Sentry, Firebase Crashlytics).
✍️
// ЩО САМЕ ШУКАТИ У ЛОГАХ? //
✅ Помилки (Errors)
✅ Запити та відповіді API
😑Подивитись, що саме пішло в запиті (Request) і що повернулося у відповіді (Response).
😑Іноді проблема не в UI, а в бекенді.
✅ Таймінги
😑Чи немає затримок у запитах?
😑Занадто довга відповідь = проблеми з продуктивністю.
✅ Фільтрування по ключових словах
😑Використовувати пошук по
✅ User ID / Session ID / Device ID
😑Ці параметри допоможуть знайти потрібну сесію серед сотень логів.
😑
// ЯКІ ІНСТРУМЕНТИ ДОПОМОЖУТЬ? //
😑Postman + Console – показує запит/відповідь і час.
😑ADB Logcat – стандартний логер Android.
😑Charles / Proxyman – перехоплення трафіку.
😑Firebase Crashlytics, Sentry – для логування крашів у продакшені.
😑
// ЩО ПЕРЕВІРЯТИ QA ПЕРЕД БАГ- РЕПОРТОМ? //
😑 Логи — це не тільки для девелоперів.
“Подивись у логи” — фраза, яку тестувальник чує не рідше, ніж “Почисть кеш”.
❓Але що саме дивитись?
❓І як логи можуть допомогти у пошуку бага?
Розберемося разом.
👇👇
// ЩО ТАКЕ ЛОГ? //
📝 ЛОГ — це журнал подій, у якому фіксуються дії користувача, запити до сервера, відповіді, помилки та технічні деталі, які “не видно з UI”.
📎Залежно від платформи, є:
✏️Frontend-логи (консоль браузера, помилки у UI).
✏️Backend-логи (на сервері — що саме пішло не так).
✏️Мобільні логи (Logcat — Android, Console — iOS).
✏️Логи з інструментів (Postman, DevTools, Sentry, Firebase Crashlytics).
✍️
// ЩО САМЕ ШУКАТИ У ЛОГАХ? //
✅ Помилки (Errors)
500 Internal Server Error, Timeout, NullPointerException, TypeError, 404 – усе це треба помічати.✅ Запити та відповіді API
😑Подивитись, що саме пішло в запиті (Request) і що повернулося у відповіді (Response).
😑Іноді проблема не в UI, а в бекенді.
✅ Таймінги
😑Чи немає затримок у запитах?
😑Занадто довга відповідь = проблеми з продуктивністю.
✅ Фільтрування по ключових словах
😑Використовувати пошук по
ERROR, WARN, EXCEPTION, FAILURE.✅ User ID / Session ID / Device ID
😑Ці параметри допоможуть знайти потрібну сесію серед сотень логів.
😑
// ЯКІ ІНСТРУМЕНТИ ДОПОМОЖУТЬ? //
😑Browser DevTools – для перегляду мережевих запитів у вебі.
😑Postman + Console – показує запит/відповідь і час.
😑ADB Logcat – стандартний логер Android.
😑Charles / Proxyman – перехоплення трафіку.
😑Firebase Crashlytics, Sentry – для логування крашів у продакшені.
😑
// ЩО ПЕРЕВІРЯТИ QA ПЕРЕД БАГ- РЕПОРТОМ? //
☑️ Чи справді був запит і яка була відповідь?
☑️ Чи є error/exception у логах?
☑️ Чи повторюється проблема на іншому пристрої або обліковці?
☑️ Чи є залежність від дій користувача?
☑️ Чи є stacktrace, який допоможе розробнику?
😑 Логи — це не тільки для девелоперів.
Тестувальник, який вміє читати логи, завжди буде на крок попереду.
Це допомагає точніше описати баг, зрозуміти, на якому рівні виникла проблема, і навіть… зекономити час усій команді.
16.04.202518:30
➡️ ЩО ТАКЕ GATEWAY І НАВІЩО ВІН ПОТРІБЕН?
У світі мікросервісної архітектури все починається з точки входу — і саме її роль виконує API Gateway.
😑 Під капотом Gateway — це сервер або сервіс, який приймає всі зовнішні запити, обробляє їх згідно з заданими правилами (авторизація, ліміти, трансформації) і пересилає далі до внутрішніх сервісів.
😀😀😀
// НАВІЩО ПОТРІБЕН GATEWAY? //
Коли сервіси були монолітними, вистачало одного API-ендпоінту.
Але із приходом мікросервісів система розділилася на десятки дрібних компонентів — і тут виникли запитання:
Відповіддю став API Gateway — точка, де замикаються всі зовнішні запити.
👇👇
// ЩО ВМІЄ СУЧАСНИЙ GATEWAY? //
😑 Приклади застосування:
⚡️ Популярні рішення:
👁🗨 Що важливо для QA:
😑
⚠️ Ризики використання Gateway
😑
▶️ У наступних статтях — як виглядає
😑
У світі мікросервісної архітектури все починається з точки входу — і саме її роль виконує API Gateway.
😑 Під капотом Gateway — це сервер або сервіс, який приймає всі зовнішні запити, обробляє їх згідно з заданими правилами (авторизація, ліміти, трансформації) і пересилає далі до внутрішніх сервісів.
Він працює як проксі з логікою, часто використовуючи маршрути, плагіни або фільтри для контролю потоку даних. Це перша точка контакту клієнта з системою, яка може сильно впливати на безпеку, швидкість і стабільність.
😀😀😀
// НАВІЩО ПОТРІБЕН GATEWAY? //
Коли сервіси були монолітними, вистачало одного API-ендпоінту.
Але із приходом мікросервісів система розділилася на десятки дрібних компонентів — і тут виникли запитання:
❓ Як реалізувати єдину точку входу?
❓ Як захистити внутрішню архітектуру?
❓ Як керувати доступом, логуванням і навантаженням?
Відповіддю став API Gateway — точка, де замикаються всі зовнішні запити.
👇👇
// ЩО ВМІЄ СУЧАСНИЙ GATEWAY? //
🎥 Маршрутизація — розподіл запитів на відповідні сервіси
🎥 Аутентифікація та авторизація — перевірка токенів і прав
🎥 Rate limiting — захист від DDoS і перевищення лімітів
🎥 Кешування — зменшення навантаження на бекенд
🎥 Трансформація даних — зміна формату запитів/відповідей
🎥 Логування і моніторинг — фіксація всієї активності
😑 Приклади застосування:
😑 Один запит на api.mysite.com може всередині бути розподілений між /auth, /products, /orders
😑 Gateway обмежує зовнішні інтеграції лише дозволеними методами
😑 Уся автентифікація зосереджена в одному місці
😑 Внутрішні сервіси ізольовані від зовнішнього світу
⚡️ Популярні рішення:
💖 Kong — open-source з розвинутим ком’юніті
💖 NGINX — легкий, швидкий, зручний для кастомізації
💖 Amazon API Gateway — хмарне рішення для AWS
💖 Spring Cloud Gateway / Zuul — частина екосистеми Java
👁🗨 Що важливо для QA:
😑 Gateway може змінювати поведінку API — це слід враховувати під час тестування
😑 Статуси 403, 429, 502 — часто приходять не від самого API, а від gateway
😑 Rate limiting варто перевіряти з кількома запитами поспіль
😑 Приклад edge-case: зламаний токен, перевищення розміру запиту, повторне надсилання
😑 У проєктах, де авторизація “на gateway”, логіка токенів і ролей тестується саме тут
😑
⚠️ Ризики використання Gateway
💢 Одна точка відмови — якщо gateway падає, недоступні всі сервіси.
💢 Помилки в налаштуваннях — можуть заблокувати легальні запити або відкрити доступ тим, кому не слід.
💢 Мішень для атак — gateway першим приймає запити ззовні, тому часто стає ціллю.
💢 Вразливість через застаріле ПЗ — без оновлень можуть з’явитися діри в безпеці.
💢 Відсутність резерву — без запасного плану збій gateway = збій системи.
😑
▶️ У наступних статтях — як виглядає
request flow через Gateway та як правильно перевіряти rate limiting.😑
02.04.202508:26
ТЕСТУВАННЯ ГІПОТЕЗ : як QA може покращити продукт, а не лише знайти баги
Сьогодні роль тестувальника значно ширша: він може впливати на розвиток продукту, пропонувати зміни й експерименти, перевіряти припущення та сприяти бізнес-результатам.
Це і є тестування гіпотез — навичка, яка підносить QA на рівень продуктової команди.
Давайте розберемося, як саме це працює
👇👇
// ЩО ТАКЕ ГІПОТЕЗА В ЦИФРОВМУ ПРОДУКТІ? //
Продуктова гіпотеза — це припущення, що певна зміна (в UI, логіці, поведінці) призведе до покращення якогось результату:
конверсії, ретеншену, часу на сайті, кліків, доходу.
✏️ Формат гіпотези:
«Якщо ми зробимо ___, тоді ___ зросте / зменшиться».
😑 Приклади:
✍️
// ЯК ТЕСТУВАЛЬНИК МОЖЕ ВПЛИВАТИ НА ГІПОТЕЗИ? //
1️⃣ Спостерігає і формує гіпотези на основі фідбеку
QA працює на стику користувача, UI та бекенду. Він бачить слабкі місця.
📌 Приклад:
😑Гіпотеза: якщо розбити форму на 2 екрани — більше користувачів завершать реєстрацію.
2️⃣ Бере участь у підготовці до A/B тестування
😑 QA перевіряє:
😑 Інструменти: Mixpanel, Amplitude, PostHog, Firebase Events
3️⃣ Валідує результати: дивиться не тільки на цифри, а й на баги
Іноді варіант B дає кращу метрику, але… зламаний на мобілці.
QA — той, хто допомагає виявити подібні нюанси.
😑
// ЯКІ ГІПОТЕЗИ МОЖЕ ЗАПРОПОНУВАТИ QA? //
Ось кілька категорій:
😮💨 UX-покращення:
😮💨 Технічні/перформанс гіпотези:
😮💨 Безпека та збереження даних:
🧩🧩
// ЯК ВІДРІЗНИТИ БАГ ВІД ГІПОТЕЗИ? //
📌 Приклад:
👇👇
// ІНСТРУМЕНТИ ДЛЯ ГІПОТЕЗ У QA-РОБОТІ //
😑
Гіпотези допомагають:
Сьогодні роль тестувальника значно ширша: він може впливати на розвиток продукту, пропонувати зміни й експерименти, перевіряти припущення та сприяти бізнес-результатам.
Це і є тестування гіпотез — навичка, яка підносить QA на рівень продуктової команди.
Давайте розберемося, як саме це працює
👇👇
// ЩО ТАКЕ ГІПОТЕЗА В ЦИФРОВМУ ПРОДУКТІ? //
Продуктова гіпотеза — це припущення, що певна зміна (в UI, логіці, поведінці) призведе до покращення якогось результату:
конверсії, ретеншену, часу на сайті, кліків, доходу.
✏️ Формат гіпотези:
«Якщо ми зробимо ___, тоді ___ зросте / зменшиться».
😑 Приклади:
*️⃣Якщо змінити колір кнопки «Купити», CTR зросте.
*️⃣Якщо додати індикатор прогресу в анкеті, більше користувачів її завершать.
*️⃣Якщо замінити модальне вікно на інлайн-повідомлення, конверсія не впаде.
✍️
// ЯК ТЕСТУВАЛЬНИК МОЖЕ ВПЛИВАТИ НА ГІПОТЕЗИ? //
1️⃣ Спостерігає і формує гіпотези на основі фідбеку
QA працює на стику користувача, UI та бекенду. Він бачить слабкі місця.
📌 Приклад:
😑Тестувальник помічає: форма реєстрації довга, і часто користувачі не доходять до останнього кроку.
😑Гіпотеза: якщо розбити форму на 2 екрани — більше користувачів завершать реєстрацію.
2️⃣ Бере участь у підготовці до A/B тестування
😑 QA перевіряє:
😑Чи коректно працюють варіанти А і B?
😑Чи зібрані події для аналітики?
😑Чи все видно в DevTools / Network / аналітичних подіях?
😑 Інструменти: Mixpanel, Amplitude, PostHog, Firebase Events
3️⃣ Валідує результати: дивиться не тільки на цифри, а й на баги
Іноді варіант B дає кращу метрику, але… зламаний на мобілці.
QA — той, хто допомагає виявити подібні нюанси.
😑
// ЯКІ ГІПОТЕЗИ МОЖЕ ЗАПРОПОНУВАТИ QA? //
Ось кілька категорій:
😮💨 UX-покращення:
*️⃣Кнопка «Підтвердити» виглядає неактивною → користувачі не тиснуть.
*️⃣ Після натискання немає анімації → здається, що нічого не відбулось.
*️⃣ Форма надто довга → додати індикатор прогресу.
😮💨 Технічні/перформанс гіпотези:
*️⃣ Фільтр вантажиться занадто повільно → винести частину логіки на клієнт.
*️⃣ Стартова сторінка важка → lazy-loading зображень покращить перформанс.
😮💨 Безпека та збереження даних:
*️⃣ Якщо запит надсилається ще до підтвердження → користувач може випадково втратити дані.
🧩🧩
// ЯК ВІДРІЗНИТИ БАГ ВІД ГІПОТЕЗИ? //
😮💨 Баг: явно неправильна поведінка (UI ламається, дані не зберігаються, сторінка не відкривається).
😮💨 Гіпотеза: все працює, але можна зробити краще. UX — не помилка, а шанс на покращення.
📌 Приклад:
*️⃣Кнопка на сайті помітна, клікабельна. Але: CTR низький. Користувачі її пропускають
*️⃣Тут немає бага. Але гіпотеза:
«Якщо змінити розмір і додати анімацію — більше людей натисне».
👇👇
// ІНСТРУМЕНТИ ДЛЯ ГІПОТЕЗ У QA-РОБОТІ //
🔸 Google Analytics / Mixpanel / PostHog – поведінка користувачів
🔸 Chrome DevTools – перевірка логіки на фронті
🔸 Charles / Proxyman – відстеження запитів
🔸 SQL / BigQuery – аналітика поведінки
🔸 A/B-тест платформи – Optimizely, LaunchDarkly, Firebase Remote Config
😑
Гіпотези допомагають:
✅ покращити UX
✅ виявити слабкі місця
✅ впливати на метрики
✅ зробити продукт зручнішим для людей
17.04.202517:43
ЗАПИТ ЧЕРЕЗ API GATEWAY — ЯК ПРОХОДИТЬ ТА ЯК ТЕСТУВАТИ?
Ми вже розібралися, що таке API Gateway, то саме час зазирнути усередину: як виглядає request flow і на чому QA має зосередитись.
👇👇
1️⃣ ВХІДНИЙ ЗАПИТ ВІД КЛІЄНТА
Користувач або система надсилає
▶️ Тут часто спрацьовує HTTPS-термінація — це момент, коли зашифрований запит (
2️⃣ ПЕРЕВІРКА АВТЕНТИФІКАЦІЇ/АВТОРИЗАЦІЇ
Gateway аналізує заголовки, перевіряє токен (наприклад, JWT), роль користувача, можливі обмеження по IP або
3️⃣ RATE LIMITING
Перед передачею запиту далі спрацьовує логіка обмежень — наприклад, не більше 10 запитів за хвилину. Якщо перевищено — миттєва відповідь
4️⃣ТРАНСФОРМАЦІЯ ТА МАРШРУТИЗАЦІЯ
Gateway може змінити тіло запиту, заголовки або маршрут (
5️⃣ОТРИМАННЯ ВІДПОВІДІ І ЗВОРОТНА ТРАНСФОРМАЦІЯ
Відповідь із внутрішнього сервісу проходить зворотний шлях: фільтрація/трансформація, додавання заголовків (наприклад, CORS), кешування, логування — і лише потім відправка клієнту.
▶️CORS (Cross-Origin Resource Sharing) — це механізм, який дозволяє браузеру вирішити, чи може front з одного домену отримувати відповіді від backend на іншому.
😑
❓ ЩО ПЕРЕВІРЯТИ QA (з прикладами):
👇
😮💨 Rate Limiting
➡️ ПРИКЛАДИ:
😑Надіслати 11
😑Перевірити, що роль "admin" має інший ліміт, ніж "user"
😑Створити тест, який чекає 60 сек і перевіряє скидання лічильника
😠
😮💨 Аутентифікація/Авторизація
➡️ ПРИКЛАДИ:
😑Запит
😑Запит із токеном звичайного користувача на
😑Тест на роль “manager” — доступ лише до
😠
😮💨 Маршрутизація
➡️ ПРИКЛАДИ:
😑Запит до
😑Запит до
😑Звичайний юзер запитує
😑
😮💨 Заголовки (включно з CORS)
➡️ ПРИКЛАДИ:
😑Перевірити, що запит з домену
😑Тест, де Authorization заголовок не зникає після 302 редиректа
😑Запит з Origin:
😑
😮💨 Edge-кейси
➡️ ПРИКЛАДИ:
😑
😑
😑Повторний
😑
Ми вже розібралися, що таке API Gateway, то саме час зазирнути усередину: як виглядає request flow і на чому QA має зосередитись.
👇👇
1️⃣ ВХІДНИЙ ЗАПИТ ВІД КЛІЄНТА
Користувач або система надсилає
HTTP-запит (наприклад, GET/products) на домен, пов’язаний з gateway (наприклад, api.mysite.com).▶️ Тут часто спрацьовує HTTPS-термінація — це момент, коли зашифрований запит (
HTTPS) розшифровується (термінується) на стороні gateway або load balancer, і далі в системі йде як звичайний HTTP.2️⃣ ПЕРЕВІРКА АВТЕНТИФІКАЦІЇ/АВТОРИЗАЦІЇ
Gateway аналізує заголовки, перевіряє токен (наприклад, JWT), роль користувача, можливі обмеження по IP або
client_id. Якщо щось не так — повертається 401 або 403.3️⃣ RATE LIMITING
Перед передачею запиту далі спрацьовує логіка обмежень — наприклад, не більше 10 запитів за хвилину. Якщо перевищено — миттєва відповідь
429 Too Many Requests.4️⃣ТРАНСФОРМАЦІЯ ТА МАРШРУТИЗАЦІЯ
Gateway може змінити тіло запиту, заголовки або маршрут (
/products перетворити на /api/v1/items) і передати далі в мікросервіс.5️⃣ОТРИМАННЯ ВІДПОВІДІ І ЗВОРОТНА ТРАНСФОРМАЦІЯ
Відповідь із внутрішнього сервісу проходить зворотний шлях: фільтрація/трансформація, додавання заголовків (наприклад, CORS), кешування, логування — і лише потім відправка клієнту.
▶️CORS (Cross-Origin Resource Sharing) — це механізм, який дозволяє браузеру вирішити, чи може front з одного домену отримувати відповіді від backend на іншому.
Якщо CORS налаштовано неправильно, frontend не отримає відповідь навіть при правильному запиті.
😑
❓ ЩО ПЕРЕВІРЯТИ QA (з прикладами):
👇
😮💨 Rate Limiting
😑 Надішли більше запитів, ніж дозволено (наприклад, 11 при ліміті 10/хв)
😑 Перевір 429 статус та повідомлення
😑 Зачекай хвилину — чи обнуляється ліміт?
😑 Різні ролі — різні обмеження?
➡️ ПРИКЛАДИ:
😑Надіслати 11
GET /products запитів протягом хвилини😑Перевірити, що роль "admin" має інший ліміт, ніж "user"
😑Створити тест, який чекає 60 сек і перевіряє скидання лічильника
😠
😮💨 Аутентифікація/Авторизація
😑 Без токена, з битим або простроченим токеном
😑 401 чи 403 — чи відповідає статус очікуванню?
😑 Перевір дозволи для кожної ролі
➡️ ПРИКЛАДИ:
😑Запит
GET /orders без токена — очікуємо 401😑Запит із токеном звичайного користувача на
/admin — очікуємо 403😑Тест на роль “manager” — доступ лише до
/reports, але не до /users😠
😮💨 Маршрутизація
😑 Валідні та невалідні URl
😑 Заборонені шляхи для звичайного користувача
➡️ ПРИКЛАДИ:
😑Запит до
GET /api/v1/products → має потрапити до відповідного сервісу😑Запит до
GET /api/v1/nonexistent → 404 Not Found😑Звичайний юзер запитує
/admin/settings → 403😑
😮💨 Заголовки (включно з CORS)
😑 Чи зберігається Authorization при редиректах
😑 Чи правильні CORS-заголовки для фронтенду
➡️ ПРИКЛАДИ:
😑Перевірити, що запит з домену
app.example.com має правильні CORS-заголовки😑Тест, де Authorization заголовок не зникає після 302 редиректа
😑Запит з Origin:
evil.com → перевірити, що CORS блокує😑
😮💨 Edge-кейси
😑 Великі тіла запитів
😑 Довгі URI
😑 Повторний запит з тим самим токеном
➡️ ПРИКЛАДИ:
😑
POST із тілом 1 МБ JSON → чи обробляється без помилки?😑
GET-запит з 250 символами в URI — чи не обрізається?😑Повторний
POST /checkout з однаковим токеном — чи не створює дубль?😑
24.03.202515:52
🧠 ROOT CAUSE ANALYSIS (RCA): Як знайти справжню причину проблеми у тестуванні?
Симптоми усунули — а баг повернувся після релізу. Знайоме? Таке трапляється, якщо усунути лише симптом, а не саму першопричину.
🤓Щоб уникнути повторень, у тестуванні використовують Root Cause Analysis (RCA) — системний підхід до виявлення джерела помилки. Він дозволяє розібратись у глибині проблеми замість того, щоб боротися з наслідками.
// ЩО ТАКЕ RCA? //
👇👇
🔍 Root Cause Analysis (RCA) — це методика, яка дозволяє системно дослідити, чому виникла помилка, і знайти саме ту причину, яка спричинила ланцюгову реакцію.
📝 RCA використовується у QA, розробці, DevOps, продуктовому менеджменті, бізнес-аналізі — скрізь, де важливо розуміти джерело проблеми, а не лише її поверхню.
✏️
// ТРОХИ ІСТОРІЇ //
RCA виник ще у середині XX століття, коли на виробництві стали впроваджувати системи контролю якості.
💻 У сфері IT RCA прижився як спосіб уникати повторення критичних багів, втрат користувачів і збою в процесах.
✍️
// НАВІЩО RCA ТЕСТУВАЛЬНИКУ? //
✅ Щоб не латати одне й те саме після кожного релізу
✅ Щоб покращити тест-кейси та процеси в команді
✅ Щоб зрозуміти — чому бага не вловили на ранньому етапі?
✅ Щоб працювати не реактивно, а проактивно
👇👇
// ЕТАПИ ROOT CAUSE ANALYSIS //
1️⃣ Ідентифікація проблеми
– Що сталося? Де саме? Які наслідки?
– Збираємо логі, дані користувача, дії перед багом.
2️⃣ Аналіз симптомів
– UI? API? інтеграція?
– Чи повторюється? Які ознаки?
3️⃣ Пошук першопричини
Використовуються популярні RCA-методи:
4️⃣ Розробка рішення
Після того як знайдена коренева причина, розробляється стратегія усунення, а не просто фікс.
5️⃣ Впровадження + перевірка
Чи не повторюється баг? Чи змінився процес? Чи покращилась якість?
✍️
🐟 Приклад з практики: Fishbone Diagram
🔎 Ситуація: при натисканні кнопки Search у мобільному додатку додаток "падає".
😑 Розбираємо через Fishbone Diagram:
👁🗨 ВИСНОВОК
📝
🔣 Інший приклад: метод 5 Whys
🔎Ситуація: пошук не працює при введенні спецсимволів.
☑️ Рішення: Впровадити процес узгодження вимог із QA.
✍️
// ПЕРЕВАГИ RCA У QA //
🔥Root Cause Analysis — це не просто інструмент, а спосіб мислення. Він вчить бачити за багами системні прогалини: у процесах, комунікаціях чи вимогах.
Симптоми усунули — а баг повернувся після релізу. Знайоме? Таке трапляється, якщо усунути лише симптом, а не саму першопричину.
🤓Щоб уникнути повторень, у тестуванні використовують Root Cause Analysis (RCA) — системний підхід до виявлення джерела помилки. Він дозволяє розібратись у глибині проблеми замість того, щоб боротися з наслідками.
// ЩО ТАКЕ RCA? //
👇👇
🔍 Root Cause Analysis (RCA) — це методика, яка дозволяє системно дослідити, чому виникла помилка, і знайти саме ту причину, яка спричинила ланцюгову реакцію.
📝 RCA використовується у QA, розробці, DevOps, продуктовому менеджменті, бізнес-аналізі — скрізь, де важливо розуміти джерело проблеми, а не лише її поверхню.
✏️
// ТРОХИ ІСТОРІЇ //
RCA виник ще у середині XX століття, коли на виробництві стали впроваджувати системи контролю якості.
Наприклад, заводи Toyota використовували RCA у рамках Lean Manufacturing та Total Quality Management (TQM).
💻 У сфері IT RCA прижився як спосіб уникати повторення критичних багів, втрат користувачів і збою в процесах.
✍️
// НАВІЩО RCA ТЕСТУВАЛЬНИКУ? //
✅ Щоб не латати одне й те саме після кожного релізу
✅ Щоб покращити тест-кейси та процеси в команді
✅ Щоб зрозуміти — чому бага не вловили на ранньому етапі?
✅ Щоб працювати не реактивно, а проактивно
👇👇
// ЕТАПИ ROOT CAUSE ANALYSIS //
1️⃣ Ідентифікація проблеми
– Що сталося? Де саме? Які наслідки?
– Збираємо логі, дані користувача, дії перед багом.
2️⃣ Аналіз симптомів
– UI? API? інтеграція?
– Чи повторюється? Які ознаки?
3️⃣ Пошук першопричини
Використовуються популярні RCA-методи:
🔹 5 Whys – запитуємо “чому?” 5 разів поспіль
🔹 Fishbone Diagram – візуально розкладаємо фактори за категоріями
🔹 Pareto Analysis (80/20) – виявляємо топ-причини, що викликають більшість помилок
4️⃣ Розробка рішення
Після того як знайдена коренева причина, розробляється стратегія усунення, а не просто фікс.
5️⃣ Впровадження + перевірка
Чи не повторюється баг? Чи змінився процес? Чи покращилась якість?
✍️
🐟 Приклад з практики: Fishbone Diagram
🔎 Ситуація: при натисканні кнопки Search у мобільному додатку додаток "падає".
😑 Розбираємо через Fishbone Diagram:
Падіння додатку
⬇️
--------------------------
| | | |
Код Процес Інфра Вимоги
⬇️ ⬇️ ⬇️ ⬇️
- пропущена перевірка null
- немає рев’ю-коду
- CI/CD дав збій
- нечітко описана UX-логіка
👁🗨 ВИСНОВОК
✔️Причина — неперевірене null-значення у відповіді від API. Тест-кейси цього не врахували.
☑️ Рішення:
– Додати null-check
– Розширити тестування
– Додати рев’ю перед релізами
📝
🔣 Інший приклад: метод 5 Whys
🔎Ситуація: пошук не працює при введенні спецсимволів.
1. Чому? — API повертає помилку
2. Чому? — не враховані спецсимволи
3. Чому? — не було валідації
4. Чому? — QA не залучили до написання вимог
5. Чому? — процес вимог не включає тестувальників
☑️ Рішення: Впровадити процес узгодження вимог із QA.
✍️
// ПЕРЕВАГИ RCA У QA //
✅ Запобігання повторним дефектам
✅ Оптимізація процесів (виявляються слабкі місця)
✅ Зниження витрат (менше часу на фікси у проді)
✅ Покращення документації, вимог, тест-кейсів
✅ Загальне зростання якості продукту
🔥Root Cause Analysis — це не просто інструмент, а спосіб мислення. Він вчить бачити за багами системні прогалини: у процесах, комунікаціях чи вимогах.
03.04.202510:40
❌ NEGATIVE TESTING: НАВІЩО ТЕСТУВАТИ ТЕ, ЩО НЕ МАЄ ПРАЦЮВАТИ?
Основа Negative Testing — пошук сценаріїв, у яких система має відмовити, відреагувати помилкою або не виконати дію.
😑Negative Testing — це не просто “ламати систему”.
Це професійний підхід до стабільності, безпеки та якості продукту.
Саме тут народжуються найцінніші баги.
✍️
// ЩО ТАКЕ NEGATIVE TESTING? //
Negative Testing (негативне тестування) — це підхід, за якого ми навмисно вводимо неправильні, неочікувані або граничні дані, аби перевірити, як система поводиться в “аномальних” умовах.
😮💨Це протилежність positive testing, коли ми перевіряємо, що все працює за планом.
Більшість критичних багів виявляються саме під час негативного тестування — тому його важливість не можна недооцінювати.
👇👇
👁🗨 Навіщо це потрібно?
✍️
// ПРИКЛАДИ НЕГАТИВНОГО ТЕСТУВАННЯ //
1️⃣ UI
❓Що перевіряємо:
Валідацію, повідомлення про помилки, стабільність форми
😀
2️⃣ API
🔤Очікуємо:
😀
3️⃣ Мобільний додаток
❓Що перевіряємо:
Обробку переривань, доступів, таймаутів, станів
⬇️⬇️
// ЯК ПОБУДУВАТИ НЕГАТИВНИЙ СЦЕНАРІЙ? //
// ДОДАТКОВІ ПОРАДИ //
Основа Negative Testing — пошук сценаріїв, у яких система має відмовити, відреагувати помилкою або не виконати дію.
😑Negative Testing — це не просто “ламати систему”.
Це професійний підхід до стабільності, безпеки та якості продукту.
Саме тут народжуються найцінніші баги.
✍️
// ЩО ТАКЕ NEGATIVE TESTING? //
Negative Testing (негативне тестування) — це підхід, за якого ми навмисно вводимо неправильні, неочікувані або граничні дані, аби перевірити, як система поводиться в “аномальних” умовах.
😮💨Це протилежність positive testing, коли ми перевіряємо, що все працює за планом.
Більшість критичних багів виявляються саме під час негативного тестування — тому його важливість не можна недооцінювати.
👇👇
👁🗨 Навіщо це потрібно?
😑 Виявити нестійкість у коді
😑 Перевірити обробку помилок (error handling)
😑 Запобігти крашам і втраті даних
😑 Підвищити довіру до продукту: баги часто ховаються саме в edge-case’ах
✍️
// ПРИКЛАДИ НЕГАТИВНОГО ТЕСТУВАННЯ //
1️⃣ UI
🔸 Ввести в поле “Телефон” — текст: abcdef
🔸 Вставити у форму emoji або спецсимволи
🔸 Натиснути “Зберегти”, не заповнивши обов’язкові поля
🔸 Ввести занадто довгий текст (500+ символів у полі “Ім’я”)
❓Що перевіряємо:
Валідацію, повідомлення про помилки, стабільність форми
😀
2️⃣ API
🔸 Відправити запит без токена авторизації
🔸 Передати userId: null або email: "123"
🔸 Викликати PUT замість POST
🔤Очікуємо:
403 / 401 / 422 — чи правильно реагує бекенд?😀
3️⃣ Мобільний додаток
🔸 Вимкнути інтернет і натиснути “Оновити”
🔸 Повернути екран під час завантаження
🔸 Кілька разів швидко натиснути на кнопку
🔸 Надати доступ до камери, а потім заборонити
❓Що перевіряємо:
Обробку переривань, доступів, таймаутів, станів
⬇️⬇️
// ЯК ПОБУДУВАТИ НЕГАТИВНИЙ СЦЕНАРІЙ? //
✔️ Подумати: що піде не так?
✔️ Визначити точку входу (UI/API/дія користувача)
✔️ Ввести дані або умову, яка порушує норму
✔️ Передбачити очікувану негативну реакцію
✔️ Перевірити, чи не зламалась система
// ДОДАТКОВІ ПОРАДИ //
🔹 Повідомлення про помилки мають бути чіткі й зрозумілі
🔹 Логувати результати — негативне тестування допомагає писати хороші тест-кейси
🔹 Враховувати edge-case’и: null, пусті поля, нестандартні мови, неочікувані типи даних
🔹 Не обмежуватись UI — тестувати також API, базу, мережу
Көбірек мүмкіндіктерді ашу үшін кіріңіз.
