Тім тут є мій Instagram. https://www.instagram.com/bugordefect_life
Тут буде про КУа не “ідеальний”, а справжній.
Work. Coffee. Bugs. Emotions - думаю у кого не завжди є час почитати дописи або просто хоче шось корисно (може не завжди) то welcome

Всім привіт - як ваші вихідні?

https://www.getxray.app/blog/top-5-software-testing-trends-2026 - як же я згоден з 5 пунктом - на 2026 дійсно без стабільності/ секьюрності не куди.

Почитайте - не велика але цікаво почитати.

Що думаєте?

Всім гарного дня і настрою друзі

Обнімашки🤗

Доброго вечора!

Як кажуть сказав А кажи і Б продовжимо бо був час коли казала шо все ipv4 вмирає - але ні не вмирає поки є NAT і так багато хто з вас взагалі бачив на реально прикладі IPv6?

Протоколи для QA - IPv6

І так шо я маю вам сказати.

IPv6 - це не “якась нова штука на майбутнє”.
Він уже тут.
І дуже часто саме він пояснює баги типу: це типо через Wi-Fi не працює, через мобільний працює”, у одного клієнта ок, у іншого таймаут”
або “запит іде, але відповідь не повертається”

І виглядає це все як магія, поки не подивишся на IPv6.

Що таке IPv6? це принцепі не складно але не понятно)

IPv6 - це новий формат IP-адрес.
Довгий. Страшний. Але логічний.

Щось типо такого ви можете бачити.

2001:0db8:85a3:0000:0000:8a2e:0370:7334

він з’явився бо IPv4 закінчився. Фізично.
А IPv6 дає стільки адрес, що їх вистачить “на всіх і надовго”.

Чому це важливо для куа і ми з вами повинні в цьому шарити
Бо через IPv6 QA перестає дивуватися і починає розуміти:

- чому клієнт ходить не через IPv4, а напряму по IPv6
- чому firewall налаштований тільки під IPv4
- чому DNS віддає AAAA-record, а не A
- чому сервер “доступний”, але тільки з одних мереж
- чому NAT тут взагалі не працює (бо його може не бути)

По факту IPv6 = прямий маршрут без костилів.

Базові речі, які куа повинен знати (і так, це теж питають):

Як подивитись IPv6-адресу:

ip -6 a

або як подивитись IPv6-маршрути:

ip -6 route

Чи перевірити доступність по IPv6:

ping6 google.com

Трейс по IPv6:

traceroute -6 google.com

Перевірити, чи DNS віддає IPv6:

dig AAAA google.com

Чи як подивитись, чи сервіс слухає IPv6:

ss -lntp | grep :::443

І тут починається магія (але вже контрольована)

Після цього ви вже розумієте що
- клієнт іде по IPv6, а сервер слухає тільки IPv4
- firewall пропускає IPv4, але блокує IPv6
- DNS віддає AAAA, а бекенд не готовий
- балансер не підтримує IPv6
- різні мережі = різні протоколи = різні баги

Це вже не “у когось працює, у когось ні”.
Це чітка причина.

Що я хочу до вас донести, друзі 🙂

QA не зобов’язаний будувати IPv6-мережі.
Але QA зобов’язаний знати, що IPv6 існує і як він впливає.

Бо зараз дуже багато багів - це не код.
Це маршрут.

І якщо ви не дивитесь у сторону IPv6 -
ви бачите лише половину картини.

Всім стабільних конектів,
без “а чого тільки в одного клієнта не працює”
Обняв 🤗
Сильні💛

Доброго раночку друзі) як ваш ранок?

У мене 2 кава з ранку - вихід на роботу після відпустки це особий день - коли на пошті 10000000...... лестів які ти будеш переглядати до вечора

А ще купа питань бо ти був у відпусці і вони є)

на відео це я 2 дні підряд поки не розгребусь після відпустки

А як у вас? теж таке?

Всім гарного дня і настрою)
Обняв 🤗🤗🤗

Друзі привіт - як ви? як ваші робочі дні після вихідних?

Я зліг з грипом групи (А) - це прям тяжко оказалоссь(

Тут Сидів пив чай від температут на обіді - то попав на таку статью - https://medium.com/@higor.mesquita/celebrating-small-wins-why-every-bug-fixed-matters-5ada3f17c7a8

Прикольно автор пише - що думаєте про його ідею??

Всім гарного вечора🤗
Сильні💛💛💛

Доброго вечора, друзі)

Все хотів вам дати цей тул то забуваю постійно - ссьогодні попав опять то думаю треба написати то опять забуду)

Що я маю вам сказать)
Є один дуже серйозний і водночас корисний тул - sqlmap
https://github.com/sqlmapproject/sqlmap

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

По суті це sqlmap сам бере параметр (query / body),
пробує різні payload-и
і каже вам прямо: тут ок або тут потенційна діра чи тут взагалі біда

Ставиться максимально просто:

git clone https://github.com/sqlmapproject/sqlmap.git
cd sqlmap
python sqlmap.py -h

