👋 Доброго ранку, QA-друзі!

Сьогодні без історій — вже 11:02, а перший урок на сьогодні вже проведено (і поки що він же й останній )

Сподіваюсь, у вас гарний настрій, бо день тільки починається — або вже якось йде 😄
У мене за вікном дощ, тому саме час зробити собі кави або чаю
…і заскочити почитати щось корисне для професійної душі.

Навіть у суботу ми трішки качаємо скіли 💪

А нижче — рубрика, яка не дасть розслабитись 👇

Всім доброго ранку, як ваші справи? 🫣☀️☀️☀️
Понеділок, а це значить, що

кава вже в руці,

планінг вже десь поруч,

а ми вже потроху в робочому строю,

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

Чому ж не А?
Якби був невірний endpoint, швидше за все був би 404 (Not Found) або взагалі CORS Error. А не 403. тому це не може бути вірною відповідью

і чому не B?
Це вже ближче. Але це наслідок, а не причина.
Браузер не передає авторизаційні дані, бо йому не дали на це дозвіл саме через credentials і політику CORS.

ну про D не будемо згадувати)

а ось чому же С?
Бо браузер не просто труба між UI і беком.
Це справжній митник. І якщо ви не вказали,
fetch(url, { credentials: 'include' })

або в axios

axios.get(url, { withCredentials: true })
тоді ніякі куки чи токени не поїдуть.

А сервер, побачивши "аноніма", чемно каже
403 Forbidden доступ заборонено.

Postman ж не обмежений цими політиками. Там що вставив те й поїхало. Тому там усе працює.

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

Порівнюй заголовки, дивись на CORS, перевіряй, чи летить токен.
Бо в UI без credentials: 'include' токен не поїде, навіть якщо в localStorage/куках він є.


Буду вдячний за репост группи, + приєднуйтесь до нас)
https://t.me/BugOrDefects

Доброго вечора всім - Як пройшов ваш понеділок? У мене щось прям в напрузі, зараз розповім)

Вечірня історія QA, А шо, камера вже зайнята?
або як я навчився читати помилки, а не тільки логи 😅

Сьогодні день був щось пекельний, займався стрімінгом, тестував запуск відео з клієнта.
Запускаю, а відео просто не стартує.
Ні помилки в UI, ні фейлу, ні лагу. Просто тиша.

Я, як порядний QA, лізу в логи.
А там нічого. Порожньо, як в холодильнику))

Починається класика:
Та ну як це, все ж працювало...
Може кудись не туди дивлюсь?
Може сервер тупе?
Може dev щось поламав?
А може... 😶‍🌫️

Пішов в DevTools → Console
І нарешті! Та сама рятівна стрічка
NotReadableError: Could not start video source

Google каже, така помилка буває, коли камера вже зайнята іншим застосунком або вкладкою.

А тепер тримайте кульмінацію
Я сам сидів на іншому екрані, там був відкритий Zoom бо була англіська і я залишився весіти в румі і саме він тримав камеру.
Я навіть не помітив індикатору, бо ну... QA без уваги це окрема професія 😅

в підсумку,
Завів ішшью на клієнт - Error від WebRTC має хендлити такі фейли з повідомленням типу “Камера зайнята”
Бо якщо користувач не бачить помилки він подумає, що воно просто не працює
А насправді просто не твій день (і не твоя камера)


А у вас таке було?
Коли баг знайшовся не завдяки скілам, а власній неуважності?
Поділіться, щоб не я один тут соромився 😅

Буду вдячний за репост группи, + приєднуйтесь до нас)
https://t.me/BugOrDefects

Доброго ранко!!! як ваш настрій? 👀👀👀

Ранкові Історіі QA. коли сам собі зробив ранковий ППЦ*****

Вівторок.
Всі кажуть, що понеділок, важкий день.
Ага, ага.
Я тепер в це не вірю.

Бо от ранок, вівторок, ніщо не віщує бєди. Я собі далі тестую стрімінг, ловлю баги, слухаю лофі… і тут прилітає ідея, а що як трохи нагрузити систему?

