🛠 Вечірня історія з технічним присмаком: Вебсокети і магія ping/pong

Короче, сьогодні сидів, перевіряв домашки і мене різко вилогінює з системи. Я такий: "Опа, що це було?". Тільки ж сьогодні логінився, токен мав би жити довше, тим більше я активно клікав по LMS.

И тут я згадав для вас реальну історію, якою хотів би Поділитися)

Тестували ми тоді новий функціонал авторизації.
Я зайшов тестовим юзером, роблю собі завдання, все норм. Відволікся на іншу вкладку, через кілька хвилин повертаюсь — юзера викинуло в логаут. Думаю: "Може я сам випадково натиснув щось?.."

Працюємо далі. Знову логінюся, клікаю туди-сюди — повертаюсь на вкладку... і знову вилогін. Тут вже явно щось не так подумав я.

Почав розбиратися. Поліз у логи. Бачу чіткий Logout Event від сервера. Тобто мене не фронт розлогінює — сервер сам присилає команду на вигнання, цікаво 👀

Тоді я поліз у логи сервера — шукав всі події по моєму sessionID. Там явно видно:
Session expired due to inactivity.
Sent logout event to client.
Але сесія ж була активна... ну, або мала бути. 🤔

Відкрив devtools → вкладку Network → фільтр WebSocket → і почав слідкувати, що відбувається.

Після копання стало ясно:
Фронт мав періодично слати ping серверу через WebSocket, щоби підтверджувати "я тут". А насправді клієнт мовчав, і через 90 секунд сервер вирішував: "Та його вже нема" — і автоматично сесію закривав.


Мораль історії:
🧠Іноді причина проблеми глибше, ніж здається на перший погляд. Не вистачає просто подивитись на куки чи токени — треба копати до рівня WebSocket протоколу і реально ловити трафік! Та Дивитися як поводить себе транспортний рівень — особливо, коли працюєш з WebSocket'ами.

я даже знайшов всій старий скрипт по Python який писав коли ще було цікаво погратися з WebSocket та набити руку по коду - я його чутка підправив і залишу вам, може кому буде цікаво подивитися

import websocket
import threading
import time


WS_URL = "wss://echo.websocket.org"   # заміни на свій WebSocket URL
PING_INTERVAL = 30  


def on_open(ws):
    print("[OPEN] Connection established")

    def send_ping():
        while True:
            print("[PING] Sending ping to server...")
            try:
                ws.send(
                    "ping"
                )  
            except Exception as e:
                print("[ERROR] Error while sending ping:", e)
                break
            time.sleep(PING_INTERVAL)

    
    threading.Thread(target=send_ping).start()


def on_message(ws, message):
    print(f"[MESSAGE] Message received: {message}")


def on_pong(ws, message):
    print(f"[PONG] Pong response from server: {message}")


def on_error(ws, error):
    print(f"[ERROR] Connection error: {error}")


def on_close(ws, close_status_code, close_msg):
    print(f"[CLOSE] Connection closed. Code: {close_status_code}, Message: {close_msg}")



ws = websocket.WebSocketApp(
    WS_URL,
    on_open=on_open,
    on_message=on_message,
    on_error=on_error,
    on_close=on_close,
    on_pong=on_pong,  
)


print("[INFO] Starting WebSocket client...")
ws.run_forever(ping_interval=PING_INTERVAL, ping_timeout=10)

