HTTP статус-коди — не тільки 200 і 404

Зберігаю сюди, бо іноді під час тестів зависаю на питанні: “А цей код — ок чи баг?”. Буває, API вертає 204, або 301, або 403 — і треба швидко зрозуміти, чому так і що це означає.

Ось стисло, але по суті:

⸻

✅ 2xx — Все ок
• 200 OK — стандартна відповідь, усе добре.
• 201 Created — щось створено (типу юзер або новий пост).
• 204 No Content — запит оброблено, але тіла відповіді нема (наприклад, після DELETE).

⸻

➡️ 3xx — Редіректи
• 301 Moved Permanently — ресурс переїхав назавжди.
• 302 Found — тимчасовий редірект (але браузери поводяться по-своєму).
• 304 Not Modified — кеш не оновлюй, бери старе.

⸻

⛔ 4xx — Клієнт помилився
• 400 Bad Request — десь ти напартачив у запиті.
• 401 Unauthorized — авторизуйся, брате.
• 403 Forbidden — навіть з токеном доступу не буде.
• 404 Not Found — немає такого шляху.
• 409 Conflict — конфлікт, наприклад, вже існує такий юзер.

⸻

☠️ 5xx — Проблема на стороні сервера
• 500 Internal Server Error — щось впало.
• 502 Bad Gateway — погана відповідь від іншого сервера.
• 503 Service Unavailable — сервіс недоступний (зазвичай, тимчасово).

⸻

Чому це важливо для QA?
Бо ми не просто клікаємо і дивимось на UI — ми маємо розуміти, що відбувається всередині. Коли щось не так, ці коди можуть одразу дати відповідь: проблема на боці клієнта чи сервера, це баг чи очікувана поведінка.

GET vs POST та вся HTTP-банда

Зберігаю сюди ще одну базову, але суперважливу штуку — HTTP-методи.
Ти їх точно бачив: GET, POST, PUT, DELETE — але якщо чітко не уявляєш, хто за що відповідає, можеш зробити неправильний запит або не там шукати баг.

⸻

GET — “Просто покажи мені”
• Отримати дані з сервера.
• Безпечний: не змінює дані.
• Часто використовують для фільтрації, пагінації, перегляду.
• Приклад: GET /users?page=2

⸻

POST — “Ось нові дані, збережи їх”
• Створення нового ресурсу.
• Дані йдуть у тілі запиту.
• Приклад: POST /users з тілом { "name": "Ihor" }

⸻

PUT — “Онови повністю”
• Заміна існуючого ресурсу.
• Повна передача нових даних.
• Приклад: PUT /users/42 з тілом { "name": "Ivan" }

⸻

PATCH — “Онови частково”
• Часткове оновлення.
• Не треба передавати всі поля, тільки ті, що змінюються.
• Приклад: PATCH /users/42 з тілом { "name": "Taras" }

⸻

DELETE — “Видали це нафіг”
• Видалення ресурсу.
• Приклад: DELETE /users/42

⸻

Але важливий нюанс:
У багатьох реальних проєктах навіть оновлення (update) і видалення (delete) роблять через POST!
Чому? Бо так простіше з безпекою, проксі, CORS або через обмеження деяких клієнтів.
Тобто ти можеш зустріти таке:
• POST /user/delete/42
• POST /user/update з тілом { "id": 42, "name": "New name" }

Це нормально, просто треба знати, що API може поводитись не завжди строго по REST-доктрині.

⸻

Чому це важливо для QA?
Бо ти маєш знати, які методи реально використовуються в продукті, який тестуєш. Іноді API-документація — одне, а те, що летить у логах — зовсім інше.

Продовжимо пост вище:
CORS: Не така проста штука, як здається — точно стикались з цією проблемою?

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

Так от, CORS — це механізм безпеки, який інколи може зіпсувати життя, навіть якщо ти все робиш правильно. І зараз хочу поділитись, як я сам колись заплутався в цьому, а потім зрозумів, як все працює. І тепер я точно знаю, коли сервер не повертає правильні заголовки, нічого не вийде.

