Друзі, привіт 💛 Як ваші справи?
Ну що, можу сьогодні привітати вас із професійним днем)
Не кажіть на себе чи когось «тестери». Ми з вами, QA інженери, і в цьому сила. Розвивайтесь технічно, і на ринку вам ціни не буде

А тепер Ранкова історія QA:

Сиджу зранку, треба глянути одну проблему на новому білді.
Ситуація яка,
Дзвінок піднімається, але апка не показує, хто саме тобі дзвонить.
У попередній версії все працювало, а в цій поламалось. Ну окей, відкриваю логи.

І шо ви думаєте? По логах усе ідеально: івенти приходять, атрибути коректні. Часто я з досвіду бачу відразу, де воно розсипалось, а тут тупо тиша.

Ну, думаю, треба порівняти логи на старому білді і на новому. Раніше я юзав Notepad++, але він незручний для великих файлів. І тут мені радять тул, який реально

І цей тул дня: Total Commander

Дам вам сразу офіційний сайт: https://www.ghisler.com/download.htm

Фішка проста: відкриваєш два лога поруч, і він підсвічує різницю рядок до рядка червоним. це просто бомба для QA, які мають справу з логами.

Саме завдяки цьому я побачив:
проблема у гонці по таймінгу, івент про юзера приходив раніше, ніж сам дзвінок конектився. Ми його ігнорили, бо чекали вже після. От і все, завдяки інструменту знайшли, чому баг проявився.

Який поінт від мене)
Не лінуйтесь читати і порівнювати логи. Очима завжди видно більше, ніж здається.
А тул дає можливість побачити там, де «воно ж все правильно».

А тепер питання до вас:
я юзаю Total Commander, а ви що використовуєте для порівняння логів? Може є щось ще новіше і крутіше? Поділіться в коментарях)

Всім гарного дня і настрою, і ще раз зі святом, колеги QA Engineers
Обняв 🤗

Друзі, привіт
Як ви? Сподіваюсь, ви та ваші рідні в безпеці

Хочу побажати вам гарного і продуктивного дня та чучуть підняти настрій

Учора почув, як мої родичі по телефону розповідають, чим я займаюсь у QA. І знаєте шо? Це відео - ідеальне пояснення
Бо у багатьох з вас, думаю, теж є такі родичі:
- які знають про інтернет тільки те, що він «десь є»
- які вважають, що якщо ти в IT, то ти мега мозг, який вміє все
- і що ти можеш прийти, все налаштувати, полагодити, а якщо пощастить - навіть «зробити зв’язок з космосом»

Ну от таке воно життя

Всіх обняв 🤗
Сильні 💛

Добрий вечір, друзі! 🌙

Щоб завжди було під рукою)

Тримайте коротеньку шпаргалку з топ-20 найпоширеніших портів. Це ті, які майже завжди зустрічаються у проектах, і про них треба пам’ятати.

Чому саме це?
Бо коли щось «не відкривається» або «не конектиться», перше що робить будь-який КУА перевіряє саме порти.
А знання дефолтних портів економить час і нерви)

Всім гарного вечора, і хай ваші сервіси слухають на правильних портах)
Обняв 🤗

Note: Якщо хочете, я зроблю ще міні-табличку з командами для перевірки відкритості портів (telnet, nc, nmap)? тоді з вас серденько а може і вогник)

Всім доброго ранку, друзі! ☀️

А ви бачили ці дані? цікава стаття від DigitalDefynd
https://digitaldefynd.com/IQ/top-countries-for-career-in-qa-testing

І Ці цифри не просто далека мрія.
Вони показують, що інвестиції в навички в автоматизацію, якість, технічність, реально окупаються.
Якщо ви зараз на мідлі або навіть джуні, але намагаєтесь зрозуміти, куди качатись, ця стаття якраз мотивує.


Всім продуктивного дня, хай надихають цифри, але хай мотивують дії)
Обняв усіх, сильні 💪

Добрий ранок, друзі ☀️
Ну що давайте розберемо наш останній пул про WebSocket поверх TCP, бо бачу, що були різні варіанти відповідей)

Чому не (A)
WebSocket, це окремий транспортний протокол, який працює напряму поверх IP
Ні. Транспортні протоколи, це TCP і UDP. А WebSocket - це розширення до HTTP, а не окремий транспорт.

Чому не (C)
WebSocket це тип UDP-з’єднання
Також ні. Бо WebSocket завжди працює поверх TCP, а от UDP юзається для швидких стрімінгових протоколів (типу RTP у відео).

