Bug or Defect?

Доброго вечора)Хочу трошки доповнити по протоколам по яким ми вже пройшлись в Протоколи для QA, коротенько але я думаю змістовно)я вже розбирав купу протоколів: такі як типо HTTP/REST, WebSocket, TCP, UDP, gRPC, IPv4/IPv6. Тобто як це працює плюс-мінус зрозуміло. Але дуже часто КУА зупиняється на цьому і не дивиться на другу критичну частину, поведінку і швидкість.протокол сам по собі не робить систему швидкою або повільною, але він напряму впливає на latency, навантаження і стабільність. REST часто виглядає “повільним” не тому, що він поганий, а тому що кожен запит, це окремий хттп виклик, зайві хедери, JSON-пейлоад і повторні handshake. WebSocket швидший не через якусь магію, а тому що з’єднання постійне і немає зайвих переговорів на кожне повідомлення. gRPC дає кращі цифри, бо бінарний формат, HTTP/2 і multiplexing.Для КУА тут ключове не питання “який протокол кращий”, а питання чи відповідає він задачі. Бо дуже часто “повільний бекенд” або “лаги”, це не баг у коді, а невдалий вибір протоколу, зайвий payload або неправильна модель обміну даними.І ось тут ви не просто “довго відповідає”, а “ця логіка не підходить для REST”, “тут потрібен стрімінг”, “тут краще event-based підхід”. Саме це і показує відео а не бенчмарки, а поведінку під різні сценарії.тобто тепер вчимося дивитись, як вони поводяться в реальних умовах. І це вже не про кліки, а про системне мислення)Всім гарного вечора і настрою🤗

Привіт, друзі. Як ви?Сподіваюсь, у вас і у ваших близьких все ок і ви в безпеці.Я поки трохи в завалі, команда хворіє, задачі ніхто не відміняв, тож тягнемо як можемо. Думаю, багатьом це знайомо)Сьогодні хочу кинути вам ще одну дуже правильну штуку, яку варто просто зберегти собі - навіть якщо зараз не юзаєте.Awesome Incident Response - https://github.com/meirwah/awesome-incident-responseВсі хто в темі по безпеці або хто туди дивиться і прямує то це для вам точно це велика, добре зібрана колекція всього, що стосується інцидентів, коли “щось пішло не так”.Не теорія і не “курси”, а реальні інструменти, підходи і ресурси типо як реагувати на security-інциденти або як збирати докази і логи - які тулзи юзати для аналізукороче прикольна штука я ше сам не все розумію але треба час) Навіть якщо ви не сек’юріті і не blue team - цей репо дуже добре прокачує голову:ви починаєте дивитись на систему не тільки як на фічі, а як на ризики і наслідки.Збережіть. Колись точно подякуєте собі.Всім гарного дня і настрою) Сильні 💛

Доброго вечора, друзі. Ну як ваш день?Натрапив сьогодні на цікаву статтю - ну прям дуже в тему того, що зараз відбувається з SQL і AI:https://highload.tech/uk/google-vypuskaye-funktsiyu-yaka-dozvolyt-pysaty-sql-zapyty-za-dopomogoyu-zvychajnogo-tekstu/І от що я для себе ще раз зафіксував.Коли я останнім часом веду заняття по SQL, то реально все рідше роблю акцент на “напиши ось такий SELECT / JOIN”.Бо давайте чесно - сьогодні будь-який SQL-запит може написати ШІ. І Google це офіційно підтверджує своїми фічами.Але є велике “але”.ШІ може згенерити запит.А пояснити, як він працює - ні, якщо ти сам цього не розумієш.І саме тут починається різниця між:“я знаю SQL” і “я розумію, що робить цей запит з базою”.Бо в реальній роботі (особливо для QA) чому цей JOIN ламає перформанс, чому WHERE фільтрує не так, як очікували, чому запит повертає зайві або пусті дані або чому після релізу все стало повільноце все не про синтаксис, а про розуміння логіки, індексів, порядку виконання, взаємодії з даними.І чим більше AI спрощує написання SQL, тим ціннішим стає розуміння, а не “зубріння”.Для мене ця стаття ще один сигнал: шо SQL нікуди не дівається, але роль людини зміщується з “написати” → “зрозуміти й перевірити”.Особливо для КУА - бо ми ті, хто має побачити, де логіка працює не так, навіть якщо запит виглядає “правильним”.Почитайте статтю.Дуже цікаво почути вашу думку:це плюс для професії чи початок кінця “класичного” SQL?Обговоримо Обняв🤗

