Всім привіт - Здивований статистикою відповідей)

Тоді давайте розберемо шо це коротенько і для чого.

Наприклад ситуація — з фронта відправляється форма або івент, і в полі, наприклад, назва, написано:
"Це круто & нова фіча"
або навіть типу:
"Ціна < 1000"

І тут починається магія — сервер падає, або дані не зберігаються, або бачиш “Parsing Failed”.
Чому?

Бо &, <, > — це спецсимволи для HTML або XML. Коли ти їх вставляєш у дані без кодування, парсер думає, що ти хочеш передати HTML-сущність.

Наприклад:   — це норм, бо це валідна сущність, тобто не розривний пробіл.
А от якщо ти просто написав & — сервер думає: “О, зараз буде сущність”, чекає далі, але не знаходить нічого валідного. У нього коротше паніка — “що це було?” — і він каже: “Parsing Error”.

Так само з < — парсер думає, що зараз почнеться тег типу <div>, але тег не закрився — значить, знову помилка.

А найсмішніше, що в JSON це не викликає проблем, а в XML або HTML — викликає.

Спитаєте а чому в Json OK!
У JSON проблеми з &, <, > самі по собі зазвичай не виникають, бо, JSON не сприймає ці символи як спецсимволи, &, <, > — у JSON це просто символи в рядку, ніякої сутності типу   він не чекає;

JSON не інтерпретує HTML або XML, тому не "плутається" від амперсанда чи кутових дужок.

АЛЕ! Проблеми можуть виникати пізніше, якщо:

Цей JSON десь вставляється у HTML без ескейпу — тоді браузер чи сервер може подумати, що це HTML.

JSON конвертується в XML або вставляється в XML-подібну структуру — і тоді вже & або < ламають усе.

Сервер неправильно обробляє символи (не декодує, не ескейпить), особливо якщо тип відповіді не application/json, а, скажімо, text/html.

Висновок:
У JSON — ок (поки ти з ним поводишся правильно).

Але у змішаних системах (JSON + HTML / XML / Markdown / Email шаблони) — починаються веселощі.

Що робити при тестувані QA?

— Тестуй вручну такі кейси: &, <, >, ", '
— Перевір, що фронт ескейпить спецсимволи (або навпаки — не ескейпить і це проблема)
— Перевір, що бекенд може їх парсити
— Не лінуйся — закинь такі значення в форму і подивись лог/відповідь
— І найголовніше — тестуй поля, які можуть містити текст від користувача: назви, коментарі, пошук, тощо

Бо інакше...
“Parsing Failed” в проді, нічосі не збереглось, юзер кричить, деви не розуміють шо сталося, а ти такий: “Я не тестив з амперсандом...

Чому це важливо для QA:
Якщо дані з цими символами не енкодяться при відправці — бек може їх не розпізнати.

Якщо бек їх не декодує — користувач побачить "сміття" типу &gt; замість >.

Це може зламати HTML-розмітку або XML-структуру — особливо в e-mail, PDF або звітах.

Ось вам маленький популярний приклад сущностей:

& → &amp;

< → &lt;

> → &gt;

" → &quot;

' → &apos;

  →   (нерозривний пробіл)

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

QA та логи: як не пропустити головне?
Зберігай собі — пригодиться ще не раз.

Для Десктопних застосунків (Windows / macOS / Linux):

Реальний час — консоль рулить
— Відкрий .exe, .app або інший файл через консоль → бачиш помилки в реальному часі.

🔧 Electron або WebView?
Ctrl+Shift+I (Win) або Cmd+Opt+I (Mac) → відкрий DevTools → вкладка Console

🗂 Системні журнали не брешуть:

— Windows: eventvwr.msc → Application
— macOS: Console.app
— Linux: journalctl, dmesg, або /var/log/syslog

Де шукати лог-файли руками на OS
%APPDATA%
%LOCALAPPDATA%
~/Library/Application Support/
~/.config/
/var/log/

Debug-режим:
— Запускай із параметром --debug — і отримай більше деталей.

📲 Android: лови, поки не зникло

Потрібно:
USB-кабель

Увімкнена налагодка (7 кліків по Build Number)

ADB з Android Platform Tools

Команди:
adb devices # перевір, що підключено
adb logcat # всі логи в real-time
adb logcat | findstr com.your.app # лише твоє
adb bugreport report.zip # все й одразу

