Всім привіт - для вас 15 потужних безкоштовних інструментів для QA 🚀
🔹 Playwright (США)
Швидке кросбраузерне E2E-тестування. Підтримує Chrome, Firefox, Safari. Ідеально для UI-тестів і інтеграції у CI/CD пайплайни.

🔹 Selenium (США)
Легенда автоматизації. Підтримка багатьох мов (Java, Python, C#, JS), тестування у реальних браузерах та хмарних сервісах.

🔹 Cypress (США)
Інтуїтивний JavaScript-фреймворк для тестування вебдодатків. Пише тести прямо у браузері, швидкий рантайм і стабільність.

🔹 Katalon Studio (Community Edition) (США)
Готовий набір для автоматизації веб, API та мобільного тестування. Мінімум налаштувань — максимум можливостей.

🔹 TestProject (Ізраїль)
Платформа для запису і запуску автоматичних тестів без коду. Інтеграція із CI/CD, спільнота плагінів, хмарне збереження.

🔹 Appium (США)
Кросплатформне тестування мобільних додатків для iOS та Android. Підтримує нативні, гібридні та вебдодатки.

🔹 JMeter (США)
Класика для навантажувального тестування. Створення сценаріїв тестування вебсайтів, API, баз даних та серверів.

🔹 Rest Assured (Швеція)
Фреймворк на Java для легкого тестування REST API. Простий синтаксис для складних сценаріїв перевірки запитів і відповідей.

🔹 Postman CLI & Collection Runner (США)
Потужний інструмент для тестування API. Дозволяє запускати тести через термінал, інтегрувати в CI/CD та автоматизувати регресію.

🔹 Robot Framework (Фінляндія)
Фреймворк із ключовими словами для автоматизації тестування. Підходить для Acceptance Testing, API, UI, DevOps задач.

🔹 Gauge (США)
Тести у форматі Markdown. Легке налаштування, підтримка мультиплатформності та чудова читабельність тест-кейсів.

🔹 Taiko (США)
Сучасний інструмент для стабільного браузерного тестування. Мінімум флейків, прості API для інтеграції з CI/CD.

🔹 Pact (Австралія)
Контрактне тестування для мікросервісів і API. Перевірка сумісності сервісів до релізу — мінімізація багів у продакшені.

🔹 TestNG (США)
Потужний тестовий фреймворк для Java. Підтримує параметризацію тестів, групування, паралельне виконання та гнучкі репорти.

🔹 ZAP (OWASP) (США)
Інструмент для сканування вразливостей у вебдодатках. Автоматичні перевірки безпеки, інтеграція у пайплайни DevSecOps.

Всі інструменти open-source і доступні для вільного використання!

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

Ранкові історії QA #4: “Недільний релакс”

Прокидаєшся в неділю з думкою:
"Сьогодні тільки Family, кава і абсолютний чіл."
Але доля така:
Ти не просто QA Team Lead. Ти ще й ментор.
І вчора ввечері тобі прилетіло 10 000 домашок на перевірку.
Кава в руку, ноутбук на коліна, режим "Let's goooo!" увімкнено.
Чіл відкладається. Починається QA-марафон.

Мораль:
У нас немає вихідних. Є просто інша форма баг-трекінгу. 😄

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

🛠 Вечірня історія з технічним присмаком: Вебсокети і магія 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