Або якщо вже є Python: можете через таку

python sqlmap.py -u "https://test-api.com/users?id=5"

Для API це взагалі маст: login/ search / filters / sorting / pagination

Все, де є user input - зона ризику.

Важливий момент (і це прям принципово):
sqlmap використовуємо тільки
- на тестових середовищах
- або з офіційним дозволом

Для КУА це дуже сильний буст:
ви починаєте дивитись на API не тільки як “200 / 400”,
а як на поверхню атаки.
І баги з “minor” раптом стають “security critical”.

Коротше, якщо тестуєте API і ще не крутили sqlmap -
дуже рекомендую хоча б розібратись, як воно працює.


Всім гарного вечора
Обняв🤗

Друзі, привіт. Як ваш день?
Продовжуємо рубрику, де QA перестає вірити “на слово” і починає розуміти, що реально відбувається в мережі.

Протоколи для QA - STUN

Що я маю вам сказать.
STUN - це той самий протокол, про який згадують тільки тоді, коли дзвінки не дзвонять, відео не стартує, а WebRTC “чомусь не працює”.

STUN (Session Traversal Utilities for NAT) - це спосіб для клієнта зрозуміти: яка в мене зовнішня IP або через який порт я виходжу чи я взагалі доступний ззовні

Якщо прям супер просто то
STUN допомагає клієнту сказати серверу:
«Ось як я виглядаю в інтернеті, а не в себе вдома за роутером».

Бо 90% проблем у WebRTC виглядають однаково: я думаю ви і сами на таке натрапляли коли чорний екран/ нема аудіо/ камера “німа”/ reconnect без кінця

І дуже часто це не баг ЮА і не бекенд а це NAT + STUN.

Виглядає в реальності це саме так
Клієнт відправляє STUN-запит на STUN-сервер
Сервер відповідає:
- типо твій public IP такий
- а ось твій public port такий

І вже з цим WebRTC пробує побудувати пряме з’єднання.

Якщо STUN не працює: то WebRTC навіть не стартує ну і ICE-кандидати не формуються і далі хоч 100 разів refresh - нічого не буде

Дуже типові баги, які насправді STUN: і на які ви точно потряплали це
- працює в офісі, не працює вдома
- працює через Wi-Fi, не працює через мобільну мережу
- працює у девів, не працює у клієнтів
- після VPN все ламається

Куа повинен хотяб мінімум знати як такі базові речі перевірити

Подивитись STUN-трафік у Wireshark:

stun

Або разом з WebRTC:

stun  turn  rtp || rtcp

Перевірити, чи взагалі йдуть STUN-запити:
- якщо їх нема → WebRTC навіть не стартував
- якщо є, але нема відповіді → мережа або firewall

Знати стандартні STUN-сервери (для тестів):

- stun.l.google.com:19302
- stun1.l.google.com:19302

Що я хочу донести
STUN - це не “щось для девів”.
Це базова частина діагностики real-time систем.

Без STUN:
КУА бачить “не працює”.
З STUN:
КУА бачить чому не працює.

І в цей момент ви вже не просто QA,
а людина, яка реально розуміє мережу.

Всім гарного дня і настрою)
Сильні 💛💛💛

Друзі привіт - як ви?
Спродіваюсь шо ви та ваші близки в безпеці.

Там є на непогана вакансія на наш ринок - для людей які шукають роботу і для старту саме то - і так то шо пишуть 1 рік досвіду або купа скелів які ви типо не знаєте - подавайтесь як я казав і кажу своїм учням це просто шаблон)

https://jobs.dou.ua/companies/rozetka-ua-internet-supermarket/vacancies/339265/

Всім гарного дня!
Сильні 💛💛💛

Друзі, привіт! Як ваші вихідні - я вже вийшов з лікарняного то повертаюсь до роботи)

І зразу добрався до розбору цього пула - і це прямо улюблена класика для QA + security.

Отже, що маємо:
API /login повертає 200 OK з неправильним паролем.
І тут починається найцікавіше)

Чому не (A) “чи не закешувався запит”
Кеш для /login - це антипатерн, але теоретично може бути неправильний кеш на рівні проксі/CDN. Проте це менш імовірно, ніж логіка/ін’єкція, і точно не перша гіпотеза
Якщо API реально кешує /login, то це вже окремий серйозний баг, але це не перше, що перевіряємо.

Чому не (B) “логи бекенду”
Логи це реально важливо, але це другий крок.
Куа спочатку має зрозуміти тип проблеми, а вже потім іти в логи.
Без гіпотези логи, це просто чорна діра на пів години.

Чому не (D) “UI-валідація”
Ми тестуємо API.
UI тут взагалі ні при чому.
Навіть ідеальна UI-валідація не врятує, якщо бекенд приймає будь-що.

І чому правильна відповідь (C) - SQL-інʼєкція
Бо це критичний security-сигнал.
Класика жанру:
' OR '1'='1