Де ще лежить корисне:
/sdcard/Android/data/com.your.app/files/

Якщо після ручного APK Market лається:
adb uninstall com.your.app
adb shell pm clear com.your.app
adb shell rm -rf /sdcard/Android/data/com.your.app


iOS: не так просто, але можливо

🛠 Потрібно:

Mac + кабель

Доступ до Xcode

Варіанти:

Xcode → Devices → Console

Console.app (обираєш iPhone → спостерігаєш)

Crash-репорти:
~/Library/Logs/DiagnosticReports/


Золоті поради для QA:

🔸 Лог без таймстампа — це ліс без GPS
🔸 Якщо є маркери або логгер — використовуй їх на максимум
🔸 Прив’язуй лог до кроків → швидше фікс
🔸 І не забудь: поганий баг без лога — як кримінал без доказів

Підписуйся на BugOrDefect
Тут не буде води. Тільки практика, приклади з реальних історій й щоденні інструменти для QA.

Ранкові сторії QA

Всім доброго ранку - і гарного понеділка🤗

Понеділок. Після відпустки.

Прокинувся з думкою: "Ну все, заряд енергії, новий тиждень, можна гори звернути!"
Але гори вже чекають на тебе — у вигляді задач.

46 нових повідомлень у Группі
Jira: 3 нові таски + 2 повертайся-знову
"Team lead з відділу" згадав баг із червня
Smoke ще не пройшов, а dev вже штовхає новий білд
"А давайте ще невеликий регрес..."

Понеділок, ти ж обіцяв бути м’яким 🙃

Ранкова порада:
Спочатку — кава ☕️
Потім — пріоритети
А вже після — все інше. Навіть регресія.

А як у вас проходять ранкові QA-понеділки?

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

Привіт всім - Продовжим тему про логи

QA ≠ Тільки кліки.

Ти хочеш читати логи?
Тоді відчуй силу терміналу.

⸻

ps?
Це не просто “псс”, це:

ps не просто команда — це твій детектив у Linux-системі.
Зробив повний гайд, як бачити те, що ховається за лаштунками

Основи виживання QA в Linux:

ps                  # покажи процеси в поточному терміналі  
ps -e               # покажи всі процеси у системі  
ps -l               # деталізований список з аргументами команд  
ps -ef              # повна інфа про всі процеси

Фільтруй, як dev,

ps -u username      # процеси конкретного юзера  
ps -p 123,456       # процеси з PID 123 і 456  
ps -e --no-headers  # без заголовків (для скриптів)  

Потоки (threads):

ps -eLf             # всі треди у всіх процесах  
ps -T -p PID        # всі треди конкретного процесу  

Термінал-контроль:

ps -t pts/0         # процеси з певного терміналу  

Детективний режим,

ps -e | grep "?"    # хто не має прив’язки до терміналу  
ps -eH              # покажи процеси ієрархічно (parent-child)  
ps -Fg root         # процеси групи root  

Свій формат — сила:

ps -eo pid,user,comm                 # власний формат виводу  
ps -eo pid,%cpu,%mem,comm           # використання ресурсів  
ps -eo pid,comm,lstart,etime        # старт/тривалість процесів  
ps -eo pid,comm,psr                 # CPU affinity (на якому ядрі крутиться)  

Хто жере пам’ять і CPU?

ps aux --sort=-%mem | head          # top 10 по пам’яті  
ps aux --sort=-%cpu | head          # top 10 по CPU  

Зомбі-режим:

ps aux | grep ""                   # зомбі процеси

Повна картина,

ps auxww                            # без обрубування команд  
watch "ps aux --sort=-%cpu | head" # реальний моніторинг CPU-пожирачів  

Мораль така:

Баг — це не лише помилка в UI.
Справжній QA — копає глибше,
в логах, процесах, ресурсах.
CLI — це твоя сила.

⸻
Якщо бажаєте ще інструкції про grep, tail, journalctl, htop?
Пиши в коменти або чекай наступний пост — буде круто

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

Дуже цікава статистика, прийдеться роботи розбору для цього пула)

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

Вечірні історії QA

Розбирав один цікавий кейс - Кейс про зникаючі дані, які насправді нікуди не зникали
(або як localStorage зробив вигляд, що користувача не існує)

