🇺🇦 Комора тестувальника | QA Info

🔄 Як QA тестує rollback після невдалого оновлення Rollback — це повернення системи до попередньої стабільної версії після невдалого релізу. QA перевіряє не тільки сам апдейт, а й те, чи продукт виживе, якщо щось піде не так. 1. Перевірка стану даних після rollback: QA дивиться, чи не зникли користувачі, замовлення, налаштування або нові записи після повернення на стару версію. Особливо критично для payment flow і профілів. 2. Сумісність старого й нового: Нова версія могла змінити структуру даних або API. QA перевіряє, чи стара версія не “ламається” після повернення назад. 3. Активні користувачі під час rollback: Що буде, якщо користувач оформлював замовлення саме у момент rollback? QA тестує завислі стани, дублікати і втрачені дії. 4. Кеш і старі ресурси: Після rollback браузер або app можуть тримати старі JS/CSS-файли. Через це UI починає працювати некоректно або частково ламається. 5. Мобільні додатки і версії API: Mobile app може вже працювати з новим API, а rollback повернув старий бекенд. QA перевіряє сумісність і graceful degradation. 6. Логи та моніторинг: Після rollback QA аналізує логи, crash reports, 500 errors, метрики API. Часто проблема проявляється не в UI, а у внутрішніх помилках. 7. Smoke після rollback: Обов’язково перевіряються критичні сценарії: логін, оплата, створення даних, push notifications, авторизація. Висновок: Хороший rollback — це не просто “повернути стару версію”. QA перевіряє, чи продукт залишився стабільним, чи не втратились дані і чи користувачі не потрапили у зламаний стан після відкату релізу. Комора тестувальника

🤔 Як складати матрицю простежуваності? Матриця простежуваності — таблиця, що показує зв'язок між вимогами та тестами: - рядки: вимоги; - стовпці: тестові кейси; - на перетинах — позначки (покрито/не покрито); Вона допомагає переконатися, що всі вимоги протестовані. Комора тестувальника

📱 Що QA має перевірити перед запуском mobile app Перед релізом мобільного додатку QA перевіряє не лише “чи працюють кнопки”. Mobile app — це десятки сценаріїв, які можуть зламатися вже у перші години після публікації. 1. Критичні user-flow: Логін, реєстрація, onboarding, push notifications, оплата, завантаження контенту. Саме ці сценарії користувач бачить першими. 2. Різні пристрої та ОС: Android/iOS, старі й нові версії систем, маленькі та великі екрани. Додаток може працювати ідеально на одному телефоні й ламатись на іншому. 3. Повільний інтернет та offline: QA перевіряє 3G/нестабільний Wi-Fi, втрату мережі під час дій, кешування та retry-логіку. Mobile користувачі часто працюють у поганих мережах. 4. Push notifications: Чи приходять повідомлення, коли app закритий? Чи відкривається правильний екран після натискання? Чи не дублюються пуші? 5. Background / foreground сценарії: Згорнути app → повернутись через 10 хв → продовжити дію. Багато додатків ламаються саме після переходу у background. 6. Дозволи та системні функції: Камера, геолокація, мікрофон, фото. QA перевіряє, що буде, якщо користувач заборонить доступ. 7. Продуктивність і батарея: Нагрів телефону, швидке розрядження, лаги, memory leaks. Mobile app має бути стабільним навіть після довгої сесії. 8. Store readiness: Назва, іконка, splash screen, version code, deep links, analytics, crash reporting. Іноді баги починаються ще до запуску app. Висновок: Mobile QA — це перевірка реального життя користувача: поганий інтернет, різні пристрої, випадкові дії та довгі сесії. Перед релізом важливо тестувати не “ідеальний сценарій”, а реальні умови, у яких app буде жити. Комора тестувальника

⚡️ AI вже не просто тренд. Це одна з найперспективніших сфер, у яку можна зайти без технічної освіти та багаторічного досвіду. Поки одні лише читають про штучний інтелект, інші вже використовують його для автоматизації задач, запуску власних проєктів та розвитку кар'єри. Запрошуємо на безкоштовний 3-денний інтенсив «AI-автоматизація без програмування».

▶️ День 1: Дізнаєтесь, хто такий AI-автоматизатор та створите свого першого AI-асистента в n8n. ▶️ День 2: Налаштуєте його роботу та протестуєте на реальних задачах. ▶️ День 3: Розберете способи розвитку та монетизації навичок AI-автоматизації.

🚀 Ви отримаєте практичний досвід роботи з AI та навички, які вже сьогодні допомагають спеціалістам ставати ціннішими на ринку праці. 🎁 Бонус: гайд «Як інтегрувати AI у своє життя». 👉 Спробуйте одну з найперспективніших AI-спеціальностей безкоштовно: https://i.goit.global/raYcH

