Bug or Defect?

Друзі, привіт! Як ваш день?

Добрався я до розбору наших пулів))
Сьогодні розберемо цей кейс і він реально часто трапляється після деплою, особливо коли маєш справу з контейнерами, NGINX і REST-запитами)

Чому не (A) - пошкоджений SSL?
Тут якби був битий сертифікат, то в логах було б видно “SSL handshake failed”, “certificate expired” або “bad PEM”.
А тут сервер взагалі не відповів, тобто він ще не встиг піднятись до стану ready.

Чому не (B) - CORS?
CORS-ошибка виглядає зовсім інакше.
Тоді REST відповів би 403 або 401, але не 503. Тут ми навіть не дійшли до CORS - запит просто не дочекався сервісу.

Чому не (C) - кеш браузера?
Якщо сервер не слухає порт, кеш не допоможе. Браузеру нема куди стукатись, тому він навіть не отримає респонсу.

Чому всеж (D)
Контейнер з NGINX або бекендом стартує, але ще не готовий приймати запити (порт не слухає).
У цей момент клієнт або frontend вже відправляє REST-запит - і отримує 503 Service Unavailable, бо NGINX ще не “прокинувся”.
Це реальн типова історія для Docker або Kubernetes - коли healthcheck ще не пройшов, але трафік уже пішов.

Як це можно перевірити? та принцепі не проблема
Подивіться docker logs або kubectl describe pod - чи встигає сервіс реально стартувати до того, як приходить запит.
У NGINX-логах буде connect() failed (111: Connection refused) - це і є знак, що порт ще не слухає.

Що я маю вам сказати
Це прям класика після деплою - коли все працює, але щось “іноді падає”.
А насправді просто REST побіг швидше, ніж NGINX встав на ноги )

Хто вгадав із першого разу то вам респект)
А хто ні, тепер точно не попадетесь на цей “сонний NGINX”

Всім гарного вечора, і настрою

Обняв🤗

Доброго ранку, друзі!
Як ви? Як ваші вихідні?

Слухайте, я за вихідні бачився з колегами і всі як один: AI, AI, 😅
І повагою до теми, але й з певним скепсисом.

Бо чому? - зараз ринок просто перевовнений джуніорами після курсів, і майже всі курси вже з інтеграцією AI:
як юзати, як питати, як писати промти, як задавати роль.

І це круто! І це треба знати
Але є один момент, і він критичний.
Якщо людина питає, але не розуміє, що саме питає - користі від AI майже нуль.

Так, AI може згенерувати тест-кейси, допомогти написати сценарій чи зробити SQL-запит.
Але якщо ви не розумієте, чому саме так, навіщо це потрібно і яку частину ви перевіряєте - результат буде пустий.
Без фундаменту і технічного розуміння все це - просто нажаль копіпаст.

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

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

Я трохи повернувся, тож готуйтеся - буду знову вас “діставати” постами)
Всім гарного дня і настрою!
Обійняв 💛💛💛

Привіт, друзі!
Як ви, як ранок, як кава сьогодні?

Слухайте, ви вже бачили цю штуку?
OpenAI викотив ChatGPT Atlas, свій власний браузер
Так, серйозно, тепер GPT прямо в середині браузера.

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

Тут типо сама презентація

https://openai.com/index/introducing-chatgpt-atlas/


Як вам таке? Хтось уже тестив?
Мені от цікаво, який у нього пошук є, свій GPT-івський чи все ж під капотом Bing.
Бо якщо свій - то це вже буде прям нова ера браузерів


Всіх обняв🤗🤗🤗

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

Що я сьогодні почитав - а вам раджу - найшов в одному з паблеків)
Поки всі говорять про “AI всюди”, от вам цікава свіжа стаття - як великі компанії (Google, GitHub, Microsoft, Monzo, Dropbox) реально міряють ефект від AI у розробці.

Виявляється, не все так просто - лінії коду не показують користь.
Вони дивляться на PR throughput, failure rate, quality, DX-метрики, навіть “bad developer days”)

