🌙 Вечірня історія 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

Є ідея, яка не дає спокою…
Скоро на каналі — нова рубрика, яка може стати твоїм улюбленим форматом.

Всім гарного вечора 😊

Всім доброго ранку — і гарної робочої п’ятниці перед вихідними! ☀️

☀️ Ранкові історії QA #9 ☀️

Коли у тебе другий день вихідного у відпустці...
…і ти точно памʼятаєш:
— задачі роздані ✅
— регрес стартував ✅
— всі on-call попереджені ✅
— Chat мовчить, Jira не світиться, ніхто не пише

А ти сидиш з кавою і думаєш:

«Може, одним оком в пайплайн глянути?..»
«А якщо тест впав, а ніхто не побачив?..»
«А як так йде прогон тест кейсів? 👀»

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


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


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

Привіт
Якщо ти такий же QA-параноїк, як і я…

…і бачиш у логах підозрілий IP ☠️
…і думаєш: “А ну його швиденько засканити, може це бот, криптомайнер чи просто dev з Франкфурта”
…і тобі не хочеться вручну відкривати 20 вкладок з VirusTotal, AbuseIPDB, Shodan

Mitaka — must-have розширення для OSINT і QA-шників, які шукають трохи більше

Mitaka — розширення для Chrome/Firefox, яке:
— Працює прямо з контекстного меню
— Підтримує понад 70 OSINT-джерел (VirusTotal, Shodan, Hybrid Analysis, тощо)
— Працює миттєво: виділив → клік → аналіз пішов

Базові Юзкейси які можно спробувати хоть зараз)
- Тестиш WebRTC/SIP — перевір IP через Shodan
- Підозрілий URL у логах? Пробивай на VirusTotal
- Хеш невідомого файлу? Освітли його з усіх боків

Безкоштовне і просте, як фільтр в Postman.
Ідеально для QA, і просто параноїків 🙃

🫠Як кажуть, Бо краще перебдеть, ніж недобдеть.

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

15 must-know інструментів для тестування в 2025
(усі безкоштовні та open-source)

1. Playwright – дуже швидке кросбраузерне E2E тестування.

2. Selenium – перевірена класика автоматизації з підтримкою Java, Python, JS та інших мов.

3. Katalon Studio (Community Edition) – легкий старт, багатий функціонал, зручна UI-обгортка.

4. TestProject – хмарна платформа з підтримкою AI та активною спільнотою.

5. Appium – must-have для автоматизації мобільних додатків (Android/iOS).

6. JMeter – для перевірки продуктивності, навантаження, скрипти без коду.

7. Rest Assured – Java DSL для тестування API — гнучко та зрозуміло.

8. Postman CLI & Collection Runner – зручне API тестування, що легко інтегрується в CI/CD.

9. Robot Framework – keyword-driven, читабельний синтаксис, зручно для команди.

10. Gauge – від творців Taiko, хороша підтримка markdown-специфікацій.

11. Taiko – сучасний тулинг для браузерної автоматизації з мінімумом “флаків”.

12. ZAP (OWASP) – обов’язковий тул для базового тестування безпеки вебдодатків.

13. Cypress – швидке JS-орієнтоване тестування UI, популярне серед фронтендерів.

14. TestCafe – ще одна JS-опція, мінімально залежить від браузера.

15. Nightwatch.js – просте рішення для E2E тестів, що легко інтегрується з CI.

Збережи собі, якщо тільки починаєш — і обирай те, що підходить до твого проєкту!


#qa #тестування #automatedtesting #opensource #manualqa #testingtools

Всім доброго вечора

Як кажуть у Lead нема вихідних і відпусток - хоча це може тільки у мене

Вечірня рубки QA

QA-історія для тих, хто тільки починає
“Firefox — а чому все розсипалось?”

Увечері питаю команду:
— Як там UI, все ок?
— Так, усе добре.
— А у Firefox дивився?

...пауза...
Через 3 хвилини мені пишуть:

“Ти ше тут, тут якась дичина…”

Захожу — і бачу те, що бачать усі, хто вперше запускає макет у Firefox:
— Шрифт дивний,
— Тінь не там,
— Кнопка блимає,
— Щось не центрується, хоч мало б.

Чому так?
Бо всі часто перевіряють тільки в Chrome. А Firefox рендерить трохи інакше:

Бо движки у браузерів різні:
— Chrome (і Edge, і Opera) — працює на Blink (Chromium),
— Firefox — на Gecko.

