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

🔍 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

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

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

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

☀️ Ранкові історії 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