Чому не (D)
WebSocket - це просто HTTPS-запити, які відправляються кожні кілька секунд
Це опис технології long polling, а не WebSocket. У WebSocket з’єднання постійне, і немає потреби кожного разу відкривати новий запит.


і чому саме (B)
WebSocket - це розширення HTTP, яке дозволяє встановити постійне full-duplex з’єднання поверх TCP.
Тобто: Спочатку йде handshake через HTTP(S). А потім вже з’єднання (апгрейдиться) і далі вже працює як окремий канал поверх TCP.

Клієнт і сервер можуть обмінюватися даними в обидві сторони у реальному часі без повторних запитів.

Який поін для КУА
Тестуємо, чи з’єднання стабільно тримається (reconnect при розриві). Дивимось, чи дані приходять у правильному порядку. Перевіряємо edge cases (наприклад, обрив мережі, idle timeout, повторна ініціалізація).

Тому якщо бачите у логах Upgrade: websocket - це значить, що ваш застосунок пішов у постійне TCP-з’єднання)

Всіх обняв 🤗
Сильні 💛

Друзі привіт, ну що ось і вихідні, коли можно видохнути і зайнятися своїми справами, я щось опять захворів)

Але сьогодні коротенько, але дуже практично. Бо скільки мене питали, що сиджу в Wireshark і які фільтри. Це мої те що еврі дей)

Це для Аудіо (SIP/RTP)

sip || rtp

ловимо сигналізацію дзвінків (SIP) і сам потік аудіо (RTP)

Відео (WebRTC/RTSP)

rtsp || stun || turn || webrtc

тут іде handshake і пакети для відео/екраншару.

CSTA (телеком API)

tcp.port == 7000

Ну тут або свій, якщо кастомно). Це канал, де ходять евенти типу call start/stop, hold, transfer.

Ну і куди ж без ресту

http || tcp.port == 443

дивимось веб-запити: чи коректно апка звертається до бекенду.

Маленький лайфхак: зробіть собі Display Filters закладками в Wireshark, і тоді не будете кожного разу мучитись.

Але це те що треба сразу під рукою, але богато що ще є,
Якщо цікаво тоді зроблю вам великий пост але з усіма кастомними фільтрами? типу “Ready-to-Use” шпаргалка: логіни, TLS-handshake, 4xx/5xx HTTP, DNS, packet loss у RTP?

Всім гарних вихідних, обняв🤗🤗🤗

Друзі привіт
Сьогодні даже не привітався зранку, бо шось я вже 5-й день хворію, і працювати треба, і коротше такий день шо опа(
Але нема шо жалітися, так шо давайте доб’ємо цю тему до кінця поки я не пообідав)

Логіни / авторизація

http.request.method == "POST" && frame contains "login"
frame contains "Authorization"
frame contains "Bearer"

миттєво видно, що клієнт шле при логіні або токен-рефреші.

TLS Handshake

ssl.handshake || tls.handshake

чи реально узгоджуються ключі? Часто тут падає handshake, і ти думаєш “бекенд не працює”, а насправді cipher mismatch.

DNS lookup

dns
dns.qry.name contains "api"

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

WebSocket

tcp.port == 8080 || tcp.port == 3000
frame contains "Upgrade: websocket"

коли треба відловити handshake та подивитися, чи реально відкривається WS.

HTTP 4xx/5xx

http.response.code >= 400

миттєво відфільтровує всі фейли клієнта й сервера.

RTP / packet loss

rtp
rtp && (rtp.seq != previous_rtp.seq+1)

у Wireshark: Telephony → RTP → Stream Analysis — там видно % втрат і джиттер.

gRPC / HTTP2

http2
http2.header.value contains "grpc"

часто юзаю у мобільних апках, а баги саме там.

CORS / Preflight

http.request.method == "OPTIONS"

одразу видно проблеми з крос-доменом.

Redirects

http.response.code == 301 || http.response.code == 302

інколи корисно побачити, куди реально відсилає клієнт.

Timeout / reset

tcp.flags.reset == 1

якщо сервер сам скидає конекшн.

По ключовому слову

frame contains "token"
frame contains "error"

банально, але працює краще за DevTools, бо видно навіть у зашифрованих payload (через фрейм-хедери).

Який поінт від мене)
Фільтри = наш рятівний круг. Коли UI каже все ок, а користувач кричить нічого не працює - Wireshark завжди покаже, де правда.

Ще раз всім гарного дня не хворійте, всіх обняв 🤗🤗🤗