Доброго вечора - знайомлю вас з крутой штукой =)))

Netcat (nc) — твій кращий друг у QA-інвестигейшені

Що це таке?
Netcat — це легкий, універсальний інструмент для роботи з мережею. Підключитись, відлагоджувати TCP/UDP-з’єднання, прослухати порт, передати дані, перевірити доступність, навіть створювати імпровізовані чати між машинами — він усе це може.

Це як якщо telnet, curl і nmap зібрались в одну утиліту без зайвих балачок.

Що вміє nc і чим він корисний QA:
Перевірити доступність сервісу/порта:

nc -zv api.myproject.local 443

Просканувати портовий діапазон (чи живе щось на цих портах):

nc -zv service.local 8000-8100

Підняти локальний listener:

nc -l 9999

(корисно, коли хочеш подивитися, чи хтось шле запит)

Відправити тестовий payload у сокет:

echo "ping" | nc 127.0.0.1 8080

Додати таймаут:

nc -zvw5 service.dev 7000

Зробити імпровізований чат між машинами (так, nc це теж вміє!)
На одному компі (слухаєш):

nc -l 1234

На іншому (підключаєшся):

nc IP_першого 1234

Пишеш — і бачиш повідомлення на іншій машині в real-time. Можна навіть влаштувати міні-QA-диспут


Навіщо це вам?
Швидко зрозуміти, чому тести падають: сервіс не працює, чи реально бага?

Перевірити staging, dev або QA середовище без чекання девопса

Тестувати інтеграції без підключення реального бекенду

Як встановити?
Ubuntu / Debian:

sudo apt install netcat

macOS (через Homebrew):

brew install netcat

Windows:
https://eternallybored.org/misc/netcat/

Збережи пост — буде день, коли staging впаде, а nc витягне тебе з хаосу

Якщо хочеш part 2 з прикладами передачі файлів, проксі чи відладки сокетів — пиши в коменти.

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

Всім доброго раночку 👋👋👋

Сьогодні без історій. Просто день.
Такий собі — як понеділок, але без понеділка.

Все працює, задачі клікаються, прод дихає рівно.
І наче можна просто спокійно… жити?

Але є привід для теплоти.
Вчора був дуже душевний день — один з моїх учнів отримав офер!
Ми до цього дійшли, і от — все склалось.

Це завжди трошки як баг, що став фічею.

Нехай у вас сьогодні буде тихо, стабільно й з хорошим вайбом.
А якщо щось бахне — ну, розберемось. Ми ж QA.

До теми з ранкового пула про перформанс!

Якщо цікаво копнути глибше — рекомендую блог BlazeMeter.
BlazeMeter Blog — це як технічний Medium для тестувальників:

— чеклісти з performance для API (реально зручно)

— кейси типу "як ми тестували мікросервіси на проді і не згоріли"

— інтеграції з JMeter, Jenkins і навіть Postman'ом

— і головне — читається просто, а не як документація до космічного шатлу

Ловіть посилання — https://www.blazemeter.com/blog

Зберігай у шпаргалку, поки не встигли сховати за пейвол 😅
І якщо знайдеш там перлину — кидай у коменти, шоб ми теж подивились.

Напишіть в коментарі знали по такий?

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

Доброго ранку - я опять з нудними історіями)

🌞 Ранкова історія QA: REST не завжди “OK”

Робочий день почався… не з кави і кліків по задачках. А з повідомлення в групі
Це не баг. REST повертає 200 OK.

🙃 Тааак, от і весь мій ранок полетів.

Не хотів відкривати повідомлення до кави. Але... щось мене потягнуло. І все — каву відмінили, пішов пояснювати.

Почав із простого
“Те, що REST повертає 200 OK — не значить, що для клієнта все добре.”

Бо якщо в тілі респонсу пусто, або там не ті дані, які потрібні клієнту, то яке ж це “OK”? Для API команда відпрацювала, а для UI — нічого не ясно.