💳 Що QA перевіряє перед payment flow Payment flow — одна з найкритичніших частин продукту. Тут навіть маленький баг може коштувати бізнесу грошей або довіри користувачів. Тому QA перевіряє не тільки кнопку “Оплатити”. 1. Коректність суми: QA перевіряє знижки, податки, доставку, конвертацію валют, округлення. Часто саме тут зʼявляються фінансові баги. 2. Повторні платежі: Подвійний клік по кнопці Pay, оновлення сторінки під час оплати, Back у браузері → система не повинна створювати дублікати транзакцій. 3. Негативні сценарії: Неправильна картка, недостатньо коштів, timeout банку, відхилений платіж. QA перевіряє, чи користувач отримує зрозумілу помилку. 4. Поведінка після успішної оплати: Чи створюється замовлення? Чи приходить email? Чи оновлюється статус у профілі? Баги часто виникають уже після успішного платежу. 5. Мережеві проблеми: Відключення інтернету під час оплати, повільний API, зависання loader. Payment flow має бути стійким навіть при нестабільній мережі. 6. Безпека: Токени, HTTPS, приховані дані картки, коректна авторизація. QA перевіряє, щоб чутлива інформація не потрапляла у логи або LocalStorage. 7. Інтеграції: Платіжні сервіси у sandbox часто працюють ідеально. QA тестує різні відповіді API, timeout-и та нестандартні кейси реальних payment providers. Висновок: Payment flow — це не одна кнопка, а складний ланцюг дій та інтеграцій. Хороший QA тестує не тільки “успішну оплату”, а всі сценарії, де система може втратити гроші або користувача. Комора тестувальника

🤔 Що робити, якщо виник баг зі статусом "дублікат"? Перевірити, чи баг дійсно збігається з уже існуючим. Якщо так, додати додаткову інформацію до існуючого бага. Якщо баг унікальний, повідомити команду про необхідність змінити статус. Комора тестувальника

⚡️ Як QA тестує race conditions без автоматизації Race condition — це баг, який виникає, коли кілька дій або запитів відбуваються одночасно і система не встигає правильно обробити порядок подій. Такі баги часто “рандомні” і дуже дратують команду. 1. Швидкі повторні дії: QA багато разів швидко натискає одну кнопку: Submit, Pay, Save. Якщо система не блокує повторний запит — можуть зʼявитися дублікати або конфлікти даних. 2. Кілька вкладок одночасно: Відкриваємо продукт у 2–3 вкладках → виконуємо різні дії паралельно. Наприклад: змінюємо профіль в одній вкладці і видаляємо акаунт в іншій. 3. Штучне уповільнення мережі: Через DevTools → Slow 3G або custom throttling. Повільні відповіді API часто провокують race conditions, які не видно на швидкому інтернеті. 4. Паралельні запити: QA одночасно запускає кілька дій: фільтри, сортування, refresh, save. Якщо state management слабкий — UI починає “стрибати” або губити дані. 5. Повторне відкриття фічі: Почати дію → оновити сторінку → повернутись назад → повторити. Часто система не очікує, що користувач перерве процес посередині. 6. Перевірка через Network tab: DevTools показує, чи дублюються запити, чи приходять responses у неправильному порядку. Це один із найкращих способів побачити race condition без автоматизації. Висновок: Race conditions не завжди видно одразу. QA, який тестує швидкі, паралельні та нестандартні дії, може знайти баги, які проявляться тільки під навантаженням у production. Комора тестувальника

🤔 Що таке звіти про помилки? Звіти про помилки — це документи, які описують виявлені помилки в програмному забезпеченні. Вони містять інформацію про крок відтворення, очікуваний і фактичний результати, а також дані про середовище, в якому сталася помилка. Добре складений звіт про помилку допомагає розробникам швидше зрозуміти і виправити проблему. Звіти про помилки є ключовою частиною процесу тестування. Комора тестувальника

Відкривають двері у світ ІТ — тільки сьогодні і абсолютно безкоштовно! 🔥 Реєструйтесь: i.goit.global

🔥 5 багів, які зʼявляються тільки після релізу Є категорія багів, які майже неможливо помітити на staging. Вони проявляються тільки тоді, коли продукт отримує реальних користувачів, навантаження і живі дані. 1. Race conditions: На staging усе працює стабільно, бо користувачів мало. Після релізу тисячі людей одночасно натискають кнопки → дублікати замовлень, зламані стани, конфлікти даних. 2. Кеш і старі дані: У production користувачі мають старий кеш браузера, LocalStorage, cookies. Після релізу UI може показувати стару версію даних або ламати логіку авторизації. 3. Проблеми з реальними даними: Тестові дані майже завжди «чисті». У production зʼявляються емодзі, довгі імена, рідкісні символи, величезні таблиці → UI і база починають ламатися. 4. Збої сторонніх сервісів: Sandbox API працює ідеально. Реальні платіжки, email-сервіси або OAuth можуть повертати timeout, rate-limit або нестандартні помилки. 5. Flaky баги під навантаженням: На staging фіча працює швидко. У production сервер повільніший, API затримується → користувач натискає кнопку повторно, отримує дублікати або завислий loader. Висновок: Частина багів народжується лише у “живому” середовищі. Тому QA повинен думати не тільки про функціонал, а й про навантаження, кеш, реальних користувачів і поведінку системи після релізу. Комора тестувальника