🛠 Чому цей скрипт бійсно корисний)
Працює на будь-якому WebSocket сервері (wss і ws підтримка)
Має окремий обробник pong відповідей
Показує реальні помилки, якщо сервер не відповідає
Дає змогу швидко діагностувати проблеми з heartbeat (пінг-понг механізмом

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

Всім привіт - Гарного настрою в Понеділок

🌞 Ранкові історії QA #5: "Понеділок, який заряджає"
Прокидаєшся в понеділок.
На душі несподівано легко. Навіть кава здається смачнішою зазвичай. ☕️
Заходиш на спринт-планування:
✅ Команда в зборі.
✅ Плани чіткі.
✅ Стратегії тестування вже крутяться в голові.
✅ Баги від минулого спринту закриті.
І тут ловиш себе на думці:
QA — це не тільки про пошук багів.
Це про створення впевненості.
В продукті. В команді. І навіть у собі. ✨
Мораль понеділка:
Правильний старт тижня починається з правильного настрою.
А правильний настрій — із віри, що сьогодні буде крутий день! 🚀

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

Всім доброго вечора! 🌟
Ну шо, давайте розберемо коротенько, що все ж таке ці TLS і SSL.

Перше — дякую всім, хто взяв участь у завданні!

🔹 Що таке SSL?
SSL (Secure Sockets Layer) — це старий протокол шифрування для безпечної передачі даних.
З часом через виявлені уразливості його замінив новіший, безпечніший протокол — TLS.

🔹 Що таке TLS?
TLS (Transport Layer Security) — це сучасний протокол для захисту даних у мережі.
Він базується на SSL, але використовує кращі алгоритми шифрування і аутентифікації.
TLS сьогодні активно використовується у браузерах, API, пошті, VPN тощо.

🔹 Трохи більше інфи:
SSL був розроблений Netscape ще у 90-х для захисту інтернет-комунікацій.
Але мав кілька серйозних вразливостей (особливо SSL 2.0 і SSL 3.0).
Тому його замінив TLS — більш захищений і сучасний стандарт.

TLS — це не "стара версія SSL", а оновлений і безпечний протокол.
На сьогоднішній день усі нормальні системи використовують TLS 1.2 або TLS 1.3.
SSL більше не використовується у виробничих системах.

Чому не А)?
А) "TLS — це стара версія SSL, вони однакові."
👉 Ні, TLS — це новіший протокол, а не "стара версія".
У TLS інші механізми встановлення з'єднання, шифрування і безпеки.

Чому не В)?
В) "TLS і SSL — це два різні типи VPN-з'єднань."
👉 Ні, TLS/SSL — це протоколи шифрування трафіку, а не створення VPN.
VPN — це окрема технологія (OpenVPN, IPsec, WireGuard).

Чому не Г)?
Г) "SSL використовується тільки в API, а TLS тільки в браузерах."
👉 Ні, і API, і браузери працюють через TLS.
SSL застарів і більше не використовується

🎯 Чому це важливо для тестувальника?
Як QA ми маємо перевіряти:

Чи використовує проект TLS 1.2/1.3.
Чи вимкнені старі протоколи (SSL 2.0, 3.0, TLS 1.0, TLS 1.1).
Чи правильно налаштовані HTTPS-сертифікати та шифри.

Особливо важливо для безпекового тестування (security testing) і відповідності стандартам (наприклад, PCI DSS).

Дякую всім за активність! 🚀


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

☀️ Ранкові історії QA #6 ☀️ Доброго ранку!!!

Ранок починається не з кави, а з повідомлення в чаті команди:
«У клієнта не відкривається веб, пише “з’єднання не захищене” 😱»
А ти вчора ще подумав: "Треба глянути ті сертифікати... завтра точно подивлюсь."
Ну ось і настав «завтра»

📌 Мораль: автоматизоване сповіщення про закінчення дії сертифікатів може врятувати не лише прод, а й твій ранок 😄

💬 А як у вас: є моніторинг сертифікатів чи все ще ручна перевірка раз на пів року «по відчуттю»? Поділіться 👇