Gecko жорсткіше дотримується специфікацій CSS. Він не “прощає” верстці такі речі як:
— відсутні -moz- префікси,
— невизначені font-family,
— box-shadow, що рендериться по-різному,
— кастомні елементи, що без fallbacks.

І особливо класика: line-height, letter-spacing або scrollbar, які рендеряться як в іншій опері.

Що робити?
-— Завжди перевіряй хоча б у Chrome + Firefox.
—- Використовуй CSS-резети або normalize.css.
—- Якщо щось не так — відкрий Firefox DevTools і дивись вкладку "Computed", вона покаже, що реально рендеритьс, + ексепшени в консолі

Порівнюй стиль елементів у Chrome і Firefox — шукай відмінності.

Маленький лайфхак:
У Chrome все красиво — не означає, що воно так і буде у користувача.
У Firefox — чесніше. Він покаже слабкі місця верстки.

Висновок:
Якщо тестиш тільки в Chrome — ти не тестиш.
Firefox — як суворий викладач. Завжди знайде, де болить.

Тому я завжди перевіряю в Gecko. Бо люблю дизайн… і спати спокійно.

Це вам як бонус де можно дивитися статистики хто шо і де юзають і скільки https://gs.statcounter.com/

Підписуйся на BugOrDefect, якщо теж маєш Chrome, Firefox, Safari, і Edge "про всяк".

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

Усім доброго ранку — Усім гарного настрою☀️
☀️ Ранкові історії ☀️

Ранкова доза реальності для майбутніх QA ☕️
Пост для тих, хто боїться співбесід

Кожного разу, коли я веду QA-курси, я переконуюсь у простій речі:
📚 Сира теорія випаровується одразу після того, як закривається кришка ноутбука.

Вчора спілкувався з одним учнем.
Каже:
— Боюсь ходити на співбесіди...
— Чому?
— Теорія слабка, практики нема. Раптом спитають щось, а я — “ну я не впевнений...”

Я кажу: “Так і ходи! Саме заради цього й треба ходити.”

Запам’ятай
Ніхто не народжується з досвідом.

На кожній співбесіді ти здобуваєш практику.

Кожна "незручна відповідь" — це +1 до твоєї реальної підготовки.

Як готуватись без практики:
Йди на всі співбесіди, навіть якщо вимагають “рік досвіду”
— Це формальність. Якщо ти мотивований і можеш пояснити як ти тестуєш — це важливіше.

Після кожної співбесіди — роби рев’ю
— Запиши питання, де “поплив”.
— Розбери вдома.
— Повтори через день-два.

Створюй свою базу знань
— Це твоя персональна зброя: сценарії, SQL-запити, помилки, що питали, навіть приклади кейсів.

І головне — не сприймай відмову як поразку.
— Це просто ще один крок до тієї співбесіди, де ти скажеш: “Ого, я впорався!”

І Пам’ятай:
Страх співбесіди — це лише страх невідомого.
Але кожна наступна — робить тебе впевненішим, досвідченішим і ближчим до роботи.

Тому, Випив каву — подав резюме — пішов на співбесіду.
Навіть якщо не готовий — саме так ти станеш готовим.

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

Всім привіт!😊
Стосовно Вчорашньої Історіі)

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

Кросбраузерне тестування: не треба тестити всюди і все

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

Що треба знати: Браузери мають рушії (rendering engines)
Саме рушії вирішують, як виглядає сторінка, як працює JS, а не назва браузера.

Chrome, Edge, Opera — Blink (Chromium)

Safari — WebKit

Firefox — Gecko

Не тестимо всюди, тестимо з розумом
Якщо в Chrome усе виглядає добре — швидше за все, так само буде й в Edge або Opera (бо той самий двигун).
Safari — окрема історія, бо WebKit має свої приколи. Firefox — теж варто перевірити, хоча б базово.
Мінімум sanity-чек: Chrome + Safari + Firefox.

Головне — рушій, а не логотип браузера
Тестиш у Chrome — вже покрив майже всі Chromium-браузери.
Safari обов’язковий, бо в iOS усі браузери всередині — WebKit, навіть "Chrome для iOS".
Firefox — теж бажаний: його юзає меншина, але з ним бувають сюрпризи.

Нюанси — є завжди:

Safari іноді глючить з flex, grid, шрифтами чи анімаціями

Firefox може по-різному рендерити форми або svg

Chrome — стабільний, але теж треба моніторити консоль (warnings, errors)

Як зрозуміти, де тестити?

Дивись аналітику (Google Analytics, gs.statcounter тощо): які браузери реально юзає твоя аудиторія