Друзі, всім доброго раночку? як ви? Поки є час хотів розібрати для вас цьй пула - я думаю така штука була і є знайома багатьом)Шо я маю вам сказать.Чому не (A) Кеш - це завжди така спокуса, але це не перший крок.Якщо фікс реально не потрапив у гілку, хоч заочищайся - нічого не зміниться.Кеш перевіряють, коли вже впевнені, що код там є.Чому не (B) Деплой важливий, але знову ж - другий крок.Бо деплоїти можна що завгодно, якщо в target-branch немає самого фіксу.Чому не (D) Права доступу тут взагалі ні до чого.Коміт є, дев його бачить - значить доступ є.Проблема не в доступах, а в процесі.І чому правильна відповідь - (C)Бо коміт може існувати в feature-branch але без PR він не потрапляє в target а без мерджа - змін у target просто немаєЦе дуже частий кейс:“Я зафіксив” = є комітале“Я замерджив” ≠ реально замерджив)Поінт дісйно просстий КУА перевіряє не слова, а факти: є PR?, є merge?, є коміт у target-branch?Якщо ні - фіксу в білді не існує, навіть якщо він “десь є”.Хто вгадав(знав) - респект, мислите правильно.Хто ні - тепер знаєте, з чого починати такі перевірки.Всім гарного дня і поменше “ой, я забув замерджити” ) Обняв🤗🤗🤗Сильні 💛💛💛

Доброго дня, друзі!Раз уже зачепили IPv4 / IPv6 - логічно йти далі. Бо поки існує NAT, IPv4 точно ще поживе )Протоколи для QA - NATЩо я маю вам сказать.NAT - це та сама магія, завдяки якій у вас вдома, в офісі і в половини світу все ще працює IPv4, хоча адрес давно не вистачає.NAT якшо повністью і я не помеляюсь то це (Network Address Translation) - це коли багато внутрішніх пристроїв сидять за однією зовнішньою IP-адресою.Світ бачить один IP, а всередині - цілий зоопарк: ноут, телефон, тестовий сервер, Docker, VM.І от тут починаються ті самі “дивні” QA-баги.І чому саме КУА тут причому)Бо NAT дуже часто пояснює кейси типу:- “у мене працює, у клієнта ні”- “через VPN ок, без VPN - таймаут”- “з мобільного не працює, з Wi-Fi працює”- “сервер бачить всі запити з одного IP”- “callback не доходить”якщо по факту:NAT ламає ілюзію прямого з’єднання.і що саме відбувається умовно клієнт має приватну IP (192.168.x.x / 10.x.x.x) і NAT міняє її на одну публічну далі сервер відповідає не “тобі”, а через NAT назад, якщо щось у цьому ланцюжку не так - привіт таймаутиОсобливо боляче NAT б’є по: WebSocket / VoIP / WebRTC/ callbacks / webhooks чи rate limit по IP. security-логіці “1 IP = 1 user”Класика коли “Ми обмежили 5 запитів з IP”А потім - весь офіс сидить за одним NAT) Дам вам пару базових речей Подивитись свою публічну IP:curl ifconfig.me Подивитись локальну:ip a Зрозуміти, чи є NAT:локальна IP ≠ публічна IP → NAT єПеревірити, як сервер бачить клієнта:логиX-Forwarded-ForX-Real-IP І тут важливий моментДля IPv6 NAT може взагалі не бути.І саме тому: що через IPv6 працює, через IPv4 + NAT - ніІ це не баг коду.Це маршрут.Що я хочу до вас донестиQA не зобов’язаний налаштовувати NAT.Але QA зобов’язаний розуміти, що він є і що він робить.Бо дуже багато “дивних” проблем - це не бекенд, не фронт і не тест.Це NAT тихо стоїть посередині і ламає логіку.Всім стабільних конектіві поменше “а чого тільки з цього офісу не працює”ОбнявСильні 💛