Ну, типу, не одна камера, а 10-20…
Ага! Підняти віртуальні камери і хай стримять собі стріми, хай бекенд потіє трохи.

Мислю далі, як це зробити?

Йду до тимліда,
Кажу Слухай, є ідея така…
Він (як завжди позитивний, як мій термометр у липні)
Та легко. Підійми віртуалку десь у vSphere, заімплементуй скриптом кілька камер і буде тобі щастя!

Я такий - Challenge accepted.

Іду в вебшару vSphere, і тут починається та сама технічна реальність, де ти QA, DevOps, і чарівник одночасно.

що роби и куди я ото поліз - ну окай

Підняв віртуалку у vSphere

Взяв Ubuntu Server ISO

Налаштував ресурси (2 CPU, 4 GB RAM, мінімум 10 GB disk)

Включив SSH, бо без нього як без рук.

Поставив віртуальні камери

Встановив v4l2loopback:

sudo apt install v4l2loopback-dkms

Завантажив:

sudo modprobe v4l2loopback devices=5 video_nr=10,11,12,13,14 card_label="Cam1","Cam2","Cam3","Cam4","Cam5"

Це створює 5 віртуальних камер /dev/video10-14.

Залив відео на луп
За допомогою ffmpeg:

ffmpeg -re -stream_loop -1 -i cam1.mp4 -f v4l2 /dev/video10 &
ffmpeg -re -stream_loop -1 -i cam2.mp4 -f v4l2 /dev/video11 &
ffmpeg -re -stream_loop -1 -i cam3.mp4 -f v4l2 /dev/video12 &
ffmpeg -re -stream_loop -1 -i cam4.mp4 -f v4l2 /dev/video13 &
ffmpeg -re -stream_loop -1 -i cam5.mp4 -f v4l2 /dev/video14 &

Кожен ffmpeg крутить своє відео вічно (-stream_loop -1), подаючи його у віртуальну камеру в реальному часі (-re).

Моніторю логіку стріму на бекенді

Через логери, метрики, response time дивлюсь, як воно себе веде.

А далі…
Ви думаєте, я пішов пити каву після такого?
Ха! Мій мозок вирішив, що він заслуговує на морозиво, бо плавитись вже почав конкретно

А ви, друзі, юзали якісь тулзи для створення віртуальних камер чи емуляції стріму?
Може, знаєте крутіші способи?
Діліться в коментах або в особисті може щось є по проще?

І памʼятайте: хороший QА, це не лише про «знайти баг», а й про «а давай нагрузимо це по-доброму »

Буду вдячний за репост группи, + приєднуйтесь до нас)
https://t.me/BugOrDefects

🌤 Доброго ранку, Друзі!

Історій сьогодні нема, буває і таке. QA-життя баги, логи, рутина.
Але раз вже ми знову говорили про запити хочу порадити один з найтоповіших тулів для цього, Charles Proxy.


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

Зроблю вам мінемальний гайд а далі вже самі)

Налаштування SSL Proxy

Proxy > SSL Proxying Settings > Enable SSL Proxying
Add location: Host=*  Port=443

Сертифікат для емулятора або реального пристрою
Help > SSL Proxying > Install Charles Root Certificate

По Фільтрам

Тільки GET                             - Method == GET
Тільки 4xx статуси  - Status >= 400 AND Status < 500
Лише свій домен  - Host contains api.myapp.com
Запити на логін  - Path contains /auth OR Path contains /login
Payload містить "token"  - Body contains token

Breakpoints (редагуй запити вручну)

Tools > Breakpoints > Add:
Host: api.myapp.com
Path: /api/v1/user
Method: POST

Зміні будь-який параметр перед відправкою (наприклад, роль юзера, токен, ID)

Modify / Rewrite Tool
Tools > Rewrite > Enable

Приклад підміна ролі у відповіді

Type: Response Body
Match: "role":"admin"
Replace with: "role":"guest"

Map Local (моки без мок-сервера)

1. Виділи запит > Map Local
2. Вкажи шлях до локального JSON (або HTML, зображення і т.д.)
3. Запит отримає локальну відповідь, не з сервера

Throttle (імітація поганої мережі)