Якщо 90% сидять у Chrome — не треба витрачати години на Opera

Є мобільна версія? Safari на iOS — must have, Chrome на Android — теж бажано

Що можу посоветовать в Help
Використовуй BrowserStack, LambdaTest або Sauce Labs
Або локально: Chrome DevTools (device emulation), віртуалки, емулятори

Не забудь про responsive-моди і скріншоти на різних breakpoint’ах

Висновок:
Тестувати треба з головою. Не треба ганяти кожну фічу в кожному браузері.
Дивись на рушії, аналізуй, пріоритезуй.
Safari та Firefox — обов’язкові для sanity. Інше — за потребою.

Бо QA — це не "все відкрити", а "знати, що має сенс перевірити".

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

Усім доброго ранку — Сонечка у віконце☀️
☀️ Ранкові історії ☀️

QA-недільна профдеформація

Було у вас таке?
Три дні релаксу, піченьки, Netflix, світ без Jira...
А потім десь у неділю з ранку мозок такий:
— «А може… ну тіпа… спринт спланувати?»
— «А гляну changelog, шо там наші в staging закинули...»
— «TestRail сам себе не заповнить…»

І ти вже не на дивані, а в голові клікаєш по Confluence-сторінках.
Наче й вихідний, а внутрішній QA вже на daily 😅

Або це тільки в мене така легка quality обсесія?

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

Всім привіт - Здивований статистикою відповідей)

Тоді давайте розберемо шо це коротенько і для чого.

Наприклад ситуація — з фронта відправляється форма або івент, і в полі, наприклад, назва, написано:
"Це круто & нова фіча"
або навіть типу:
"Ціна < 1000"

І тут починається магія — сервер падає, або дані не зберігаються, або бачиш “Parsing Failed”.
Чому?

Бо &, <, > — це спецсимволи для HTML або XML. Коли ти їх вставляєш у дані без кодування, парсер думає, що ти хочеш передати HTML-сущність.

Наприклад:   — це норм, бо це валідна сущність, тобто не розривний пробіл.
А от якщо ти просто написав & — сервер думає: “О, зараз буде сущність”, чекає далі, але не знаходить нічого валідного. У нього коротше паніка — “що це було?” — і він каже: “Parsing Error”.

Так само з < — парсер думає, що зараз почнеться тег типу <div>, але тег не закрився — значить, знову помилка.

А найсмішніше, що в JSON це не викликає проблем, а в XML або HTML — викликає.

Спитаєте а чому в Json OK!
У JSON проблеми з &, <, > самі по собі зазвичай не виникають, бо, JSON не сприймає ці символи як спецсимволи, &, <, > — у JSON це просто символи в рядку, ніякої сутності типу   він не чекає;

JSON не інтерпретує HTML або XML, тому не "плутається" від амперсанда чи кутових дужок.

АЛЕ! Проблеми можуть виникати пізніше, якщо:

Цей JSON десь вставляється у HTML без ескейпу — тоді браузер чи сервер може подумати, що це HTML.

JSON конвертується в XML або вставляється в XML-подібну структуру — і тоді вже & або < ламають усе.

Сервер неправильно обробляє символи (не декодує, не ескейпить), особливо якщо тип відповіді не application/json, а, скажімо, text/html.

Висновок:
У JSON — ок (поки ти з ним поводишся правильно).

Але у змішаних системах (JSON + HTML / XML / Markdown / Email шаблони) — починаються веселощі.

Що робити при тестувані QA?

— Тестуй вручну такі кейси: &, <, >, ", '
— Перевір, що фронт ескейпить спецсимволи (або навпаки — не ескейпить і це проблема)
— Перевір, що бекенд може їх парсити
— Не лінуйся — закинь такі значення в форму і подивись лог/відповідь
— І найголовніше — тестуй поля, які можуть містити текст від користувача: назви, коментарі, пошук, тощо

Бо інакше...
“Parsing Failed” в проді, нічосі не збереглось, юзер кричить, деви не розуміють шо сталося, а ти такий: “Я не тестив з амперсандом...

Чому це важливо для QA:
Якщо дані з цими символами не енкодяться при відправці — бек може їх не розпізнати.

Якщо бек їх не декодує — користувач побачить "сміття" типу &gt; замість >.

Це може зламати HTML-розмітку або XML-структуру — особливо в e-mail, PDF або звітах.

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

& → &amp;

< → &lt;

> → &gt;

" → &quot;

' → &apos;

  →   (нерозривний пробіл)

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