Що таке CORS?

CORS — це контроль доступу між різними доменами, який блокує доступ до ресурсів, якщо вони знаходяться на іншому сервері. Якщо ти з фронтенду на frontend.com хочеш звернутися до API на api.com, то браузер може заблокувати цей запит, якщо сервер не вказав, що дозволяє доступ. Це така собі захисна стіна.

Як це працює на практиці?

Спочатку браузер відправляє preflight-запит (OPTIONS), щоб перевірити, чи можна зробити запит.

Якщо сервер відповідає, що можна — тоді браузер робить основний запит, наприклад, POST.

Якщо сервер не налаштований, запит просто не проходить.

Що має бути на сервері, щоб це працювало?

Access-Control-Allow-Origin — дозволяє доступ з певного домену.

Access-Control-Allow-Methods — перелік методів, які можна використовувати (GET, POST і т.д.).

Access-Control-Allow-Headers — які заголовки можна передавати.

Access-Control-Allow-Credentials — для cookies і токенів.

Навіщо це знати?

Коли ти працюєш з API або тестуєш його, і бачиш помилку, типу:


No 'Access-Control-Allow-Origin' header is present on the requested resource.
Це не означає, що щось не так з твоїм кодом чи запитом. Це означає, що сервер просто не дозволяє доступ з твоєї сторони. Пам'ятай, що інколи навіть якщо ти зробиш усе правильно з клієнтської сторони, потрібно переконатись, що сервер правильно налаштований для підтримки CORS.

Моя порада: якщо це твоя перша проблема з CORS, не панікуй. Я сам колись витратив години на пошук ідеальної відповіді, поки не зрозумів, як це працює насправді. Якщо ти натрапив на таку проблему в проекті — поділись, може, я допоможу з розв’язанням!

Ловітььььь реальний кейс згадав

Тестую я собі фічу. Все красиво. Натискаю кнопку — нічого не відбувається. Думаю: ну не може бути, ж я тільки що оновив сторінку. Перевіряю в DevTools — запит відправився. Відповідь є. Але UI — мертвий.

Вмикаю логіку Шерлока Холмса:
• Кеш? Ні, чистив.
• Backend? Та ні, відповідає.
• Фронт? Оооооооо… ага, ось ця кнопка не в ту сторону дивиться.

Пишу деву:
— “Чувак, у вас на кнопці onClick не вішається. Там div замість button.”
Відповідає:
— “Та я вчора після шостої пушнув. Ти ще той коміт взяв? Бо я вже після нього все пофіксив, але на гілку не запушив.”

Та шо ти кажеш…

⸻

Мораль:
QA має не тільки тести писати, а ще й телепатію прокачувати. Бо як інакше дізнатись, що дев “пофіксив локально, але забув залити”?

Якщо ти теж колись тестував повітря, бо код ще не долетів — ти не один. Ми всі так живем.

🐣 Після свят — назад у бій!

Після трьох днів паски, шинки і «ще одну каву — і засяду» повертаємось у робочий ритм 😅

Якщо вкладка з Jira відкривається з острахом, а руки самі тягнуться до “npm start”, знай — ти не один такий.

Починаємо тиждень з малого — подивитися, що там впало в логах, і згадати, що ми взагалі робимо в цьому проекті 👀

Цікаву штуку згадав

Коли бек мовчить, а баг не репродюситься — запускай Wireshark!

Було діло: перевіряю фічу, запит має летіти на сервер, а у відповідь — тиша. Таймаут, ніяких помилок, ні в консолі, ні в логах. І знаєш що? Вся команда така: «У нас все працює 😅»

І тут вмикається QA-режим "не вірю нікому, перевіряю все".

🔧 Запускаю Wireshark, починаю слухати трафік:

Бачу, що мій запит навіть не доходить до сервера.

