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

Як кажуть у Lead нема вихідних і відпусток - хоча це може тільки у мене

Вечірня рубки QA

QA-історія для тих, хто тільки починає
“Firefox — а чому все розсипалось?”

Увечері питаю команду:
— Як там UI, все ок?
— Так, усе добре.
— А у Firefox дивився?

...пауза...
Через 3 хвилини мені пишуть:

“Ти ше тут, тут якась дичина…”

Захожу — і бачу те, що бачать усі, хто вперше запускає макет у Firefox:
— Шрифт дивний,
— Тінь не там,
— Кнопка блимає,
— Щось не центрується, хоч мало б.

Чому так?
Бо всі часто перевіряють тільки в Chrome. А Firefox рендерить трохи інакше:

Бо движки у браузерів різні:
— Chrome (і Edge, і Opera) — працює на Blink (Chromium),
— Firefox — на Gecko.

Gecko жорсткіше дотримується специфікацій CSS. Він не “прощає” верстці такі речі як:
— відсутні -moz- префікси,
— невизначені font-family,
— box-shadow, що рендериться по-різному,
— кастомні елементи, що без fallbacks.

І особливо класика: line-height, letter-spacing або scrollbar, які рендеряться як в іншій опері.

Що робити?
-— Завжди перевіряй хоча б у Chrome + Firefox.
—- Використовуй CSS-резети або normalize.css.
—- Якщо щось не так — відкрий Firefox DevTools і дивись вкладку "Computed", вона покаже, що реально рендеритьс, + ексепшени в консолі

Порівнюй стиль елементів у Chrome і Firefox — шукай відмінності.

Маленький лайфхак:
У Chrome все красиво — не означає, що воно так і буде у користувача.
У Firefox — чесніше. Він покаже слабкі місця верстки.

Висновок:
Якщо тестиш тільки в Chrome — ти не тестиш.
Firefox — як суворий викладач. Завжди знайде, де болить.

Тому я завжди перевіряю в Gecko. Бо люблю дизайн… і спати спокійно.

Це вам як бонус де можно дивитися статистики хто шо і де юзають і скільки https://gs.statcounter.com/

Підписуйся на BugOrDefect, якщо теж маєш Chrome, Firefox, Safari, і Edge "про всяк".

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

Усім доброго ранку — Усім гарного настрою☀️
☀️ Ранкові історії ☀️

Ранкова доза реальності для майбутніх QA ☕️
Пост для тих, хто боїться співбесід

Кожного разу, коли я веду QA-курси, я переконуюсь у простій речі:
📚 Сира теорія випаровується одразу після того, як закривається кришка ноутбука.

Вчора спілкувався з одним учнем.
Каже:
— Боюсь ходити на співбесіди...
— Чому?
— Теорія слабка, практики нема. Раптом спитають щось, а я — “ну я не впевнений...”

Я кажу: “Так і ходи! Саме заради цього й треба ходити.”

Запам’ятай
Ніхто не народжується з досвідом.

На кожній співбесіді ти здобуваєш практику.

Кожна "незручна відповідь" — це +1 до твоєї реальної підготовки.

Як готуватись без практики:
Йди на всі співбесіди, навіть якщо вимагають “рік досвіду”
— Це формальність. Якщо ти мотивований і можеш пояснити як ти тестуєш — це важливіше.

Після кожної співбесіди — роби рев’ю
— Запиши питання, де “поплив”.
— Розбери вдома.
— Повтори через день-два.

Створюй свою базу знань
— Це твоя персональна зброя: сценарії, SQL-запити, помилки, що питали, навіть приклади кейсів.

І головне — не сприймай відмову як поразку.
— Це просто ще один крок до тієї співбесіди, де ти скажеш: “Ого, я впорався!”

І Пам’ятай:
Страх співбесіди — це лише страх невідомого.
Але кожна наступна — робить тебе впевненішим, досвідченішим і ближчим до роботи.

Тому, Випив каву — подав резюме — пішов на співбесіду.
Навіть якщо не готовий — саме так ти станеш готовим.

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

Всім привіт!😊
Стосовно Вчорашньої Історіі)

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

Кросбраузерне тестування: не треба тестити всюди і все

Є таке страшне слово — кросбраузерність. І багато хто плутає: думають, що треба відкривати кожен браузер на кожній ОС, тицяти все підряд і молитися. Насправді — ні.

Що треба знати: Браузери мають рушії (rendering engines)
Саме рушії вирішують, як виглядає сторінка, як працює JS, а не назва браузера.

Chrome, Edge, Opera — Blink (Chromium)

Safari — WebKit

Firefox — Gecko

Не тестимо всюди, тестимо з розумом
Якщо в Chrome усе виглядає добре — швидше за все, так само буде й в Edge або Opera (бо той самий двигун).
Safari — окрема історія, бо WebKit має свої приколи. Firefox — теж варто перевірити, хоча б базово.
Мінімум sanity-чек: Chrome + Safari + Firefox.

Головне — рушій, а не логотип браузера
Тестиш у Chrome — вже покрив майже всі Chromium-браузери.
Safari обов’язковий, бо в iOS усі браузери всередині — WebKit, навіть "Chrome для iOS".
Firefox — теж бажаний: його юзає меншина, але з ним бувають сюрпризи.

Нюанси — є завжди:

Safari іноді глючить з flex, grid, шрифтами чи анімаціями

Firefox може по-різному рендерити форми або svg

Chrome — стабільний, але теж треба моніторити консоль (warnings, errors)

Як зрозуміти, де тестити?

Дивись аналітику (Google Analytics, gs.statcounter тощо): які браузери реально юзає твоя аудиторія

Якщо 90% сидять у Chrome — не треба витрачати години на Opera

Є мобільна версія? Safari на iOS — must have, Chrome на Android — теж бажано

Що можу посоветовать в Help
Використовуй BrowserStack, LambdaTest або Sauce Labs
Або локально: Chrome DevTools (device emulation), віртуалки, емулятори

Не забудь про responsive-моди і скріншоти на різних breakpoint’ах

Висновок:
Тестувати треба з головою. Не треба ганяти кожну фічу в кожному браузері.
Дивись на рушії, аналізуй, пріоритезуй.
Safari та Firefox — обов’язкові для sanity. Інше — за потребою.

Бо QA — це не "все відкрити", а "знати, що має сенс перевірити".

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

Усім доброго ранку — Сонечка у віконце☀️
☀️ Ранкові історії ☀️

QA-недільна профдеформація

Було у вас таке?
Три дні релаксу, піченьки, Netflix, світ без Jira...
А потім десь у неділю з ранку мозок такий:
— «А може… ну тіпа… спринт спланувати?»
— «А гляну changelog, шо там наші в staging закинули...»
— «TestRail сам себе не заповнить…»

І ти вже не на дивані, а в голові клікаєш по Confluence-сторінках.
Наче й вихідний, а внутрішній QA вже на daily 😅

Або це тільки в мене така легка quality обсесія?

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

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

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

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