Situation,
— Юзер логіниться по email
— Додає товари в корзину
— Закриває додаток / виходить
— Знову логіниться

Корзина порожня, фільтри скинуті, REST нічого не повертає

Думаю: "Окей, рефреш? Кеш? Session timeout?"
Але! Навіть після оновлення сторінки до релогіна все було ОК, тобто справа не в сесії, не в рефреші, і точно не в браузері.

Думаю окай - будемо розбирати,

— Перевіряю REST — дійсно, приходить пустий масив на /cart і /filters
— Іду в базу — роблю select по user_id, → і тут перший шок: взагалі немає записів по цьому юзеру
Але я ж пам’ятаю, що вони були… Я САМ їх додавав!
— Перелогінююсь ще раз з тим же email → дивлюсь — корзина заповнюється (😅), але тільки якщо логін був з тією ж регістрацією email, як і раніше

Окей, теорія: різний кейс в email'і (upper/lower case) дає різний результат
Починаю тест:

— Заходжу як User@example.com → додаю товар → ID юзера в REST: id=1479
— Виходжу → заходжу як user@example.com → ID юзера: id=1932 😳

Один і той самий email, але два різні юзери в системі
(бо фронт не нормалізує email до нижнього регістру, і створює новий акаунт)

DevTools → Application → LocalStorage
→ дивлюсь ключі, значення
→ під кожен варіант email (User@... і user@...) зберігається окремий user_id

Виходить, що юзер сам себе обманув — або точніше, фронт створив дві сутності під один email, просто через різну капіталізацію.
А бек — йому що? Він чесно створив два акаунти.

Висновки для себе і всіх, хто дочитав:

Завжди нормалізуй email на фронті (toLowerCase())

Якщо REST поводиться адекватно, а юзер каже "все пропало" — дивись на ID

Використовуй DevTools → Application → LocalStorage
→ дивись user_id, token, і все, що може впливати на запити

Фронт теж може бути джерелом проблем, навіть коли здається, що він ні при чому

Різниця в одному символі — мінус корзина, мінус юзерський досвід

Такий баг не ловиться автоматично.
Його ловить уважний QA, який знає, куди копати: бази, localStorage, REST, ID.

🫡 Дякую, що дочитав

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

Всім доброго раночку 🤗 - погодка сьогодні не сонячна, але держимо настрій)

Ранкова історія QA 🫣
Коли учень перегнав вчителя?
(або як реагувати, коли тебе вже навчають твої ж учні)

Вчора ввечері був ще один дзвінок з учнем — готуємось до співбесіди, проганяємо кейси, говоримо про API, кеші, інтеграції…
І от на одному моменті я завис — кажу:
— “Слухай, а отут я так сходу не скажу...”
А він:
— “Та я розбирав нещодавно, там такий нюанс ще є, зараз покажу”.
І показує. Правильно. Красиво. По ділу.
І я завис вдруге — не від питання, а від думки.

А що, якщо учень вже краще за мене?
Радіти чи ревнувати?
Пишатися чи підтягуватись?

Бо з одного боку — це ж круто, я передав знання, дав базу, навчив розбиратись самостійно.
А з іншого — трошки б’є по самооцінці 😅

А ви як реагуєте, коли ваш учень “переростає” вас?
Це сигнал, що ви крутий ментор, чи дзвіночок, що пора й самому качатись далі?

🤔 Поділіться в коментах — хочеться зрозуміти, як інші це сприймають.

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

Привіт - Вирішив написати вам короткий розбір пула поки пішов на обід

ну що як вже багато знає шо правильна відповідь це (B) яка набрала всього 13%😢

find / -name "core.*" -exec cp {} ~/Desktop/ \; — Ця команда проста і робоча. Вона проходиться по всьому файловому дереву (/) в пошуках файлів, які підпадають під маску core.*, і одразу копіює кожен знайдений файл у твій Desktop.

{} — це місце, куди find підставляє знайдений файл.
-exec ... \; — виконує команду для кожного результату.

Неважливо, де файл лежить — знайде і скопіює. Не треба нічого вручну парсити, писати скрипти чи гадати, куди що передати.