🤔 Якщо потрібно додати якийсь умову, який запит для цього потрібен? У запиті потрібен умовний оператор. У SQL це — WHERE, CASE WHEN, а в API — параметр запиту, який фільтрує або змінює поведінку відповіді. Комора тестувальника

⚠️ Чому staging ≠ production і як це ламає тестування Багато QA стикаються з ситуацією: на staging все ідеально, а після релізу продукт починає ламатися. Причина проста — staging майже ніколи не дорівнює production. 1. Різні дані: На staging зазвичай тестові акаунти, маленька база і «чисті» сценарії. У production — реальні користувачі, великі обʼєми даних і хаотична поведінка. Саме тут починають вилітати edge-cases. 2. Інша інфраструктура: Кеш, CDN, балансувальники, черги, rate limits — у production часто більше сервісів і навантаження. Через це баги можуть зʼявлятись лише після релізу. 3. Feature flags і конфіги: Часто на staging увімкнені не всі фічі або інші налаштування API. QA перевірив один сценарій, а користувачі отримали зовсім інший. 4. Навантаження користувачів: На staging одночасно працює 5–10 людей. На production — тисячі. Через це зʼявляються race conditions, проблеми з кешем, дублікати запитів і падіння API. 5. Зовнішні інтеграції: Платежі, email-сервіси, push-notifications, OAuth — staging часто використовує sandbox-версії, які поводяться стабільніше за реальні сервіси. 6. Людський фактор: Реальні користувачі роблять речі, які команда навіть не уявляла: закривають вкладку під час оплати, натискають кнопку 10 разів, працюють із 5 пристроїв одночасно. Висновок: QA має памʼятати: staging — це лише модель production, а не його копія. Хороше тестування — це не тільки перевірка фічі, а й розуміння, як вона поводитиметься у реальному середовищі з реальними користувачами. Комора тестувальника

🤔 Що робити, якщо не відомі потрібні платформи, але потрібна максимальна підтримка? - Орієнтуватися на статистику ринку (наприклад, Android 10+, iOS 14+). - Перевірити аналітику поточних користувачів, якщо є доступ. - Використовувати емулятори та хмарні платформи (BrowserStack, Sauce Labs) для охоплення великої кількості пристроїв. - Забезпечити підтримку основних браузерів і роздільних здатностей. Комора тестувальника

🤔 Де взяти тестове середовище? Тестове середовище надається інженерами DevOps, розробниками, адміністраторами або створюється автоматично за допомогою процесів CI/CD. Комора тестувальника

⚡️ Через 2–3 роки вміння працювати з AI стане таким же базовим, як сьогодні Excel або Google Docs. AI уже використовують маркетологи, менеджери, підприємці, копірайтери, дизайнери, аналітики та розробники. Ті, хто вміє правильно працювати з AI, виконують завдання швидше, заробляють більше та мають перевагу на ринку праці. Але AI — це вже не одна професія. Сьогодні активно розвиваються напрямки:

🟢 AI Automator 🟢 Prompt Engineer 🟢 AI Content Maker 🟢 No-Code + AI Specialist

Кожен із них вирішує різні задачі та потребує різних навичок. Як зрозуміти, який напрям підійде саме вам? Пройдіть короткий AI-тест від GoIT та дізнайтесь, де ваш потенціал може розкритися найкраще. https://telegram.me/ai_career_quiz_bot

JWT, або JSON Web Token JWT — це відкритий стандарт RFC 7519, який визначає компактний і автономний спосіб безпечного передавання інформації між сторонами у вигляді JSON-об'єкту. Ця інформація може бути перевірена і заслуговує довіри, оскільки підписана цифровим підписом. JWT може використовувати або загальний секрет (через алгоритм HMAC), або пару відкритого та закритого ключів з використанням RSA або ECDSA. Авторизація — найпоширеніший сценарій використання JWT. Після аутентифікації користувача JWT дозволяє йому отримувати доступ до певних ресурсів або сервісів, реалізуючи таким чином механізм авторизації. Тобто JWT передає серверу інформацію про користувача та його роль/права доступу. Структура JWT JWT складається з трьох частин: Header, Payload та Signature. 1. Header (Заголовок) Зазвичай містить тип токена (JWT) та алгоритм підпису (наприклад, RSA, HMAC). json { "alg": "RS384", "typ": "JWT" }``` 2. Payload (Полезний вантаж) Основна частина, що містить інформацію про користувача та додаткові параметри, наприклад: 🔹sub — ідентифікатор користувача 🔹iat — час видачі токена 🔹exp — час закінчення терміну дії токена 🔹role — роль користувача (наприклад, "admin")

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
>