Навіть TCP-з’єднання не встановлюється (немає SYN-ACK).

А значить — мене банять ще до аплікації.

💡 Виявилось, що моя IP-геолокація була не додана в allowlist на фаєрволі. Тобто сервер просто не приймав з’єднання з мого регіону — і тишком мовчав про це.

Висновок для QA:

Якщо апка «не працює», а логів нема — це ще не значить, що баг у коді.

Інколи це мережевий рівень: фаєрвол, проксі, гео-обмеження.

Wireshark — мастхев у QA-арсеналі, коли все інше мовчить.

Не треба бути девом, щоб зрозуміти, що трафік не пішов. Просто відкрив, відфільтрував, подивився — і вже можеш на daily сказати: «Запит навіть не дійшов, перевірте мережу »

Wireshark для QA — мінімум зусиль, максимум користі

Після останнього кейса з «сервер мовчить», обіцяв накидати фільтри, які реально юзаю, коли треба перевірити трафік і не згоріти в потоках SYN’ів і ACK’ів.

Ось топчик для QA:

⸻

🔹 Перевірити лише POST-запити:

http.request.method == "POST"

🔹 Побачити весь HTTPS-трафік (коли шифрування, але хоч бачити сесії):

tls

🔹 Показати тільки трафік між твоїм клієнтом і певною IP-адресою:

ip.addr == 192.168.1.100

🔹 Подивитися, чи є взагалі TCP-зʼєднання:

tcp.flags.syn == 1 && tcp.flags.ack == 0

Це покаже всі SYN-запити (початок встановлення TCP-зʼєднання) — корисно, коли підозрюєш, що сервер не приймає коннект.

⸻

🧠 Ідея яка: тобі як QA не треба лізти в payload (особливо якщо він зашифрований). Але можна побачити — чи взагалі пішов запит, чи сервер щось відповів, чи зʼєднання встановилось.

І от тоді ти не просто кажеш «не працює», а вже приходиш на стендап з картами на руках.

👋 Всім привіт у BugOrDefects!

Радий бачити вас тут — сподіваюсь, вам цікаво читати, так само як мені цікаво писати.
Цей канал я створив не просто для зберігання інфи, а щоб ми з вами мали простір для росту, обміну досвідом і трошки інсайтів QA.

А тепер — коротка історія з життя. Технічна, але життєва.

Коли баг жив не в коді, а в... CDN
Одного разу ми отримали репорт: “Кнопка не працює”.
Формально — все ОК. UI завантажується, запити йдуть, відповіді приходять.
Тільки в одних юзерів все працює, а в інших — ні.

Почав копати:

в DevTools — 200 на все

в логах сервера — теж чисто

все, що можна повторити локально — повторюється без багу

І ось де магія:
після перевірки через VPN виявилося, що з певних регіонів CDN (Content Delivery Network) віддає стару версію JS-файлів, які вже не сумісні з оновленим бекендом.

Причина — кешування на стороні CDN не було інвалідовано після деплою.

Висновок: навіть якщо код без багів — інфраструктура теж частина “системи”, і вона може ламати UX.

Такі дрібниці формують великий досвід.
QA — це не тільки “натиснути кнопку”, це вміння мислити ширше, бачити зв'язки і не зупинятись, поки не зрозумієш “чому насправді”.

Дякую, що ви тут! Далі — тільки цікавіше 👀

Всім привіт і вітаю на каналі
Сьогоднішня історія — з серії "Усе було добре... поки ні"

Прийшов зранку на роботу. Перевіряю Jira. І тут — повідомлення, від якого одразу вирівнюється постава 😅

Багу, яку раніше вже ловили і фіксили, знову находять на продакшені.
Думаю: ну як так?
А виявилось усе просто й боляче одночасно —
✅ бага була зафіксена
❌ але таргет-версія в Jira стояла не релізна, а якась other-branch

В результаті — фікс пішов повз реліз, QA поставила невірний таргет і все тихенько поїхало не туди.

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