Всім привіт! Як ваш день?Хочу поділитись штукою, яка мене реально здивувала.Це Claude Cowork - і це вже не просто “AI в чаті”.Реально це шось новеньке - може воно і де багато є але я в перше почув і побачив шо це, короче це AI, який живе у десктопному додатку Claude на macOS і працює як асистент по файлах. Реально як колега, а не як пошук.Він отримує доступ до вибраної папки на компі й може: читати файли або створювати нові чи ти кажешь та він редагує існуючі або збирати дані з кількох документ і робити звіти, таблиці, summariesУмовно ви не кажете “зроби крок 1, крок 2”.а ви кажете мету, а він сам думає, як до неї дійти.як приклад “Збери всі результати тестів у звіт”або“Наведи порядок у цій папці з логами”І він реально це робить.Реально виглядає шо це діє: працює з файлами, структурою, контекстом на твоєму компі.Не знаю як ви але я відношусь до тих людей у якого 3 моніка але у на кожному бардаш шо нема нового місця для новой папочки)) - думаю може він мені допоможе)реально це research preview, поки що тільки macOS і для Claude Max. але чекаємо шо буде далі) https://www.anthropic.com/claudeВсім гарного дняОбняв🤗🤗🤗

Друзі привіт - як ваш день? Чучуть поговоримо про протоколи? Протоколи для 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, або трафік блочиться ще до сервісукуа не зобов’язаний його налаштовувати.Але зобов’язаний розуміти, коли проблема саме там.Бо інакше половина “дивних” багів так і залишаться магією.Всім стабільних тунелів і мінімум таймаутів.Обняв🤗

Доброго вечора, друзі)Постійно питають шото за пайтой - ти же автоматизуєшь - так я пишу на пайтоне але для себе, спрошую для себе мануальну роботу) Так ось пару днів назад побачив прикольну штуку на пайтон - думаю буде вам корисно) Що я маю вам сказать)Є один дуже цікавий і недооцінений тул - Pinkertonhttps://github.com/0xdsm/PinkertonЦе інструмент, який шукає секрети прямо у фронтенді:API keys, токени, паролі, auth-штуки, які випадково (або не дуже) потрапили в JavaScript.Це не “хакинг заради хакингу”.Це нормальний технічний тул, який показує:чи не світяться у вас в JS файлах речі, які взагалі не мали туди потрапити.По суті як воно працює: тул проходиться по сайту і парсить JS файли а потім шукає патерни ключів, токенів, конфігів і показує конкретно: що, де і в якому файлі. Без “може”, без гадання.Ну поставити просто як і завжди)git clone https://github.com/0xdsm/Pinkerton.gitcd Pinkertonpip3 install -r requirements.txtpython3 main.py -u https://example.com І далі ви вже бачите, що реально лежить у публічних скриптах.Для КУА це прям сильна штука:ви починаєте дивитись на фронт не тільки як на UI,а як на потенційну поверхню витоку.Особливо актуально для: SPA/ Web-клієнтів / API, які викликаються з браузера/ проєктів, де “ключ просто для фронта” (спойлер: так не буває)Важливий момент: свої проєкти, тестові середовища ну або з офіційним дозволомякщо ви тестуєте web / API і ще не дивились, що реально лежить у JS -👀Всім гарного дня)Обняв 🤗

Друзі, привіт! Як ваші вихідні - я вже вийшов з лікарняного то повертаюсь до роботи) І зразу добрався до розбору цього пула - і це прямо улюблена класика для 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) - мислите правильно.Хто ні - тепер знає, де копати наступного разу.Всім гарного дня і безпечних логінів)Обняв 🤗🤗🤗

Друзі, привіт. Як ваш день?Продовжуємо рубрику, де 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,а людина, яка реально розуміє мережу.Всім гарного дня і настрою)Сильні 💛💛💛