Що я маю вам сказать - AI важливий, але міряти треба не скільки згенерував, а наскільки покращив роботу команди.

https://newsletter.pragmaticengineer.com/p/how-tech-companies-measure-the-impact-of-ai

Обняв 🤗🤗🤗

Доброго раночку друзі - як у вас настрій?

хочет квест з ранку? шоб після кавусі ще і мозок запустить?

А ну хто у нас є дев а може в душі дев? хто знає що це така за 1? аааа

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

Привіт друзі!
Як ваші вихідні, відпочили чи як завжди - тільки розігнався і вже понеділок? 😅

Ранкові історії QA
Давно не було історій, правда?
Так от, сьогодні поговоримо, як NGINX може поламати мозок навіть у понеділок зранку.

Короче, приходжу після вихідних - кавуся третя), ноут, Jenkins каже “pipeline passed”, життя прекрасне.
Думаю: перевірю тест, який залишив на вихідних.
Захожу в акаунт - і бац, історія пуста.
Немає логів, немає даних, ЮА мовчить як риба.

Окей, відкриваю DevTools → бачу REST 504 Gateway Timeout.
О, ну точно або бекенд лежить, або NGINX десь чудить.

Захожу на сервер, думаю треба подивитися логі, куди ж без них)

journalctl -u nginx.service -n 50

Ну і так і там класика жанру

connect() failed (111: Connection refused)

Думаю, цікаво, чому “refused”, якщо сервіс наче має піднятись автоматом.
Йдемо далі:

sudo systemctl status nginx

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

Ну окай думаю давай чучуть по глибще копнемо

dmesg | grep nginx

і тут все стало ясно: система запускає API ще до того, як NGINX підняв сокети.
В результаті - запит іде в нікуди, бо сервіс “в комі”.

Іншими словами гонка сервісів це біда( а це дуже і дуже чата проблема(
NGINX ще тільки каже “я в процесі запуску”, а REST уже біжить у продакшн)

Ну шо бага є)
щоб REST стартував тільки після того, як вебсервер реально живий.

Що я маю вам сказать з цього приводу)
Коли бачите “504 Gateway Timeout” - не спішіть тикати у девів)
Перевірте логи, сервіси, залежності запуску.
Бо іноді не баг, а просто NGINX ще не встиг випити кави)

Всім гарного тижня і спокійних деплоїв)
Хто ловив такі “післяребутні” приколи - діліться в коментарях, бо впевнений, я не один такий)

Обняв ☀️🤗🤗🤗
Сильні💛

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

Геймера приготуватися))
Що я маю вам сказать - чули вже про гру https://store.steampowered.com/app/2060160/The_Farmer_Was_Replaced/ і це не просто ферма
Тут ви реально вчитеся Python прямо через геймплей.

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

Якщо ви КУА, який хоче підтягнути Python для автоматизації - це реально прикольний і нетиповий спосіб почати.
Краще, ніж черговий тутор на YouTube 😄

Всім гарного ранку і продуктивного дня)

Доброго ранку друзі)

Як ви? Сподіваюсь ви і ваші близькі в безпеці)

Хочу побажати вам гарного настрою не зважаючи не на що)

А тут ще є 1 не погана вакансія може комусь зайде, то велком

https://knubisoft.com/vacancy/junior-strong-middle-low-qa-engineer-hybrid/

Обняв🤗🤗🤗
Сильні💛💛💛

Привіт друзі!

Ну що, поговоримо сьогодні про… лімони 🍋? Так-так, не жартую)

Чому я взагалі згадав про це? Бо це дуже крутий приклад того, як реальні користувачі можуть “протестувати” продукт краще, ніж будь-який скрипт чи мануальщик.

Ви просто Уявіть ситуацію: в додатку запускали кампанію збору “віртуальних лімонів” - з точки зору бізнесу це був івент, а з точки зору QA це стало… повноцінним регресійним тестуванням у проді.