Чому не (A) cd / && find . -name "core.*" | cp $1 ~/Desktop/ — Тут багато хто попадається.
Ти наче хочеш через | передати шлях у cp, але $1 — це не значення з пайпа, а аргумент скрипту/команди, в результаті cp отримує порожній $1 і каже: "чувак, куди копати?".


Чому не (С) scp user@server:/core.25931 . — Хороша команда, якщо ти точно знаєш повний шлях до файлу. Але якщо файл "десь на сервері" — тобто ти навіть не знаєш, чи він в корені, чи в якійсь /var/tmp/... — ця команда нічого не знайде.
А ще може впасти з помилкою: "No such file or directory".

ну і чому не (D) gzip core.* && mv core.*.gz /tmp/ — Архівуєш дамп — це ок, але core.* може містити кілька файлів або неіснуючі файли в поточній директорії. А ще ти його не копіюєш, а переміщаєш в /tmp/. І знову — якщо не в тій директорії, команда не знайде нічого.

тобто коротко чому find / -name "core.*" -exec cp {} ~/Desktop/ \; рулить,

- Працює з будь-якою кількістю дампів
- Не вимагає знати шлях
- Копіює одразу, без танців з бубном
- Зручно для автоматизації або в кризових ситуаціях

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

Залишу це тут))

Bug, Defect, Error, Failure, Issue — не плутай!
Збережи собі — знадобиться ще не раз

Error — Це людська помилка: неправильна логіка, формула, або інтерпретація вимог.
Саме error створює дефекти в коді чи дизайні.
Приклад: Dev помилився у формулі знижки — отримали від’ємну ціну.

Defect — Це відхилення від очікуваної поведінки, помічене на етапі розробки чи тестування.
Не обов’язково впливає на користувача — це те, що не відповідає вимогам.
Приклад: Пропускає вхід з пустим паролем, хоча за ТЗ не має.

Bug — Це дефект, що проявляється при виконанні ПЗ — часто в тестах або продакшні.
У реальному житті “баг” і “дефект” часто вживають як синоніми.
Приклад: Кнопка “Submit” не працює — забули викликати функцію.

Failure —
Це реальна відмова системи під час запуску.
Помилка → дефект → баг → failure — саме він б’є в користувача.
Приклад: Додаток падає при завантаженні файлу понад 2MB.

Issue
Широке поняття з трекерів (JIRA, GitHub):
🔹 Баги
🔹 Завдання
🔹 Фічі
🔹 Імпрув
Не кожна issue — це баг.
Приклад: “Проблема логіну” → може бути баг, а може просто редизайн.

Як пов’язані всі ці поняття?

Error (людська помилка)
↓
Defect (в коді чи дизайні)
↓
Bug (виявлено під час тестування або в юзерів)
↓
Failure (помітна відмова при запуску)

На замітку QA:

🔸 Баг без контексту — як діагноз без аналізів
🔸 Не всі баги = дефекти. Але всі дефекти можуть стати багами
🔸 У JIRA не все "issue" — проблема. Чітко називай тип

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

Всім доброго вечора!
Якого б ти рангу не був, а це знати повинен.

QA Cheatsheet: Must-Have Basics для кожного тестувальника
Збережи собі й повертайся, коли загубишся в багоджунглях.

📌 1. Види тестування
Functional — чи все працює за вимогами?
Regression — нічого старого не зламалось?
Unit — окремі модулі працюють?
Integration — взаємодія модулів ок?
API — запити та відповіді валідні?
UI/UX — чи це юзер-френдлі?
Performance — швидко/під навантаженням?
Security — діри знайдено?
Smoke/Sanity — швидка перевірка ключевого

📌2. Техніки тестування
Boundary Value
Equivalence Partitioning
State Transition
Random
Exploratory
Ad-hoc
Checklist

📌3. Severity vs Priority
Severity = наскільки боляче
Critical > Major > Minor > Trivial

Priority = наскільки терміново
High > Medium > Low

📌4. Інструменти для бойового QA
Selenium / Cypress / Playwright – UI
Postman / RestAssured – API
JMeter / K6 – навантаження
Burp / OWASP ZAP – безпека
TestRail – тести
Jira / Bugzilla – баги
Charles / Fiddler – мережа

📌 5. Документація, без якої ніяк
Test Plan
Test Cases
Test Summary
Bug Reports