Мораль проста:
🛡 QA — це не тільки тести, а ще й контроль процесу.
Бо іноді один чек у Jira може вирішити долю продакшну.

🧩 5 Chrome-розширень, без яких моє тестування вже не те
або «що в моєму QA-арсеналі завжди включено»

🔍 Wappalyzer
Дозволяє миттєво побачити, на чому побуданий сайт — фреймворки, CMS, вебсервер, аналітика, CDN, шрифти.
Часто допомагає ще до початку тестів зрозуміти технології проєкту, або знайти щось "неочікуване".

🍪 EditThisCookie
Редактор cookies. Міняю токени, видаляю зайве, підставляю роль іншого користувача — кайф.
Корисний не тільки для авторизації, а й для перевірки безпеки (наприклад, чи правильно працює expiry/session, чи не можна підкинути іншу сесію).

📡 Postman Interceptor
Пряме підключення браузера до Postman. Перехопив сесію — і можеш тестити API як залогінений юзер.
Сильно економить час, коли треба повторити флоу в UI та одразу поганяти бек.

🧾 JSON Formatter
Просто красиво форматує JSON. Все.
Коли response важкий і багато вкладень — без цього можна не побачити різницю між null, undefined і typo.

⚛️ React Developer Tools
Для тих, хто тестує React. Можна залізти в компонент, подивитись state, props, чи щось оновлюється і що ні.
Допомагає зрозуміти, чому кнопка неактивна або форма не сабмітиться — без танців з дебагом.

🧠 Ці інструменти — як продовження моїх рук.
Іноді саме завдяки ним баг знаходиться не за години, а за хвилини.

📌 Якщо зайде — зберу ще добірку з тулзами для API, mobile або accessibility тестування.

📲 Буду вдячний за репост Групи:
https://t.me/BugOrDefects

☕️ Ранкові історії QA #1: “Тест-кейс на інтуїцію”

Тікет:
📝 "Додати обмеження на кількість символів"

І все. Без макетів.
Без уточнень.
Без прикладів.

Ти такий:
"Ну, стандарт же — 255. Зроблю, перевірю, полетів далі."

А потім...

🚨 На проді обрубало все після 32 символів.
Клієнт в паніці, фідбек летить градом, баг репорт — прямо в серце.

💡 Мораль історії:
Ніколи не покладайся на “інтуїцію”.
Те, що здається очевидним — зазвичай, ні для кого не очевидне.
Питай. Уточнюй. Фіксуй. І ще раз уточнюй. 😄

📲 Буду вдячний за репост Групи.
https://t.me/BugOrDefects

Обідній скролінг не минув дарма: натрапив на мега добірку по security — ділюсь!

Хочете розпочати проводити тестування безпеки? Ось гайд

- OWASP Mobile Security Testing Guide – посібник від OWASP з тестування мобільних застосунків.

- OWASP Web Security Testing Guide – посібник від OWASP з тестування веб-застосунків.

- HowToHunt – туторіал і рекомендації щодо пошуку вразливостей.

- Pentest Book – корисна база знань із пентесту, сценаріїв проникнення та багато іншого.

- HackTricks – база знань CTF-гравця, де він ділиться хакерськими прийомами, техніками та всім, що дізнався на CTF, а також останніми дослідженнями та новинами.

- NIST SP 800-115 – керівництво від NIST із методологій тестування безпеки та проведення пентестів.

- Red Team Field Manual (RTFM) – кишенькова книга з корисними командами та техніками для Red Team і пентестерів.

- MITRE ATT&CK – база даних тактик, технік і процедур (TTPs), які використовуються в реальних атаках.

🕵️ QA-історія: “Таймаут — це не завжди про порт”

Недавно мав кейс, коли один сервер (назвемо його Сервер А) стукався до іншого (Сервер B) — і на кожну спробу з’єднання ми отримували таймаут.

Ну що ж, класика. Беру термінал, перевіряю.

