“Які дії мені дозволено робити з цим ресурсом?”

Якщо фронтенд працює з API на іншому домені — браузер перед POST, PUT або нестандартним GET надсилає OPTIONS, щоб перевірити, чи можна взагалі робити такий запит.

Ти можеш вручну зробити OPTIONS-запит до будь-якого API endpoint і подивитися, чи підтримує він DELETE, PATCH, HEAD тощо.

Це буває корисно:
*️⃣коли немає документації;
*️⃣щоб протестувати налаштування сервера;
*️⃣або щоб знайти помилки конфігурації (наприклад, метод заборонено, хоча має бути доступним).

Якщо ти не хочеш змінювати дані на сервері (як це було б із POST чи PUT), але хочеш переконатися, що ресурс існує і працює — OPTIONS ідеальний варіант. Він не створює і не змінює нічого.

Сервер не відповідає на OPTIONS (хоча повинен).
Немає або неправильні заголовки Access-Control-Allow-*.
Неправильно вказані дозволені методи.

Тому варто перевіряти OPTIONS не лише з функціонального, а й з безпекового боку.

Щоб працювати з різними середовищами (dev/stage/prod), варто використовувати власні базові URL, токени, параметри у вигляді змінних.

Postman підтримує JavaScript для автоматизації: можна обчислити токен, згенерувати дату, виконати перевірку.