🧲 Bug Magnet — underrated друг для веб-QA
(особливо на старті кар'єри)

Сьогодні з 7 ранку знову сів перевіряти домашки від студентів. І як завжди — помітив знайому картину:
🛑 поля без валідації
🛑 ніхто не тестує на спецсимволи
🛑 SQL-ін'єкції проходять як рідні
🛑 граничні значення взагалі не чіпали

І от в черговий раз я згадав тул, який мені ще на перших курсах порадила викладачка. Він тоді реально допоміг мені почати думати як QA, а не просто "клікати кнопочки".

👉 Це Bug Magnet — розширення для браузера, яке додає контекстне меню з готовими edge-case значеннями прямо в input-поля на сайті. Просто правий клік — і вставляєш:

- наддовгі рядки
- спецсимволи
- emoji
- SQL / XSS ін’єкції
- пусті значення
- tricky email-и
- edge-case числа/дати

Це маст-хев для новачків — бо не треба самому придумувати “що б таке вставити”. Він сам підкаже, і при цьому навчає думати як потенційний зловмисник або просто як уважний тестувальник.

📌 Bug Magnet допоможе вам:

✅ Тестувати валідацію без зайвих зусиль
✅ Ловити потенційні проблеми ще до бекенду
✅ Думати не тільки позитивними, а й негативними сценаріями

📥 Доступний у Chrome та Firefox.
І так, він повністю безкоштовний.

🧠 Якщо ви починаєте шлях у QA або вже працюєте, але не чули про цей інструмент — обов’язково спробуйте.

А якщо юзаєте щось подібне — дайте в коментарях, цікаво зробити нову підбірку 🔍

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

Привіт - Доповнення до цього поста

🔍 5 маловідомих, але потужних інструментів для веб-QA
(з технічним підходом і деталями, які ви не знайдете в кожному курсі)

Вже відомий для вас
1. Bug Magnet

📌 Що це?
Розширення для Chrome/Firefox, яке додає контекстне меню з шаблонами граничних значень, спецсимволів, SQL/XSS payload, Unicode, імен з пробілами, довгих рядків тощо.

🎯 Навіщо QA?
Тестування input-полів на валідацію
Перевірка обробки edge cases
Виявлення недостатнього санітайзингу і недоступності

🛠 Як використовувати?
Клікаєш правою кнопкою на інпуті — і вставляєш складний текст за один клік.

2. HackBar (Quantum)
📌 Що це?
Панель у Firefox для ручного тестування вразливостей веб-додатків: SQL Injection, XSS, Command Injection тощо.

🎯 Навіщо QA?
Безпекове тестування без складних тулз типу Burp Suite
Перевірка інпутів і URL на ін’єкції

💡 Приклад: вставити ' OR 1=1 -- у URL або форму прямо з панелі — перевіряєш реакцію сервера.

3. Wappalyzer
📌 Що це?
Розширення до браузера, що визначає технології, які стоять за сайтом (CMS, вебсервер, JavaScript фреймворки, аналітика, CDN, безпека тощо).

🎯 Навіщо QA?
- Розуміння архітектури продукту
- Перевірка наскільки відрізняються стаді/прод
- Використовуєш для глибшого аналізу багів (наприклад, бачиш, що на проді змінили JS-фреймворк — тести валяться не просто так)


4. Hoppscotch (ex-Postwoman)
📌 Що це?
Веб-альтернатива Postman — легкий, швидкий, відкритий REST-клієнт прямо у браузері.

🎯 Навіщо QA?
- API тестування без встановлення Postman
- Перевірка GET/POST/PUT/DELETE запитів
- Збереження сценаріїв, токенів, аутентифікація

💡 Бонус: легкий UI, відкритий код, CI-friendly.


5. JSONPath Evaluator (jsonpath.com)
Онлайн-тулза для парсингу та вибірки даних із JSON через JSONPath — аналог XPath для XML.

🎯 Навіщо QA?
- Тестування складних API-відповідей
- Перевірка вкладених об’єктів без мороки
- Автоматизація перевірок на основі точних полів

💡 Приклад: маєш великий JSON — можеш швидко витягти $.data[0].user.name і перевірити значення без скролу очима.


🔧 Висновок:
Ці тулзи не просто «плюшки», а реальні інструменти під капот — для тих, хто хоче копати глибше, навіть будучи мануальщиком.

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

Всім доброго вечора - Робочий день закінчився, ну шо розберемо шо таке Let's Encrypt

Якщо коротко Let's Encrypt — це некомерційна організація, яка допомагає зробити інтернет безпечнішим. Вона безкоштовно надає SSL/TLS-сертифікати, завдяки яким дані між сайтом і користувачем передаються у зашифрованому вигляді. Увесь процес отримання та поновлення сертифікатів автоматизований, тому власнику сайту не потрібно робити це вручну або платити — впровадити HTTPS можна швидко й легко.

Ключові фішки:
- Повністю безкоштовна альтернатива комерційним CA (як Comodo, GeoTrust)
- Автоматична видача та оновлення сертифікатів через протокол ACME
- Працює з популярними вебсерверами (Apache, Nginx), CI/CD, Docker тощо
- Довіряється всіма сучасними браузерами (включно з Chrome, Firefox, Edge)

Чому це важливо для QA?
- Перевіряєш валідність сертифікатів на стаді та проді
- Можеш зловити проблеми з некоректною інтеграцією або простроченням
- Тестуєш взаємодію HTTPS API, редиректи, HSTS тощо
- Часто Let's Encrypt — єдиний SSL на non-prod середовищі

Чому інші варіанти — ні?
A) "Платний сервіс для генерації TLS/SSL-сертифікатів"
- Саме фішка Let's Encrypt — безкоштовність.
Платні аналоги існують, але Let’s Encrypt не бере гроші за сертифікати.