Ну, думаю:
“Зараз по-швидкому telnet, curl, nc, і все злетить”.
Але щось пішло не так. 🙃

📍 Перші кроки перевірки:
🔸 Перевіряю з’єднання з A до B:

telnet server-b 8080

— конект є.

🔸 Далі:

nc -vz server-b 8080

— з’єднання успішне.

🔸 curl:

curl -v http://server-b:8080/ping

— зависає. Потім: Connection timed out.

❗️Це вже цікаво. Значить — дістатися можемо, але відповіді немає.

📍 Діагностика:

✅ Перевіряю з боку B:

sudo netstat -tulnp | grep 8080

— сервіс слухає порт.

✅ Перевіряю журнал логів на B — видно, що запити доходять і відповіді відправляються.

✅ На B пускаю tcpdump:

sudo tcpdump -i eth0 port 8080

— видно пакети на вхід і на вихід.

📍 А тепер магія Wireshark:
На Сервері A запускаю tcpdump:

sudo tcpdump -i eth0 host server-b and port 8080 -w trace.pcap

— відкриваю .pcap у Wireshark, і там видно тільки SYN → SYN-ACK → ACK → [DATA] → …
І все. Далі — нуль. Відповідь не доходить.

📍 Розгадка:

Після довгих пошуків і залучення інфри, знайшов причину:
🔥 фаєрвол на Сервері A блочив вхідні відповіді, бо вони приходили з іншого регіону (інший діапазон IP).

👉 Тобто:
Сервер A міг ініціювати з’єднання (вихідні пакети дозволені)

Але коли Сервер B відповідав — фаєрвол A це блочив (вхідні пакети з цього регіону були заборонені)

💡 І тому — таймаут.

📍 Команди, що реально допомогли:

🔹 Перевірити конект:

nc -vz server-b 8080
telnet server-b 8080

🔹 Перевірити маршрут:
traceroute server-b

🔹 Подивитись відкриті порти:

sudo netstat -tulnp

🔹 Зняти трафік:

sudo tcpdump -i eth0 host server-b -w trace.pcap

🔹 Аналіз трафіку у Wireshark

📍 Мораль QA-історії: Іноді конект не гарантує, що все працює.
🧠 Не зупиняйся на “telnet працює” — йди глибше.

Бо фаєрвол може сказати:
🔒 “Виходити можна. А от повертатись — ні.”

📲 Буду вдячний за репост Групи.
https://t.me/BugOrDefects

Ранкові історії QA #2: “П’ятничний реліз”
PM:
— Та нічого складного, дрібне оновлення. Зробимо сьогодні.
Dev:
— Там одна стрічка коду, пофіксили.
А ти запускаєш smoke — і бачиш, як “дрібне оновлення” знесло пів застосунку.
І ти розумієш:
в QA не буває “дрібного оновлення”, особливо в п’ятницю.

📲 Буду вдячний за репост Групи.
https://t.me/BugOrDefects

🎯 "Як набратись досвіду, якщо роботи в QA ще нема?"
Це питання мені за цей тиждень написали в особисті кілька людей. Прямо:

"Я вчуся на курсах, практикуюсь, але як почати?"
"Де брати реальні таски, якщо ще не працевлаштований?"

І я такий:
Окей, настав час розповісти.

📍 uTest і TestIO — дві платформи, з яких я сам починав.
Причому я ще був на другому місяці курсів, а вже фрілансив і мав "Практичний" досвід.

🔹 На TestIO я тестував мобільні апки, вебсайти, фічі для логінів, баги ловив — і реально заробляв.
Перші виплати — чистий кайф. Плюс англійська в дії, UI — як на долоні, і вчишся писати багрепорти, які не соромно в портфоліо.

🔹 На uTest теж круто: там багато exploratory тестування, юзерські сценарії, де треба думати як end-user, а не просто тицяти.