📌6. STLC – Життя тесту
Аналіз вимог
Планування
Написання кейсів
Підготовка середовища
Виконання
Баги + ретест
Закриття

📌7. Принципи тестування
Дефекти є — треба шукати
Раннє тестування = дешевше
Все протестити — нереально
Баги гуртуються
Тести мають бути повторними
Все залежить від контексту
Відсутність багів ≠ продукт ок
Шукай дефекти з самого старту

📌8. Головне з сучасного QA-контексту
CI/CD – релізи на автопілоті
TDD – спершу тест, потім код
BDD – сценарії як розмова
SDLC/STLC – бач загальну картину

📌9. Майндсет QA-шника
Постійна цікавість
Думай як юзер
Ламай свідомо
Фіксуй усе
Автоматизуй, де це має сенс
Говори з девами і продами

Хочеш більше таких шпаргалок?
Підписуйся https://t.me/BugOrDefects

Ранкова історія QA 👀

Сьогодні без історій.
Ніхто нічого не зламав, білди зелені, dev мовчить, прод дихає.

Просто день як день.
А ти — як ти.

П’єш каву, читаєш таски й чекаєш, коли щось піде не так. Бо інакше — не QA.

✈️ буду вдячний за репост групи.

https://t.me/BugOrDefects

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

🌙 Вечірня історія QA: Ubuntu Edition

Є кейси, після яких хочеться просто зробити shutdown now...
⠀
Ситуація:
Підключаюсь я до своєї улюбленої Ubuntu машини. Ввожу пароль — бац... чорний екран на пару секунд... і знову екран логіну.
⠀
Я такий:
"Ммм, цікаво… Ну давай, Google, витягуй мене з цього".
⠀
Перші думки — або проблеми з X, або щось з драйверами/десктопом. Але ж просто ж логін — а по SSH заходить норм.
⠀
Після кількох годин розкопок, перевірки логів

journalctl -xe, cat ~/.xsession-errors

— зрозумів:
login manager (в моєму випадку gdm3) просто завалився при запуску сеансу.
⠀
Рішення:
Зайшов по SSH або в tty (Ctrl+Alt+F3)

Випробував перезапуск gdm3:

sudo systemctl restart gdm3  

Але... той самий результат 🥲

Вирішив перевстановити дисплей-менеджер:

sudo apt-get install --reinstall gdm3  

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

sudo apt install lightdm  
sudo dpkg-reconfigure lightdm  

Вибрав lightdm — після цього система ожила
⠀
Ну а далі ще трохи

sudo apt autoremove, sudo apt update,

і я знову в строю.
⠀

У кого таке було? 😄
Пиши в коментар, як вибирався з чорноти екрану.
А якщо ще не було — збережи пост, може колись Ubuntu тебе "перевірить"

✈️ буду вдячний за репост групи.

https://t.me/BugOrDefects

Сьогодні попав під ☔️ і побачив таку картину😆

Коли твій автотест не перевіряє умови середовища…
☔️+❄️+💦= #true

Manual QA дивиться на це і такий:
Ну точно ж баг, ну люди добрі!🤪🤪🤪

Усім доброго ранку! 😴☀️

☀️ Ранкові історії QA ☀️

QA-ранок: «Це точно клієнт!»

Прокидаєшся, відкриваєш чат:
Там вже всі спам’ять Клієнт не працює! Що з ним?
І ти такий: Ага, щас…

І от ти включаєш інвестигейт, лупаєш по логу, перевіряєш все — і тут піп: сервер прислав кривий XML.
А клієнт за який ти відповідаєш вже отримав репутацію “того, хто все ламає”.
І ти вже кричиш в чат: «Ні, хлопці, це сервер тупить!»
Але всім простіше вірити, що це клієнт винен.

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

📲 Буду вдячний за репост Групи.

https://t.me/BugOrDefects

Ubuntu. Просто. Чітко. В одному місці.
Поки система не впала — збережи цю шпаргалку.

Команди на всі випадки:
– Моніторинг
– Файли
– Пакети
– Мережа
– Сервіси
– Cron
– Snap і APT
– UFW, SSH, ping і ще купа всього

Якщо ти працюєш з Ubuntu — це must-have.
то роздрукуй, повісь і поклоняйся час від часу.

Буду вдячний за репост групи.

https://t.me/BugOrDefects