Клієнт очікує масив з item’ами, який має значення, що показувати, які кнопки вмикати, чи взагалі є дані.
А в нас — просто статус без контенту. Ну, дякую.

40 хвилин пояснень, прикладів, зворотних кейсів, і — буде фікс 🙌
REST навчиться відповідати не просто “success”, а ще й інформативно.
Бо ми ж не просто виконуємо запит, ми будуємо діалог між фронтом і беком.

А у вас бувають такі моменти, коли треба пояснювати, що “success” — ще не значить “правильно”?

Гарного всім дня і тримаємось — до вихідних уже ближче 😄

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

Всім доброго ранку!! 🤗

Ранкові історіі QA - Впевнений шо у вас таке теж було і не раз)
Дайте хоч щось… — сказав дев і зробив твій день присвішений дослідження і збору 1000000 кб логів 🤪🤪🤪


Коли дев каже

“У нас нічого не видно. Дайте хоч щось…”

А ти бачиш, як на клієнті трансляція йде. Відео програється, спікер говорить, все типу ок. Але dev на стороні серверу каже:
У нас порожньо. Нічого не приходить.

І ти такий
Ну добре…
Тут починається твоя улюблена частина — трасування, sniffing і трохи QA-магії
Бо коли в UI щось відображається, а бекенд ніби нічого не отримує — ти вже знаєш, що це класика.

Клієнт є, сервер є, а трафік — ніби у відпустці.

Сценарій дуже простий як двері
У додатку йде трансляція. Але сервер не бачить ніякого трафіку (відеопотік через UDP).
А дев каже
У нас все чисто. Напевно, на клієнті щось…


І ти такій окей давай ставимо флажки і ловимо пакети

Слухаємо клієнта
Вмикаємо Wireshark (або dumpcap) на клієнтському боці.

ip.addr == <server_ip> && udp.port == 5000

або просто

ip.addr == <server_ip>

Запускаємо запис, відтворюємо трансляцію, ловимо .pcap.
У дампі бачимо:
Пакети йдуть / payload є / порти вказані правильно

Клієнт — невинний.

ну окай тоді слухаємо сервер
На сервері — tcpdump, бо він не підведе

sudo tcpdump -i any host <client_ip> and udp port 5000 -w /tmp/server_capture.pcap

І… порожньо. Нічого. Нуль.
кей, тоді пробуємо ще фокус

sudo tcpdump -i any port 5000

Все ще — тиша. Нема навіть SYN, нема навіть запитів.
Ага! Тут вже цікаво.
так тепер аналізую мережу

Якщо на клієнті видно, а на сервері — нічого, це може бути:

фаєрвол (локальний або міжмережевий)

UDP-зв’язок блокується між сегментами

Неправильна маршрутизація (NAT, VPN, проксі)

Сервер слухає не той інтерфейс або порт

Аналіз в Wireshark
Фільтруємо пакети за:

ip.addr == <server_ip>

udp

rtp

frame contains "SETUP"

(якщо це RTSP)
І вже можна точно сказати:
“Ось клієнт відправляє, ось час, ось порт. Але сервер не бачить взагалі.”

Відправляєш dev’у: .pcap + скрін + timestamp
І підпис:

Ось вам всі логи і почті рішення - займайтесь)
але можно спробувати ще и фікс зробити))) але яж просто QA

Ключові фішки аналізу

tcpdump на сервері — must have

Wireshark — ідеально для фільтрації по потоку (stream)

Фільтри: ip.addr, udp, tcp.stream eq, frame contains

Завжди дивись: SYN, ACK, payload, порт, інтерфейс

Moral of the story,
Коли dev каже “Дайте хоч щось” —
Дай йому дамп і хай не бубнить.

бувало у вас таке що деви хочуть вид вас все на блюдечці?

Буду вдячний за репост группи, + приєднуйтесь до нас)
https://t.me/BugOrDefects