💬 Ці платформи — це не просто “погратись”. Це:
✔️ Практика в реальних проектах
✔️ Можливість бачити, як пишуть баги інші
✔️ Робота з інтернаціональною QA-спільнотою
✔️ І головне — досвід, який можна писати в CV вже зараз

💡 Мораль:
Якщо роботи поки нема — досвід все одно можна здобути.
І повір: навіть кілька місяців на TestIO/uTest дають більше, ніж чекати першу вакансію на дивані.

📲 Буду вдячний за репост Групи.
https://t.me/BugOrDefects

🛠 5 прикольних фішок Postman, які реально спрощують життя QA-шника

Я часто чую: «Postman — це просто для ручного ганяння API». Але насправді він набагато глибший. Якщо ти мануальний QA і працюєш з API, ось 5 речей у Postman, які я використовую майже щодня і які варто знати:

1️⃣ Змінні середовища (Environment variables)
Коли ти тестиш на кількох енвах — dev, staging, prod — забивати руками URL або токени кожного разу = біль.
В Postman можна створити середовище і підставляти змінні типу

{{baseUrl}}

або

 {{authToken}}.

Ідеально, коли треба швидко перемкнутись з одного енву на інший — 2 кліки і готово.

2️⃣ Pre-request scripts — автоматизація до того, як піде запит
Наприклад, треба згенерити унікальний email або зберегти токен перед наступним запитом?
Postman дозволяє запускати JS-скрипти до запиту.
Я, наприклад, часто юзаю:

pm.environment.set("email", 

user_${Date.now()}@test.com);

Потім просто вставляю

{{email}} 

у body.

3️⃣ Collection Runner — для масових прогонів
Не хочеш клікати вручну по 10+ запитах? Запускай колекцію одразу.
Плюс — можна підвантажити CSV/JSON з різними параметрами й перевірити, як API поводиться з різними даними.

4️⃣ Автотест у вкладці Tests (так, Postman — це ще й маленький тест-фреймворк)
Postman дозволяє писати невеликі перевірки прямо у кожному запиті:

pm.test("Status code is 200", () => {
pm.response.to.have.status(200);
});

Я так часто перевіряю не лише статус, а й тіло відповіді або специфічні поля. Це не повна автоматизація, але вже щось.

5️⃣ Newman — якщо треба запускати все з терміналу або CI/CD
Newman — це CLI-версія Postman. Завантажив колекцію, і можеш запускати її хоч у Jenkins, хоч з терміналу.
Коли хочеться напівавтоматизувати smoke-тест — ідеально.

Це все прості штуки, але якщо почати ними користуватись — ручне тестування API стає на рівень вище.

📲 Буду вдячний за репост Групи.
https://t.me/BugOrDefects

П’ятниця. Вечір
Всі нормальні люди — на барі, на дивані або вже в сні.
А ти — QA.

Лягаєш спати після важкого тижня, і тут…
БАМ! — в голову прилітає думка:
“А якщо той тікет не репродюситься, бо дані летять не туди? Або тому що timezone не співпав?..”

Вставати не можна. Але спокою вже немає.
Бо мозок — це ще той Jenkins:
пуш — трігер — білд думок — без таймауту.

Вам таке знайоме? Відчути той дзен на п’ятничній ночі і в той же час — тиск думок про баги?

Всім гарного вечора і вихідних

Ранкові історії QA #3: "Субота для QA"

Плани:
☕️ Спокійно випити каву.
🛋 Полежати без думок про баги.
📖 Можливо, почитати щось для душі.

Реальність:
Замовляєш латте через додаток.
Отримуєш американо.
Починаєш тестувати апку доставки:

- Чи правильна передача параметрів?
- Чи не переплутані поля у базі?
- Чи не відвалився десь маппінг кавових типів?..

QA mode: активовано автоматично.
Навіть у суботу. Навіть за кавою.

Мораль:
Ти можеш вийти у вихідний, але вихідний з QA — ні.

📲 Буду вдячний за репост Групи.
https://t.me/BugOrDefects