pm.test("Status code is 200", function () {

Запити можна об’єднувати у колекції — за функціональністю або мікросервісом.

Допомагає запускати всі запити з колекції по черзі, з різними наборами даних (CSV/JSON).

Забезпечують запуск запитів за розкладом — щогодини, щодня. Дають змогу виявити збої API після релізу.

Дозволяють симулювати відповіді API, навіть якщо бекенд ще не реалізований.

Відповіді можуть відображатися у вигляді таблиць, графіків — за допомогою шаблонів (HTML + Handlebars).

Інтеграція з CI/CD: запуск тестів через Newman у пайплайнах.

Перевірки статус-кодів, значень у полях, структури JSON тощо.

😑 Як працюють типи авторизації (Bearer, Basic Auth, API Key)
😑 Як писати умовні конструкції у тестах (if-else на різні відповіді)
😑 Як використовувати глобальні, локальні та середовищні змінні
😑 Як зберігати динамічні значення між запитами (pm.environment.set)
😑 Як організовувати колекції для зручного користування і командної роботи

*️⃣Якщо змінити колір кнопки «Купити», CTR зросте.
*️⃣Якщо додати індикатор прогресу в анкеті, більше користувачів її завершать.
*️⃣Якщо замінити модальне вікно на інлайн-повідомлення, конверсія не впаде.

😑Чи коректно працюють варіанти А і B?
😑Чи зібрані події для аналітики?
😑Чи все видно в DevTools / Network / аналітичних подіях?

*️⃣Кнопка «Підтвердити» виглядає неактивною → користувачі не тиснуть.
*️⃣ Після натискання немає анімації → здається, що нічого не відбулось.
*️⃣ Форма надто довга → додати індикатор прогресу.

*️⃣ Фільтр вантажиться занадто повільно → винести частину логіки на клієнт.
*️⃣ Стартова сторінка важка → lazy-loading зображень покращить перформанс.

*️⃣ Якщо запит надсилається ще до підтвердження → користувач може випадково втратити дані.

😮‍💨 Баг: явно неправильна поведінка (UI ламається, дані не зберігаються, сторінка не відкривається).

😮‍💨 Гіпотеза: все працює, але можна зробити краще. UX — не помилка, а шанс на покращення.

*️⃣Кнопка на сайті помітна, клікабельна. Але: CTR низький. Користувачі її пропускають

*️⃣Тут немає бага. Але гіпотеза:
«Якщо змінити розмір і додати анімацію — більше людей натисне».

🔸 Google Analytics / Mixpanel / PostHog – поведінка користувачів
🔸 Chrome DevTools – перевірка логіки на фронті
🔸 Charles / Proxyman – відстеження запитів
🔸 SQL / BigQuery – аналітика поведінки
🔸 A/B-тест платформи – Optimizely, LaunchDarkly, Firebase Remote Config

✅ покращити UX
✅ виявити слабкі місця
✅ впливати на метрики
✅ зробити продукт зручнішим для людей

👁‍🗨 Нативні додатки – найшвидші, але дорогі у розробці.
👁‍🗨 Кросплатформні рішення економлять час, але мають компроміси.
👁‍🗨 Гібридні застосунки та PWA – це баланс між зручністю та обмеженнями.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0Iiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNjkxMDE0NDAwfQ.V4yMjDkJwBQzjZm30sMSq2qQ2_8xX1E0Xv6PqQ5_UXU

{

{

Bearer означає, що будь-яка особа або система, яка має токен, може його використовувати для доступу до ресурсу.

POST /login

{

GET /profile

{

Set-Cookie: sessionId=abc123; Path=/; HttpOnly

Access-Control-Allow-Origin: https://frontend.example.com

⭕️Історія: Потрібен був точніший механізм кешування змінених ресурсів.

⭕️ Проблема: Часові мітки були занадто грубими для визначення змін.

✔️Рішення: Заголовок ETag присвоює унікальний ідентифікатор версії ресурсу.

ETag: "abc123xyz"

If-None-Match: "abc123xyz"

⭕️Історія: Атаки типу clickjacking використовували приховані фрейми.

⭕️ Проблема: Зловмисники могли вбудовувати ваш сайт у свої сторінки та вводити користувачів в оману.

✔️Рішення: Заголовок X-Frame-Options забороняє або обмежує вбудовування сайту у iframe.

X-Frame-Options: DENY

X-Frame-Options: SAMEORIGIN

*️⃣Використовуйте Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options.
*️⃣Завжди налаштовуйте Content-Security-Policy для захисту від XSS.
*️⃣Уникайте витоку зайвої інформації через заголовки на кшталт X-Powered-By, Server.

💖Завжди перевіряйте Origin проти білого списку.
💖Не використовуйте * у Access-Control-Allow-Origin, якщо встановлено Access-Control-Allow-Credentials: true.
💖Правильно обробляйте preflight-запити (OPTIONS) і відповідайте відповідними CORS-заголовками.

💖Поєднуйте Cache-Control, ETag, Expires для ефективного кешування.
💖Використовуйте заголовок Vary, щоб керувати варіаціями кешу (наприклад, за мовою або кодуванням).
💖Стискайте відповіді за допомогою Content-Encoding: gzip.

✔️Використовуйте User-Agent, Referer, власні заголовки типу X-Request-ID для трасування запитів.
✔️Додавайте Date, Server-Timing для збору аналітики та вимірювання продуктивності.

Якщо CORS налаштовано неправильно, frontend не отримає відповідь навіть при правильному запиті.

😑 Надішли більше запитів, ніж дозволено (наприклад, 11 при ліміті 10/хв)
😑 Перевір 429 статус та повідомлення
😑 Зачекай хвилину — чи обнуляється ліміт?
😑 Різні ролі — різні обмеження?

😑 Без токена, з битим або простроченим токеном
😑 401 чи 403 — чи відповідає статус очікуванню?
😑 Перевір дозволи для кожної ролі

😑 Валідні та невалідні URl
😑 Заборонені шляхи для звичайного користувача

😑 Чи зберігається Authorization при редиректах
😑 Чи правильні CORS-заголовки для фронтенду

😑 Великі тіла запитів
😑 Довгі URI
😑 Повторний запит з тим самим токеном

☑️ Чи справді був запит і яка була відповідь?
☑️ Чи є error/exception у логах?
☑️ Чи повторюється проблема на іншому пристрої або обліковці?
☑️ Чи є залежність від дій користувача?
☑️ Чи є stacktrace, який допоможе розробнику?

Тестувальник, який вміє читати логи, завжди буде на крок попереду.

Це допомагає точніше описати баг, зрозуміти, на якому рівні виникла проблема, і навіть… зекономити час усій команді.

✔️ Високу продуктивність – напряму використовує процесор і графіку пристрою.
✔️ Доступ до всіх системних можливостей (Bluetooth, камери, датчиків, push-сповіщень тощо).
✔️ Найкращий UX, бо елементи інтерфейсу відповідають стандартам платформи.

📌 iOS – Swift, Objective-C
📌 Android – Kotlin, Java

✔️ Як працює управління пам’яттю (наприклад, iOS може "вбивати" застосунок у фоновому режимі).
✔️ Як реагують push-сповіщення у різних станах застосунку.
✔️ Чи є специфічні особливості ОС (наприклад, різні дозволи в Android 13+).

😑 React Native – написаний на JavaScript, використовує Bridge для спілкування з нативними модулями.
😑 Flutter – використовує мову Dart і має власний графічний рушій для відображення UI.

🫠 React Native викликає нативні API через JS Bridge, що трохи уповільнює виконання.
🚀 Flutter рендерить UI власними засобами, тому працює швидше, але займає більше місця.

☑️ Перевірка продуктивності (анімації можуть лагати через міст React Native).
☑️ UI може виглядати інакше на різних платформах (особливо у Flutter).
☑️ Перевіряти інтеграцію з нативними модулями (камера, геолокація, push).

✔️Веб-контент рендериться всередині WebView.
✔️ Можливий доступ до нативних функцій через плагіни (камера, push, GPS).
✔️ Виглядає як мобільний застосунок, але працює як веб-сторінка.

☑️ Чи правильно працює WebView на різних версіях ОС.
☑️ Чи працюють нативні плагіни (GPS, push, файловий доступ).
☑️ Продуктивність і швидкість завантаження (можливі затримки при переходах між екранами).
☑️ Відмінності в UI/UX між платформами.

✔️ Не потребує встановлення, відкривається в браузері.
✔️ Підтримує push-сповіщення, офлайн-режим (через Service Workers).
✔️ Але має обмежений доступ до системних ресурсів (немає Bluetooth, обмеження на GPS).

☑️ Чи коректно працює кешування офлайн.
☑️ Як реагує застосунок на втрату мережі.
☑️ Чи є відмінності у роботі на iOS та Android (наприклад, Safari має жорсткіші обмеження).

✅ Скрін резолюшен – роздільна здатність екрана, тобто скільки пікселів розміщується на дисплеї.
✅ Розмір екрана – фізична діагональ дисплея у дюймах.
✅ Щільність пікселів (DPI/PPI) – скільки точок припадає на один дюйм екрана.

Це параметр, що визначає, скільки пікселів вміщується у ширину та висоту дисплея, наприклад, 1080×1920 px.

👍Чим більше пікселів, тим чіткіше зображення, але це також впливає на продуктивність пристрою.

❗️UI-елементи можуть виглядати по-різному на пристроях із різною кількістю пікселів.
❗️Деякі елементи можуть зміщуватися, накладатися або обрізатися.
❗️Висока роздільна здатність потребує більше ресурсів, що може впливати на швидкість роботи додатка.

Це довжина діагоналі екрана в дюймах, наприклад, 6.1” для iPhone 14.

↔️Впливає на комфортність роботи з додатком.
↔️Визначає розмір та розташування елементів UI.
↔️Менші екрани можуть вимагати іншого підходу до розміщення контенту.

Щільність пікселів визначає, наскільки дрібними або великими виглядають елементи на дисплеї. Вимірюється у DPI (dots per inch) або PPI (pixels per inch).

⬆️Чим вищий показник, тим чіткіший текст і графіка.

⭕️UI-елементи можуть виглядати по-різному на екранах з різною щільністю.
⭕️Низька щільність може робити текст розмитим, а висока – занадто дрібним.
⭕️На пристроях з високою щільністю пікселів потрібно тестувати іконки та зображення у відповідних розмірах.

Використовуй онлайн-інструменти, наприклад, dpi.lv або calculatorsoup.com, щоб розрахувати DPI на основі розміру екрана та його роздільності.

👁Android Studio показує щільність для різних емуляторів.

🔹 UI може виглядати інакше на різних екранах.
🔹 Кнопки та текст можуть виявитися надто маленькими або великими.
🔹 Графіка може бути розмитою на дисплеях з високою щільністю.

Cache-Control: no-cache, max-age=3600

Це зберігання копій відповідей (у браузері або проміжних серверах), щоб зменшити навантаження на сервер і пришвидшити доступ. Кешування контролюється через Cache-Control, ETag, Expires.

❓ Як реалізувати єдину точку входу?
❓ Як захистити внутрішню архітектуру?
❓ Як керувати доступом, логуванням і навантаженням?

🎥 Маршрутизація — розподіл запитів на відповідні сервіси
🎥 Аутентифікація та авторизація — перевірка токенів і прав
🎥 Rate limiting — захист від DDoS і перевищення лімітів
🎥 Кешування — зменшення навантаження на бекенд
🎥 Трансформація даних — зміна формату запитів/відповідей
🎥 Логування і моніторинг — фіксація всієї активності

😑 Один запит на api.mysite.com може всередині бути розподілений між /auth, /products, /orders
😑 Gateway обмежує зовнішні інтеграції лише дозволеними методами
😑 Уся автентифікація зосереджена в одному місці
😑 Внутрішні сервіси ізольовані від зовнішнього світу

💖 Kong — open-source з розвинутим ком’юніті
💖 NGINX — легкий, швидкий, зручний для кастомізації
💖 Amazon API Gateway — хмарне рішення для AWS
💖 Spring Cloud Gateway / Zuul — частина екосистеми Java

😑 Gateway може змінювати поведінку API — це слід враховувати під час тестування
😑 Статуси 403, 429, 502 — часто приходять не від самого API, а від gateway
😑 Rate limiting варто перевіряти з кількома запитами поспіль
😑 Приклад edge-case: зламаний токен, перевищення розміру запиту, повторне надсилання
😑 У проєктах, де авторизація “на gateway”, логіка токенів і ролей тестується саме тут

💢 Одна точка відмови — якщо gateway падає, недоступні всі сервіси.
💢 Помилки в налаштуваннях — можуть заблокувати легальні запити або відкрити доступ тим, кому не слід.
💢 Мішень для атак — gateway першим приймає запити ззовні, тому часто стає ціллю.
💢 Вразливість через застаріле ПЗ — без оновлень можуть з’явитися діри в безпеці.
💢 Відсутність резерву — без запасного плану збій gateway = збій системи.

Наприклад, заводи Toyota використовували RCA у рамках Lean Manufacturing та Total Quality Management (TQM).

🔹 5 Whys – запитуємо “чому?” 5 разів поспіль

🔹 Fishbone Diagram – візуально розкладаємо фактори за категоріями

🔹 Pareto Analysis (80/20) – виявляємо топ-причини, що викликають більшість помилок

        Падіння додатку
               ⬇️
    --------------------------
    |        |       |       |    
    Код    Процес  Інфра   Вимоги  
    ⬇️     ⬇️      ⬇️      ⬇️
- пропущена перевірка null  
- немає рев’ю-коду  
- CI/CD дав збій  
- нечітко описана UX-логіка  

✔️Причина — неперевірене null-значення у відповіді від API. Тест-кейси цього не врахували.

☑️ Рішення:
– Додати null-check
– Розширити тестування
– Додати рев’ю перед релізами

1. Чому? — API повертає помилку
2. Чому? — не враховані спецсимволи
3. Чому? — не було валідації
4. Чому? — QA не залучили до написання вимог
5. Чому? — процес вимог не включає тестувальників

✅ Запобігання повторним дефектам
✅ Оптимізація процесів (виявляються слабкі місця)
✅ Зниження витрат (менше часу на фікси у проді)
✅ Покращення документації, вимог, тест-кейсів
✅ Загальне зростання якості продукту

✔️ SQL – запити до баз даних, перевірка бекенду.
✔️ API – Postman, REST, GraphQL, тестування інтеграцій.
✔️ Git – робота з кодом і тестовими скриптами.
✔️ CI/CD – Jenkins, GitHub Actions для автоматизації тестування у пайплайнах.
✔️ Мови програмування – Python, JavaScript або Java (особливо для автоматизаторів).

🔹 Основи тестування програмного забезпечення від Logos IT Academy
🔹 Курс "Основи аналітики даних" на Prometheus
🔹 Безоплатні курси тестувальника від AVADA MEDIA

💰QA Engineer з нуля до роботи в IT від Mate Academy
💰 Онлайн-курси тестувальника (QA) від SkillUp
💰 Курси тестувальників онлайн від GoIT Global

✔️ Вести тестову документацію – тест-кейси, баг-репорти, чеклісти.
✔️ Піднімати питання ризиків – які проблеми можуть виникнути після релізу?
✔️ Автоматизувати рутину – якщо перевіряєш одне й те саме вручну, оптимізувати процес.
✔️ Пропонувати покращення – наприклад, запровадити тестування API, якщо його ще немає.

*️⃣Читати книги: "Lessons Learned in Software Testing", "Agile Testing".
*️⃣ Проходити курси: Udemy, Coursera, Test Automation University.
*️⃣ Відвідувати конференції: TestCon, QA Fest, SeleniumConf.
*️⃣ Спілкуватися в QA-спільнотах та Telegram-каналах: QA_Prostir 😉

✅️Онлайн-магазин або портал з великою аудиторією
✅️API, яке викликають інші системи
✅️Мобільний або PWA додаток з інтерактивним бекендом
✅️Великий обсяг даних (CRM, аналітика)
✅️Рекламні кампанії чи розпродажі

✔️Має GUI і CLI
✔️Працює з HTTP, WebSocket, FTP, БД, SOAP
✔️Підходить для навантажувального тестування в UI або автоматично

✅️Threads: 100
✅️Ramp-Up: 60
✅️Loop Count: 10
✅️HTTP Request: GET /api/data
✅️Constant Timer: 100 мс
✅️Assertion: Response code = 200

✅️Start: 50 Threads
✅️Add: 50 кожні 30 сек
✅️Досягти: 1000 Threads
✅️Спостерігайте: Error %, тривалість відповіді, CPU, RAM

✅️Thread Group 1: 100 Threads, Ramp-Up: 60
✅️Thread Group 2: 1000 Threads, Ramp-Up: 5, Start Delay: 120 сек

✅️Threads: 100
✅️Ramp-Up: 60
✅️Loop: Forever
✅️Scheduler: ON → Duration: 28800 сек (8 годин)

✅️Той самий сценарій з Threads: 100, 200, 400
✅️Loop Count: 10

✅️Threads: 10
✅️Ramp-Up: 10
✅️Loop Count: 100
✅️Sampler: JDBC Request або HTTP POST до API
✅️Якщо API — надсилаємо великі payload'и
✅️Якщо БД — запити типу SELECT * FROM orders WHERE date BETWEEN ...
✅️CSV Data Set Config: файл з параметрами для підстановки (напр. айдішники, дати)
✅️Assertion: перевіряємо, що відповідь не порожня / статус = 200

😑 Виявити нестійкість у коді
😑 Перевірити обробку помилок (error handling)
😑 Запобігти крашам і втраті даних
😑 Підвищити довіру до продукту: баги часто ховаються саме в edge-case’ах

🔸 Ввести в поле “Телефон” — текст: abcdef
🔸 Вставити у форму emoji або спецсимволи
🔸 Натиснути “Зберегти”, не заповнивши обов’язкові поля
🔸 Ввести занадто довгий текст (500+ символів у полі “Ім’я”)

🔸 Відправити запит без токена авторизації
🔸 Передати userId: null або email: "123"
🔸 Викликати PUT замість POST

🔸 Вимкнути інтернет і натиснути “Оновити”
🔸 Повернути екран під час завантаження
🔸 Кілька разів швидко натиснути на кнопку
🔸 Надати доступ до камери, а потім заборонити

✔️ Подумати: що піде не так?
✔️ Визначити точку входу (UI/API/дія користувача)
✔️ Ввести дані або умову, яка порушує норму
✔️ Передбачити очікувану негативну реакцію
✔️ Перевірити, чи не зламалась система

🔹 Повідомлення про помилки мають бути чіткі й зрозумілі
🔹 Логувати результати — негативне тестування допомагає писати хороші тест-кейси
🔹 Враховувати edge-case’и: null, пусті поля, нестандартні мови, неочікувані типи даних
🔹 Не обмежуватись UI — тестувати також API, базу, мережу

✔️ Pull-to-refresh – оновлення списків свайпом вниз.
✔️ Жести свайпу – видалення, навігація, відкриття меню.
✔️ Довге натискання – виклик контекстного меню, drag-and-drop.
✔️ Нативні перемикачі, чекбокси – елементи, що відповідають платформі.
✔️ Тактильний відгук (Haptic feedback) – вібрації та системні ефекти.
✔️ Нативні анімації та переходи – плавні та оптимізовані для ОС.

❌ Платформозалежні жести – iOS: свайп від краю для навігації, Android: кнопка «Назад».
❌ Системні дії – наприклад, iOS не дозволяє змінювати жести управління (Control Center).

❌ UI-компоненти можуть виглядати менш нативно – наприклад, прокрутка в React Native може бути менш плавною.
❌ Деякі платформозалежні функції вимагають нативних модулів – складні жести, специфічні віджети.

✔️ Базові UI-взаємодії – натискання, кнопки, прокрутка.
✔️ Довге натискання – але часто викликає дії браузера.
✔️ Деякі жести свайпу – якщо реалізовані через JavaScript.

❌ Немає справжнього pull-to-refresh – контрольований браузером.
❌ Обмежені свайпи – навігація назад/вперед контролюється браузером.

🔹 Pull-to-refresh варто тестувати тільки в нативних і кросплатформних додатках, а не в PWA.
🔹 Свайпи можуть працювати нестабільно у гібридних та веб-застосунках.
🔹 Довге натискання в PWA може викликати системні меню браузера.
🔹 Haptic feedback доступний тільки в нативних та кросплатформних застосунках.
🔹 Перемикачі, date pickers та інші UI-компоненти відрізняються залежно від типу застосунка.

❌Повідомлення не приходять вчасно.
❌ Вони можуть дублюватися.
❌ Або зникати без сліду.

✔️ Чи приходить пуш після тригерної дії? (наприклад, нове повідомлення або зміна статусу замовлення)
✔️ Чи відображається пуш на заблокованому екрані, у статус-барі та в центрі повідомлень?
✔️ Чи з’являється пуш, коли застосунок відкритий, у фоні чи закритий?
✔️ Чи працює пуш після перезавантаження пристрою?

☑️ Текст, іконки, зображення – чи все відображається правильно?
☑️ Чи немає обрізаних символів? (Особливо на iOS, де є жорсткі ліміти)
☑️ Локалізація – пуш має бути на правильній мові, залежно від налаштувань пристрою.

✔️ Чи відкривається потрібний екран застосунку після натискання?
✔️ Чи працюють "Swipe to dismiss" і кнопки дій? (Наприклад, "Відповісти", "Переглянути")
✔️ Що буде, якщо натиснути пуш кілька разів? (Відкриється один екран чи створиться купа дублів?)

☑️ Що буде, якщо інтернет зник під час надсилання пуша? Чи прийде він пізніше?
☑️ Чи працюють пуші в режимі енергозбереження або low-power mode?
☑️ Чи не надходить забагато пушів одночасно? (Щоб не спричинити блокування зі сторони Android/iOS)

✔️ Чи групуються пуші в стек, якщо їх багато? (Наприклад, повідомлення у месенджері)
✔️ Чи кожен пуш відображається окремо, займаючи весь екран? (Деякі пуші, наприклад, на iOS можуть показувати великі банери)
✔️ Чи є логіка оновлення повідомлення замість створення нового? (Наприклад, "Очікуйте кур’єра через 10 хвилин" → "Кур’єр уже на місці")
✔️ Що буде, якщо видалити один пуш зі стека? Чи зникнуть всі, чи лише конкретний?

☑️ Що буде, якщо користувач заборонив пуші? Чи працює fallback (email або інші сповіщення)?
☑️ Чи є правильний запит на дозвіл (особливо на iOS, де не можна спамити запитами)?
☑️ Як працюють пуші на різних версіях Android та iOS?

Важливо протестувати всі сценарії: доставку, контент, взаємодію користувача, вплив на батарею та permission’и.

Особливо це критично для застосунків, де пуші безпосередньо впливають на користувацький досвід – банки, e-commerce, соцмережі.