Якщо пароль підставляється в SQL без параметризації, бекенд може: ігнорувати пароль або повертати першого юзера завжди логінити з 200 OK

І це вже не просто баг - це security vulnerability.

Що я хочу вам сказати) Якщо: пароль неправильний але API каже 200 OK, це не “дивна логіка”, це потенційна вразливість

І саме тут куа перестає бути “клікером”
і стає людиною, яка реально захищає продукт.

Хто обрав (C) - мислите правильно.
Хто ні - тепер знає, де копати наступного разу.

Всім гарного дня і безпечних логінів)

Обняв 🤗🤗🤗

Доброго вечора, друзі)

Постійно питають шото за пайтой - ти же автоматизуєшь - так я пишу на пайтоне але для себе, спрошую для себе мануальну роботу)
Так ось пару днів назад побачив прикольну штуку на пайтон - думаю буде вам корисно)

Що я маю вам сказать)

Є один дуже цікавий і недооцінений тул - Pinkerton
https://github.com/0xdsm/Pinkerton

Це інструмент, який шукає секрети прямо у фронтенді:
API keys, токени, паролі, auth-штуки, які випадково (або не дуже) потрапили в JavaScript.

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

По суті як воно працює: тул проходиться по сайту і парсить JS файли а потім шукає патерни ключів, токенів, конфігів і показує конкретно: що, де і в якому файлі. Без “може”, без гадання.

Ну поставити просто як і завжди)

git clone https://github.com/0xdsm/Pinkerton.git
cd Pinkerton
pip3 install -r requirements.txt
python3 main.py -u https://example.com

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

Для КУА це прям сильна штука:
ви починаєте дивитись на фронт не тільки як на UI,
а як на потенційну поверхню витоку.

Особливо актуально для: SPA/ Web-клієнтів / API, які викликаються з браузера/ проєктів, де “ключ просто для фронта” (спойлер: так не буває)

Важливий момент: свої проєкти, тестові середовища ну або з офіційним дозволом

якщо ви тестуєте web / API і ще не дивились, що реально лежить у JS -👀

Всім гарного дня)
Обняв 🤗

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

Це я тількі закінчів) З 9 по 21 - Нормально)

Знаєте я та людина яка каже своїм та всім - питайте питайте питайте і ше раз питайте - Але буває таке шо іноді цей малюк на відео це я))

Буваю у вас таке шо вроді все ок але коли 10 раз одно і теж буває чучуть починаєшь нервувати?)

Всім гарного вечора а головне спокійного)
Обняв🤗
Сильні 💛

Друзі привіт - як ваш день?

Чучуть поговоримо про протоколи?

Протоколи для QA - IPsec

Що я маю вам сказать.
Поговоримо сьогодні про IPsec - це не “ще один протокол”.
Це рівень безпеки для мережі, а не для апки.

IPsec = захищений тунель між мережами або хостами.
Не HTTP, не API, не UI - а саме IP-рівень.

Його ви зустрічаєте там, де: VPN між офісами, доступ до внутрішніх сервісів, або прод працює, а локально “не конектиться” чи API відкривається тільки з певної мережі

І тут КУА дуже часто впирається в стіну.
Тут дуже важливо зрозуміти КУА що IPsec працює нижче, ніж: HTTP/ HTTPS/ TCP і навіть firewall rules апки

Тобто:
якщо IPsec не піднявся - ніякий curl, Postman і “перезапусти сервіс” не допоможуть.

Типові симптоми IPsec-проблем, з офісу все працює, з дому - ні(і ви точно таке бачили) або ping не йде, але DNS резолвиться чи timeout без логів у бекенді даже сервіс “живий”, але недоступний або API доступний тільки через VPN

І це не баг бекенду.
Це мережа.

Шо ви як куа можете і повині перевірити в тому чи іншому випадку)

Подивитись, чи є IPsec-тунель:

ipsec status

Або (залежить від реалізації):

ip xfrm state

Чи є маршрути через тунель:

ip route

Чи йде трафік взагалі:

ping internal-ip

Перевірити, що трафік шифрується:

tcpdump -i any esp

(ESP = Encapsulating Security Payload - серце IPsec)

це must-have для QA - Бо без розуміння IPsec QA: валить баги “не працює”, чує від інфри “це не до нас”, і не може довести, де саме проблема

А з розумінням - ви чітко кажете: тунель не піднявся, або маршрут не пішов через IPsec, або трафік блочиться ще до сервісу

куа не зобов’язаний його налаштовувати.
Але зобов’язаний розуміти, коли проблема саме там.

Бо інакше половина “дивних” багів так і залишаться магією.

Всім стабільних тунелів і мінімум таймаутів.
Обняв🤗

Доброго вечора друзі - Так тут є запит від колег(підписників) про ютуб

Про розбір мережі(протоколів тощо) в форматі короткого відео на ютуб

Буде цікаво? я думаю це буде цікаво але це гарний кусок роботи для мене) якщо дісно це корисно буде то буду робити)

То в коментарі може напишіть + серденько по більше)

Обняв🤗