Proxy > Throttle Settings > Enable Throttling
Example: 3G Edge
Bandwidth: 128kbps  
Latency: 1000ms

Ось це прям Корисно для тесту інтерфейсу під час повільного завантаження.

ну і куди без Save Session
File > Save Session As...
лог зберігається, можна закинути в Jira / репорт / переслати деву

Для QA це
Перевірити, що буде, якщо сервер поверне помилковий JSON

Перехопити і вручну повторити нестабільний запит

Підмінити відповідь бекенду, щоб перевірити відображення помилок

Вловити різницю в поведінці мобільного vs веб клієнта

ну і бонусом залишу вам
шаблон rewrite правила.

Request Header: Replace Authorization: Bearer valid → Authorization: Bearer invalid
Response Body: Replace "status":"active" → "status":"banned"

Без чарльза ти просто дивишся на апку.
З ним бачиш, що в ній насправді відбувається.

https://www.charlesproxy.com/. тут можете його Download

Буду вдячний за репост группи, + приєднуйтесь до нас)
https://t.me/BugOrDefects

Всім доброго вечора) ну я не міг це не закинути вам 🤪😀😀😀

Цеж прям відео, яке пахне продакшеном
Із серії "Нам просто треба маленький фікс"...
А отримали,
- розрив джуніорського серця
- нескінченну кількість side effects
- нервового проджекта на фініші
- а ще в кінці винен QA бо так пізно найшов багу перед релізом 🤯

і не кажіть шо у вас такого не було - ти думаєшь шо ти молодець найшов багу - а тобі втик ЧОГО ТАК ПІЗНО)👀👀

🌤 Доброго ранку.

Сьогодні без багів і приколів. Просто трошки з життя.

Прокидаюсь, і розумію сьогодні не мій день.
Голова гуде, як прод після гарячого релізу.
Температура, нудота, тіло ватне.
Організм каже мені пиши лікарняний, друже, відпусти ситуацію.

А мозок QA-шника вже відкриває пошту.
І бац, issue в якому є фікс, який скинули вночі.
Причому не просто фікс, а той, що має сьогодні піти в прод.
І бажано перевірити до обіду.

І от я сижу, ще без сніданку, дивлюсь на той таск, і думаю

Ну от як, блін, це має працювати?
Я ледве мозок можу ворушити, а таск живіший за мене і кричить який сік лік давай перевіряй мене! 👀

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

А у вас бували такі дні?

Коли тіло каже "відпочинь", а таск "не час".

Коли ніхто не скаже "спасибі", але ти все одно зробив.

Коли чай це не напій, а coping mechanism.

Всім гарного рабочего дня - Вихідні вже скоро 🫰🏻

Буду вдячний за репост группи, + приєднуйтесь до нас)
https://t.me/BugOrDefects

Статистика дуже тісна для кожной відповіді, зроблю коротке роз'яснення цього пула


Чому (А) неправильно

GET-запити використовуються для отримання даних.
Вони не повинні мати body. За стандартом HTTP, GET ігнорує тіло запиту.
якщо вже фільтрація (наприклад, role=admin) повинна передаватися через query-параметри типо як приклад GET /api/users?role=admin

Чому не (B)
Сумнівно и Частково неправильно
POST зазвичай використовується для створення ресурсу.
Якщо ми робимо POST на /api/users/123, це ніби як створення з фіксованим ID, що не є стандартною практикою за часту ID присвоює сам сервер - і так є проекти які використовую POST і для DELETE/UPDATE/ADD

Чому же всеж це саме (C)
PUT використовується для повного оновлення ресурсу.
Ми звертаємося до конкретного користувача з ID 123 і передаємо нові дані.
Тіло запиту (body) містить оновлену інформацію це повністю відповідає REST-стилю.

Ну і (D)
DELETE запити не потребують тіла.
Уся необхідна інформація вже міститься в URL (/api/users/123), тому body зайвий.
Більшість серверів ігнорують body у DELETE-запитах.

Вроді пояснив, але якщо у вас є зауваження чи щось додати - Welcome


Буду дуже вдячний за підписку і поширення групи 🤗🤗🤗

https://t.me/BugOrDefects