3. Signature Для створення підпису використовується комбінація алгоритму хешування та секретного ключа або пари відкритого/закритого ключів:

signature = hashing_algorithm(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

Формат JWT

<base64Url(header)>.<base64Url(payload)>.<base64Url(signature)>

— Як працює JWT 1. Авторизація: Після входу користувача в систему (наприклад, за допомогою логіна та пароля) сервер генерує JWT, що містить інформацію про користувача (ім'я, роль, права доступу) та інші важливі параметри. 2. Зберігання токена: Клієнт отримує токен і зберігає його (зазвичай у localStorage або у cookies). 3. Використання токена: Кожен наступний запит до сервера включає токен у заголовку Authorization. Сервер перевіряє його підпис і термін дії (по iat/exp), поки токен діє. — Як відбувається перевірка токена 1. Сервер отримує JWT. 2. Декодує частини header і payload. 3. Перевірка підпису: за допомогою секретного ключа або відкритого ключа сервер перераховує підпис токена і порівнює його з отриманим. 4. Перевірка терміну дії токена: по параметру exp. Якщо токен закінчився, користувач може отримати новий токен за допомогою refresh-токена (зазвичай це відбувається автоматично). Single Sign-On (SSO) на базі JWT JWT можна використовувати для реалізації Single Sign-On (SSO) — входу в систему один раз з можливістю подальшого доступу до декількох незалежних додатків без повторної аутентифікації. JWT в цьому випадку служить маркером доступу, що зберігається після першої аутентифікації і використовується для авторизації в інших сервісах. Наприклад, після входу на корпоративну платформу користувач може використовувати один і той же JWT для доступу до електронної пошти, файлів або чатів. Корисні ресурси: 🔹 JWT playground 🔹 Відео з поясненням Комора тестувальника

🤔 Що означає використання одного і того ж пестициду в QA? Це натяк на парадокс пестициду: якщо одні й ті самі тестові випадки використовуються знову і знову, вони з часом втрачають ефективність, оскільки перестають виявляти нові дефекти. Тести потрібно оновлювати та доповнювати. Комора тестувальника

📊 Data Analytics — одна з тих сфер, де попит на спеціалістів зростає швидше, ніж ринок встигає їх готувати. Причина проста. Компанії вже давно навчилися збирати дані. Тепер їм потрібні люди, які можуть ці дані зрозуміти та перетворити на конкретні рішення для бізнесу. Саме тому аналітиків шукають у:

▪️ IT ▪️ e-commerce ▪️ маркетингу ▪️ фінансах ▪️ логістиці ▪️ продуктових компаніях

На безкоштовному марафоні від GoIT покажемо, як виглядає професія зсередини та які навички потрібні для розвитку в цьому напрямі. Ви дізнаєтесь: 🔖 як працюють аналітики даних 🔖 де використовується SQL та BI-системи 🔖 які кар'єрні можливості відкриває Data Analytics 🕓 Онлайн | Безкоштовно 👉 Реєстрація: https://i.goit.global/jaEMY

Порада по Chrome Dev Tools Чи знаєте ви, що можна швидко змінити колірну схему прямо в Chrome Dev Tools, щоб протестувати сайт в темному/світлому режимі? Ми можемо швидко перемикати налаштування color-scheme прямо з Chrome Dev Tools. Для цього немає необхідності змінювати системні налаштування Комора тестувальника

Допоможіть своїм агентам ШІ дійсно "бачити" сайт, який ви тестуєте. Якщо ви використовували Playwright MCP не тільки для демо-логінів з YouTube, то, швидше за все, стикалися з проблемою: агент не бачить частину елементів на сторінці, плутається або взагалі втрачає контекст. Причина проста — Playwright MCP передає в LLM ARIA-снимок, а не повний список інтерактивних елементів з DOM. Хлопці зробили апгрейд для MCP, який: • серіалізує повне дерево DOM • повертає всі інтерактивні елементи • передає повний контекст сторінки В результаті агент отримує повну картину сторінки, розуміє, як працювати з елементами, і може генерувати значно більш якісні та широкі тестові сценарії з першої спроби. Посилання на рішення: https://www.treegress.com/treegress-mcp-browser Комора тестувальника