Під час збору користувачі пройшли усі ключові флоу - логін, API-виклики, оновлення сторінок, роботу бази. Система отримала пікове навантаження - і це чудово перевірило бекенд і скейлінг. Спрацював навіть ефект манкі-тестування: користувачі натискали непередбачувано, створюючи кейси, до яких ми б самі не додумались.
І головне - це дало величезний масив реальних метрик і поведінкових сценаріїв без жодної ручної роботи.

Фактично, команда отримала “безкоштовне” тестування на проді, а користувачі навіть не здогадувалися, що вони частина КУА-процесу)

Ідея проста, але сильна: залучення реальних користувачів до бета-тесту або івентів може дати більше даних, ніж тисячі автотестів.

А тепер честно)
Назбирали собі??))


Всіх обняв)
Сильні 💙

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

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

Це тул під назвою Headerpwn - такий собі фазер, який перевіряє, як ваш сервер реагує на різні HTTP-заголовки. І повірте, це не така банальна штука, як здається.

Бо от ви тестуєте бекенд - все класно: POST, GET, статуси 200/400, response приходить як треба. Але... що буде, якщо заголовок трошки змінити? Додати нестандартний? Відправити зайвий? Саме тут і починаються цікаві історії)

Headerpwn якраз і створений для цього: він автоматично перебирає купу варіантів заголовків і дивиться, як сервер на це реагує.
- Чи впаде він?
- Чи поверне неочікуваний статус?
- або, можливо, “пропустить” запит повз авторизацію?

А ще він реально зручний для КУА легко інтегрується з Burp Suite, тому можна запускати все в одному інтерфейсі.

Принцепі все буде просто) написали = запустили)

headerpwn -url https://example.com -headers my_headers.txt

-url - ціль, яку тестуємо

-headers - файл зі списком заголовків, які будемо перебирати

Після запуску ви отримаєте повну картину реакції сервера на різні варіанти - і це реально допомагає знайти те, про що бекенд-розробник навіть не здогадувався.

Який поінт від мене
тест безпеки (чи можна обійти auth або CSRF-перевірку); пошук неправильних конфігурацій (наприклад, X-Forwarded-For або Content-Type можуть змінювати поведінку); аналіз edge-case сценаріїв ще до продакшену. це все про це)

https://github.com/devanshbatham/headerpwn - є даже дока)

Як на мене - це той тул, який не лежить “на кожен день”, але коли треба знайти щось нетипове чи нестандартне, то дуже виручає.
Ідеально, коли Dev каже: “Та ні, такого сценарію ніколи не буде” - а ти запускаєш Headerpwn і показуєш, що таки буде 😄

Якщо хочете - наступним постом покажу, які заголовки найчастіше “ламають” бекенд на проєктах?

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

Обняввв 🤗🤗🤗

Доброго ранку, друзі! Як ви, як ваші вихідні?

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

А тепер - каву в руку і вперед працювати на повну. Новий тиждень - нові задачі, нові виклики і нові результати.

Бажаю вам максимально продуктивного дня і правильного настрою.
Сильні 💪

Обережно на відео присутній МАТ

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

Як ви? як ваш тиждень і ваш настрій? Так чучуть пропав бо роботи дуже дуже і дуже багато, леть встигаю ше і людей треба вчити) Але чу-чуть відіхнете від мене ТАК???

Шо я маю вам сказать сьогодні)

я і обіцяв повернутись до теми плюшок у Python 3.14? я вже чучуть подивився, але не богато, ну що давайте сьогодні коротко, але по суті - чому цей реліз реально вартий вашої уваги навіть якщо ви не кодите щодня.

Я пишу на Python не так багато, але цей реліз мене прям порадував, бо він торкається речей, які КУА можуть знадобитись у реальних задачах: від написання скриптів для API-тестів до швидкого дебагу прямо в терміналі.

І так Free-Threaded Python - як кажуть прощавай GIL
Якщо колись вас бісило, що потоки в Python насправді працюють послідовно - забудьте. У 3.14 з’явилась експериментальна збірка без GIL (Global Interpreter Lock), тобто тепер вони можуть реально виконуватись паралельно.
Для нас це означає, що скрипти для навантаження чи паралельних API-тестів будуть працювати помітно швидше.