B) "Браузерна технологія, що блокує фішингові сайти"
Це щось ближче до Google Safe Browsing або SmartScreen від Microsoft.
Let's Encrypt не займається фільтрацією сайтів.

D) "Онлайн-сканер для пошуку вразливостей в HTTPS-з'єднаннях"
Це можуть бути інструменти типу SSL Labs, Qualys або Hardenize - про які я вам можу також розказати)
Let's Encrypt — це центр сертифікації, а не сканер.

І тепер Висновок:
Let's Encrypt — це must-know для будь-якого QA, хто тестує веб або API через HTTPS.
Навіть якщо ти не DevOps, але ловиш баги типу:

- NET::ERR_CERT_DATE_INVALID
- SSL certificate has expired
- Connection not secure — то треба знати, звідки сертифікат, і як він працює в інфраструктурі.

До речі, багато CI/CD (GitHub Actions, GitLab, Render, Railway) інтегруються з Let's Encrypt — тому тестувальнику важливо розуміти, коли це може зламатися.

В цьому пулі було дуже напружено - всім гарного вечора ❤️❤️❤️


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

Всім доброго ранку - і гарно дня ☀️

☀️ Ранкові історії QA #7 ☀️
"А у вас теж таке було?"

Початок дня. Вмикаю ноут, відкриваю Jira — і одразу в очі:
“Баг закрито. Причина: not a bug, works as intended”.

А вчора ж я годину бився з кейсом, де:
користувач отримує помилку 403 без жодної логіки,

- логи порожні,
- dev відповів “а у нас так задумано” 🙃

І от я сиджу, п’ю каву, дивлюсь на цей “задум” — і думаю:
“Задум такий, що навіть юзер сам здогадатись не зможе...”

Мораль:
Іноді баг — це не баг, а UX-пастка. Іноді «так задумано» — це просто зручно не копатися глибше.

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

А у вас теж таке було? Що вважали "фічею", а по факту — 100% баг?
Поділіться, подивимось, чия історія більш дика 😄

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

🌙 Вечірня історія QA, Дзвінки падають. На проді.

Середа. 18:30. Завтра йду у Відпустку,

Сиджу собі, тихо тестую зміну в UI — і тут дев пише:
"Слухай, користувачі кажуть — дзвінки скидає через кілька секунд. Можеш глянути?"
Я такий: "Та звісно, зараз гляну. Напевно якась дурниця. Хвилин 10 і розберемось." Ага.

Почалося:
Повторюю сценарій — створюю дзвінок, 3 секунди — і хегап.
- Не натискав нічого. Просто дроп.
- Другий раз — те саме.

Дивлюсь лог клієнта
- reason: hangup
- disconnected by Janus
= тобто сервер сам скидає виклик.

Йду в Janus logs на staging
- там event: hangup, reason: DTLS timeout
- ого. Значить проблема на рівні WebRTC.

Ну шо погнали дивитися:
1. Wireshark
- DTLS handshake зависав, не проходив до кінця.
- клієнт надсилає ClientHello, а відповідь або приходить з затримкою, або не приходить зовсім.

2. Janus API (/v1/sessions)
- бачу, що сесія створюється, але media = false, ice = disconnected
- Janus розриває сесію автоматом по таймауту.

3. Перевірив TLS-сертифікати на TURN-сервері
- валідні
- але порт відкритий лише локально (інфраструктура обновлялась, а ufw обмежив доступ)

Фінальний аналіз:
- Коли клієнт намагається підключитись до TURN, DTLS не проходить, бо порт недоступний.
- Janus не отримує ICE-кандидати і скидає виклик по таймауту.
- Проблема не в коді, а в інфраструктурі.

Що зробив:

✔️ Описав у Confluence flow з Wireshark, TLS і Janus логами
✔️ Залив export пари зламаних дзвінків
✔️ Написав devops команді, відкрили порт — і все запрацювало.

А дзвінки пішли, як по маслу.

Висновок:
Буває, що одна дрібна деталь в інфрі — і все сиплеться. Але коли маєш під рукою Wireshark, Janus API і уважність — навіть найпідступніший drop не проскочить.

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

Всім доброго ранку - з 1 Травня ☀️

🌅 Ранкова історія QA #8
1 травня. Четвер. Вихідний. Але мозок QA думає інакше.

Прокидаюсь, як завжди, по будильнику.
На автопілоті — душ, кава, відкрив ноут, увімкнув тунель.
Зайшов у пошту, відповів на пару листів, відкрив Confluence, щось глянув, подумки вже прикинув, які задачі сьогодні закрию.