Як приклад

import threading

def worker(n):
    print(f"Running job {n}")

for i in range(10):
    threading.Thread(target=worker, args=(i,)).start()

У 3.14 це виконується паралельно як слід, без “очікування” черги.

Ну про це окремо так? t-рядки - тепер форматування як у людей
Дуже зручно для логів або генерації тестових даних:

name = "QA"
t"Hello {name}, welcome to testing world!"

Раніше треба було робити f"...", тепер - t"...", і вони не обчислюються одразу, що дає більше контролю під час побудови рядків.

REPL майже як міні-IDE
Якщо ви колись юзали python у терміналі для швидких перевірок - тепер це взагалі інший рівень. підсвічування синтаксису, автодоповнення при імпорті модулів, кастомні теми, зручні підказки при помилках ну не красота?

Я, наприклад, часто прямо в REPL тестую шматки коду з API або генерацію токенів - тепер це робити у 2-3 рази приємніше.

Ну і як же Новий модуль compression.zstd
Прямо з коробки можна стискати дані через Zstandard. Це корисно, якщо ви генеруєте великі репорти або хочете оптимізувати логування/експорти прямо у тестах.

import compression.zstd as zstd

data = b"Some QA logs" * 1000
compressed = zstd.compress(data)

Помилки, які тепер пояснюються як для людей
Якщо ви коли-небудь бачили SyntaxError і не могли зрозуміти, що не так - тепер Python сам підкаже, що ви, наприклад, забули двокрапку або переплутали ключове слово.

А нові можливості в exceptions теж варті уваги)

Можна писати простіше:

try:
    risky_func()
except ValueError, TypeError:
    ...
(якщо не використовуєте as)

Шо я хочу вам в принцепі сказать)

Ви можете писати легші утиліти для тестування без зайвих бібліотек. Легше дебажити API, логіку або дані в REPL., Тести на навантаження тепер реально багатопоточні.

А повідомлення про помилки - це мінус 15 хвилин на гугління кожного дня.

Я би сказав так: Python 3.14 - це не про революцію, це про комфорт. Але саме він робить маленькі скрипти для КУА більш професійними, а великі інструменти - більш стабільними.

Так що так)

НЕ ГУБУть мене, я тут)

Всім гарного дня і настрою друзі)
Всіх обняв🤗🤗🤗, Cильні 💛💛💛

І там ледь не забув сказати - пайтонводи, це для вас окремий меседж 😄

Ви вже бачили, що Python 3.14 офіційно релізнули? Якщо ще ні - обов’язково гляньте, бо там багато цікавих змін. Навіть якщо ви не пишете на Python щодня, як і я, - все одно кайфово спостерігати, як мова росте й полегшує життя нам КУА.

Світ Python стає кращим, і кожен реліз - це ще один крок до того, щоб писати код швидше, чистіше й з меншими болями. Якщо цікаво - можу зробити короткий технічний огляд того, що саме з’явилось нового у 3.14.

Хочете?

Друзі, доброго раночку)

Бажаю вам сьогодні гарного дня, легкого старту тижня і правильного настрою - хай задачі вирішуються швидко, а баги обходять стороною.

На відео, впевнений, кожен впізнає когось зі своїх девів 😄 - от саме так вони виглядають, коли бачать, що на них завели нову issue.

Всіх обняв, сильні як завжди 💪

Всім доброго ранку друзі☀️☀️☀️

Як ви? Як пройшли вихідні? Я вже на другій каві, бо тиждень обіцяє бути шалений - багато задач, зустрічей і роботи, але чесно кажучи, це приємно. Коли є чим займатись - час летить швидше і день проходить цікавіше.

Хотів ще сказати кілька слів про ваші повідомлення щодо курсів. Я бачу всіх і читаю всіх, але, на жаль, я один. Якщо набирати занадто багато людей, це буде не курс, а просто лекції з теорії - а мені хочеться давати вам практику, реальні кейси і корисні навички, які ви зможете застосувати на роботі. Тому не переживайте - усім відповім трохи згодом, і якщо у вас буде час і натхнення, ми обов’язково попрацюємо разом.

А поки - ось вам цікава стаття до ранкової кави:
https://blog.qatestlab.com/2025/09/10/when-ai-will-replace-manual-testers

Бажаю вам гарного початку тижня і продуктивного дня.
Обняв. 🤗🤗🤗

Друзі, привіт! Як ви? Сподіваюсь, що ви й ваші близькі в безпеці 💛

Сьогодні хочу поділитися з вами реальною знахідкою, яку випадково побачив в одному технічному пабліку - і вона прям мастхев для кожного QA, девелопера чи безпекаря

https://awesomeopensource.com/categories/security

Це величезна колекція open-source тулів для безпеки - від аналізу вразливостей і пентесту до сканерів мереж, захисту API, DevSecOps-рішень та інструментів для CI/CD.
Коротше - все, що треба, щоб підвищити рівень свого проєкту й перевіряти його не лише “на кнопочки”, а й на реальні ризики.

Я такі штуки завжди зберігаю під руку, бо вони реально допомагають, коли потрібно швидко щось перевірити чи підтягнути знання.

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

Всім гарного дня та гарного настрою ☀️
І пам’ятайте - п’ятниця це теж робочий день, але тільки до 17:00 )
Обняв 🤗

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

Сьогодні розбираємо дуже типовий, але підступний кейс - той самий “Too many redirects” після деплою через NGINX.
На перший погляд - нічого страшного, але коли бачиш це на проді в 2 ночі - одразу хочеться знайти винного (спойлер: часто це не дев, а конфіг).

Чому не (A) Проблема з SSL-сертифікатом
Якби би справа була у SSL, ви б побачили “SSL handshake failed” або “certificate verify failed”, а не безкінечні редіректи.
SSL тут ні до чого, він або працює, або ні. А от редіректи це логіка, не шифрування)

Чому не (D) Помилка у порті proxy_pass
Якщо був би неправильний порт, то запит просто не дійшов би - NGINX би повернув 502 Bad Gateway або connection refused.
А тут все навпаки: сайт живий, просто крутиться по колу)

І не зовсім (B) тільки NGINX редіректить http → https
Сам по собі такий редірект - нормальна практика.
Але коли і NGINX, і бекенд роблять однаковий редірект, то починається весела петля)

І чому саме правильна відповідь: C - подвійний редірект
Оце якраз той випадок, коли обидві сторони занадто старалися
NGINX каже: “Я тебе зараз гарно переведу на https”,
а бекенд каже: “О, я теж переведу, бо безпека понад усе!”
І все браузер біжить по колу, доки не здається

Виглядате це бути в логах шось типо такого
Client → http://ваш.com
↓ 301 Redirect
NGINX → https://ваш.com
↓ 301 Redirect
Backend → https://ваш.com
↓ 301 Redirect
NGINX знову → https://ваш.com
і так по колу(

Це можно також перевірити - принцепі яб сказав легко
Робите

curl -I -L http://site.com

І якщо бачиш купу 301/302, і вони цикляться між http та https - bingo

Або моєно подивитися конфіг у

/etc/nginx/sites-enabled/default

(або свій site.conf).
Якщо там побачите шось типо

return 301 https://$host$request_uri;

і при цьому бекенд ще раз редіректить - ось твій баг.

Що я маю вам сказать)
Коли бачите “Too many redirects” - не лізьте одразу в браузер або бекенд.
Спочатку curl -v, дивитесь Location-заголовки, і за 10 секунд бачиш, хто з сервісів зайвий герой)


Хто з першого разу вгадав - респект)
А якщо ні - тепер, коли почуєте “Too many redirects”, у голові одразу спалахне: ага, подвійний https, бачу тебе)

Обняв 🤗🤗🤗