Сиджу хвилин 40, готуюсь писати деву в Группу…
і тут:
“Стоп… а сьогодні ж вихідний!”

Смішно, але реально не усвідомлював.
Просто мозок включився в QA-режим — і понеслося.
Зробив ще одну каву, закрив тунель і пішов нарешті вихіднювати 😄

QA-режим — це коли ти живеш по спринту, а не по календарю.

У кого теж таке траплялось — пишіть в коменти.
Ми вас не осудимо. Ми самі такі.

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

Цікава статистика
Правильну відповідь дали всього 15% — значить, тема реально не з простих.
Давайте я поясню по-простому . Якщо залишаться питання — пишіть у коментарі, відповім

Що таке WebRTC (Web Real-Time Communication) — це технологія, яка дозволяє двом користувачам напряму через браузер передавати:

- відео,
- аудіо,
- файли
…і все це без серверів-посередників.

Наприклад:
Ти відкриваєш дзвінок у Google Meet, Zoom — і WebRTC встановлює прямий зв’язок між тобою і співрозмовником.

Але як браузери “знаходять” одне одного?
Тут починається магія STUN / TURN, бо просто так з'єднатись — не вийде.

Чому?
Бо більшість людей сидять за NAT (роутер, офісна мережа, Wi-Fi), або ще й за Firewall.
А це значить — ти "схований", тебе не видно ззовні.

Уявіть: ти в офісі, твій друг вдома. Кожен — за своїм Wi-Fi. Обидва — «сховані» за маршрутизаторами (це і є NAT). Щоб встановити пряме з'єднання, треба якось "виглянути з-за стінки". Тут на сцену виходять…

STUN (Session Traversal Utilities for NAT)
Це як сервіс, який каже: "Ось твоя зовнішня IP-адреса і порт, через які тебе можна знайти".
Потрібен, щоб браузери знали, як пробитися через NAT.
Він не передає медіа — лише допомагає встановити з'єднання.

Спробую поясни біль своїми словами
(Твій ноутбук зазвичай має внутрішню адресу типу 192.168.x.x, яку "зовні" не видно. Щоб WebRTC міг з'єднати тебе напряму з іншим учасником, потрібно дізнатись твою "зовнішню" адресу — ту, через яку ти виходиш в інтернет. STUN-сервер якраз і каже:
"Гей, ось твоя публічна адреса — користуйся!"

Якщо обидва користувачі нормально бачать зовнішню адресу — WebRTC з’єднує їх напряму. Без зайвих витрат.)

Аналогія: STUN — це як дати іншому свою адресу, щоб той знайшов тебе.

TURN (Traversal Using Relays around NAT)
Коли STUN не допомагає (жорсткий NAT або Firewall), використовується TURN.
Це ретранслятор, тобто медіа йде через спеціальний сервер.
Не напряму, а "в обхід".

Аналогія: TURN — це як передати лист не напряму другу, а через поштаря.

Також давайте розберемо ще 1 штуку
З чого WebRTC складається?
У WebRTC є три основні частини (API):

- getUserMedia() — дає доступ до твоєї камери і мікрофона.
- RTCPeerConnection — встановлює саме з'єднання між двома користувачами.
- RTCDataChannel — канал для обміну іншими даними (файли, текст тощо).

З чого почати тестувати якщо ви з таким стикнулися ?
Ось простий чеклист для старту:

- Перевір getUserMedia — чи працює камера і мікрофон.
- Увімкни chrome://webrtc-internals/ — побачиш всі події WebRTC у браузері.
- Фільтруй трафік у Wireshark — шукай stun, turn, rtp, ice.
- Подивись на тип ICE-з'єднання (relay/host/srflx) — воно показує, чи пішов STUN чи TURN.
- Перевір консоль: "ICE connection failed" часто означає проблему зі з'єднанням (наприклад, STUN не пройшов, TURN не налаштований).

Ну давайте також расскажу всеж чому не A/C чи D

A — WebRTC не поверх HTTPS. Він використовує UDP (SRTP/DTLS), а HTTPS може бути тільки в сторони сигналізації.

C — HLS/DASH — це серверний стрімінг, а WebRTC — живе двостороннє з’єднання між клієнтами. Зовсім різне.

D — WebRTC не використовує WebSocket напряму для передачі медіа. WebSocket — лише варіант сигналізації, але передача — через ICE-кандидати, STUN/TURN.


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