💀 Найтупіший спосіб вбити будь-який мобільний додаток (і чому QA це пропускають)Уявіть біль: користувач заповнює величезну форму реєстрації у вашому додатку (або оформлює кредит). Доходить до останнього кроку, де треба ввести код із SMS.Він згортає ваш додаток. Відкриває повідомлення. Копіює код. Повертається назад... і бачить стартовий екран із логотипом.Додаток перезапустився з нуля. Всі введені дані зникли. Телефон полетів у стіну, а ваш додаток — у кошик.Що сталося "під капотом"?Тестувальники часто забувають одну жорстоку істину: операційні системи (Android та iOS) — це безжальні диктатори. Вони ненавидять додатки, які "висять" у фоні.Коли юзер згорнув вашу апку, щоб відповісти в Telegram або зробити фото, ОС вирішила: "О, мені не вистачає оперативки для камери! Кого б вбити? А ось цього хлопця у фоні!".Ваш процес був фізично знищений системою (Process Death). А коли юзер повернувся, ОС спробувала його "воскресити" (Restore State), але розробники забули написати код для збереження даних у кеш.Як влаштувати цей краш-тест своїми руками?Щоб перевірити, чи виживе ваш додаток, вам не треба чекати, поки ОС сама вирішить його вбити. Увімкніть "режим ката":🔥 Спосіб 1: Для Android-хардкорщиків (Don't Keep Activities)
Зайдіть у налаштування телефону -> "Для розробників" (Developer Options) -> увімкніть галочку "Не зберігати дії" (Don't keep activities).Тепер система буде вбивати кожен екран вашого додатка тієї ж мілісекунди, як ви його згорнете. Зайдіть у свою апку, почніть щось робити, згорніть її і розгорніть знову. Якщо все крашнулося або дані зникли — вітаю, ви знайшли Blocker.
📸 Спосіб 2: Тест "Важкої артилерії" (iOS / Android)Не хочете лізти в налаштування? Зробіть це природним шляхом:
1️⃣Запустіть ваш додаток, почніть важливий процес (оплата, заповнення профілю).2️⃣Згорніть його.3️⃣Відкрийте камеру і почніть знімати відео в 4K 60fps на 1-2 хвилини. Або запустіть Genshin Impact / Call of Duty Mobile.4️⃣Поверніться у свій додаток.
Важка гра або камера вижеруть усю оперативну пам'ять (RAM), і система гарантовано приб'є ваш додаток у фоні.Висновок:Мобільний додаток — це не сайт на десктопі, який може висіти у вкладці тижнями. Він живе у ворожому середовищі, де його можуть вбити будь-якої миті. Якщо розробники не навчили додаток "зберігатися перед смертю" (Save Instance State), цей продукт не готовий до реального світу.А ваші додатки виживають після згортання? 👇🔥 — Так, у нас з цим строго, тестуємо через Don't keep activities!👀 — Жодного разу так не перевіряв(ла), сьогодні ж спробую...🤯 — Наш додаток падає, навіть якщо просто змінити орієнтацію екрана!
💳 Подвійне списання грошей: Що таке Ідемпотентність API і як її тестуватиПривіт, екіпаж! Сьогодні розберемо один із найдорожчих багів електронної комерції та страшне слово, яким бекендери люблять лякати джунів. ☕️Уявіть класичну ситуацію:Ви купуєте квитки на поїзд. Вводите дані картки, тиснете "Оплатити". Інтернет на секунду "зависає". Лоадер не крутиться. Ви нервуєте і тиснете кнопку "Оплатити" ще тричі.Нарешті з'являється екран успіху. Ви заходите в банкінг і бачите, що гроші списалися чотири рази. Ви купили 4 однакові квитки на одне й те саме місце.Чому це сталося? Тому що розробник забув про Ідемпотентність (Idempotency).Що це за звір?В IT ідемпотентність — це властивість системи, при якій багаторазове повторення однієї і тієї ж дії дає той самий результат, що й одноразове.
🔹Метод GET — ідемпотентний. Скільки б разів ви не запитували баланс, баланс не зміниться від самого запиту.🔹Метод DELETE — ідемпотентний. Якщо ви видалили юзера номер 5, повторний запит на видалення просто скаже "Його вже немає", а не видалить когось іншого.🔹А от метод POST (створення замовлення, оплата) — НЕ ідемпотентний за замовчуванням. Кожен новий запит POST створює новий об'єкт.
Як архітектори захищають систему?Щоб 4 кліки не перетворилися на 4 оплати, фронтенд при натисканні кнопки генерує унікальний рядок — Idempotency-Key (Ключ ідемпотентності) — і відправляє його в заголовках (Headers) запиту.Бекенд бачить ключ, проводить оплату і "запам'ятовує" його. Якщо через секунду прилітає ще один запит із таким самим ключем, бекенд розуміє: "Ага, це дубль від нервового юзера або лаг мережі". Він не знімає гроші вдруге, а просто повертає ту саму відповідь, що й першого разу.Як QA має це тестувати? (Краш-тест оплати)Не довіряйте UI, блокування кнопки "Pay" після першого кліку — це захист від "дурня", а не надійна архітектура.⚡️ Тест дубля через PostmanСтворіть запит на покупку товару. Скопіюйте його. Відправте запит. А потім відразу відправте його ще раз, не змінюючи жодного символу (і не міняючи Idempotency-Key, якщо він є).Очікуваний результат: Другий запит НЕ повинен створити нове замовлення. Він має повернути або помилку 409 Conflict, або статус 200 OK (але ID замовлення у відповіді має бути від першої транзакції!).
🐢 Тест "Поганого інтернету"
Відкрийте Chrome DevTools -> Network -> Throttling -> увімкніть Slow 3G.Заповніть форму, натисніть "Надіслати" і почніть швидко клікати по кнопці ще 10 разів, поки запит "висить" у повітрі. Якщо в базі з'явилося 10 однакових записів — заводьте Blocker.
Висновок: Ідемпотентність — це бронежилет вашого бізнесу. Якщо ви тестуєте фінтех, е-коммерс або бронювання — це перше, що ви маєте перевірити на API рівні.А ви стикалися з подвійним створенням сутностей на своїх проєктах? 👇🔥 — О так, постійно ловимо баги з подвійними кліками!👀 — У нас кнопка просто блокується, сподіваємось, цього достатньо...🤯 — Прямо зараз піду перевіряти нашу адмінку через Postman!
🪄 Магія DevTools: Як підмінити відповідь бекенда за 1 хвилину (без Charles та Postman)Привіт, екіпаж! Понеділок — чудовий день, щоб навчитися трохи "ламати" матрицю. ☕️Знайомий біль: Вам потрібно протестувати, як фронтенд покаже помилку сервера (статус 500), або що буде, якщо в юзера від'ємний баланс чи ім'я на 300 символів. Але бекенд працює ідеально, а доступу до бази даних, щоб змінити собі баланс, у вас немає.Більшість іде качати складні проксі-інструменти типу Charles чи Fiddler. Але мало хто знає, що прямо у вашому Chrome є вбудована функція Local Overrides (Локальні підміни). Вона дозволяє "перехопити" відповідь сервера і підсунути браузеру свій власний JSON.Як стати хакером за 4 кроки (зберігайте шпаргалку):📂 Крок 1: Вмикаємо оверрайди
Відкриваємо DevTools (F12) -> йдемо у вкладку Sources -> зліва на панелі шукаємо вкладку Overrides (якщо її немає, натисніть на >>).Тиснемо Select folder for overrides і вибираємо будь-яку пусту папку на своєму комп'ютері. Браузер попросить дозвіл на доступ — погоджуємось (Allow).
🎯 Крок 2: Ловимо запитЙдемо у звичну вкладку Network. Знаходимо той самий API-запит, який повертає ваші дані (наприклад, ваш профіль із балансом {"balance": 100}).
✍️ Крок 3: Підміняємо реальність
Клікаємо по цьому запиту правою кнопкою миші -> вибираємо Override content (Підмінити контент).Браузер автоматично перекине вас у редактор коду. Прямо там міняємо 100 на -999999 або замість імені пишемо величезний текст. Зберігаємо файл гарячими клавішами Ctrl+S (або Cmd+S).
🔥 Крок 4: Магія!Просто оновлюємо сторінку (F5). Браузер проігнорує реальну відповідь сервера і підтягне ваш відредагований файл. Баланс на екрані став від'ємним! Верстка попливла? Вітаю, ви знайшли баг.
Чому це маст-хев для Manual QA?Ви можете імітувати будь-які крайові значення (null, пусті масиви, спецсимволи), не смикаючи розробників і не створюючи сотні тестових акаунтів. А щоб вимкнути магію — достатньо просто зняти галочку Enable Local Overrides у вкладці Sources.📌 Перешліть цей лайфхак у робочий чат, нехай ваші фронтендери почнуть нервувати, що ви тепер можете змокати будь-який стан UI! 😉А як ви зазвичай тестуєте нестандартні відповіді від сервера? 👇🔥 — DevTools Overrides — мій улюблений інструмент!👀 — Використовую Charles / Proxyman для такого.🤯 — Просив(ла) розробників хардкодити помилки... Тепер буду робити сам!
🍕 Баг вартістю в мільйони: Чому QA зобов'язаний вимкнути мишку (Accessibility Testing)Привіт, екіпаж! Неділя — час поговорити про те, як IT впливає на реальних людей. ☕️Уявіть ситуацію: п'ятниця, вечір, ви хочете замовити піцу. Заходите на сайт, а там... неможливо натиснути кнопку "Оплатити". Ви злитесь і йдете до конкурентів.Саме це сталося з Гільєрмо Роблесом у 2016 році на сайті Domino's Pizza. Але був нюанс — Гільєрмо сліпий. Він користувався Screen Reader'ом (програмою, що читає екран), а розробники Domino's забули додати текстові мітки до кнопок. Програма просто озвучувала сліпому юзеру: "Кнопка. Кнопка. Графіка".Гільєрмо подав на Domino's до суду і виграв справу. Компанія витратила роки на суди, отримала величезні репутаційні збитки і все одно була змушена переписати сайт.У західному IT тестування доступності (a11y — від літери 'a', 11 літер між ними, і 'y') — це не благодійність, це суворий закон (ADA в США, EAA в Європі). Якщо ваш продукт не доступний для людей з інвалідністю — вас засудять.Як Manual QA може протестувати Accessibility прямо зараз?Вам не потрібні складні автотести. Достатньо зробити три прості кроки:🚫🖱Челендж "Без мишки" (Keyboard Navigation)Вимкніть мишку та тачпад. Відкрийте ваш проєкт і спробуйте пройти головний флоу (наприклад, реєстрацію або покупку), використовуючи тільки клавішу Tab (для переходу вперед), Shift+Tab (назад) і Enter (для кліку).Що шукати: Чи видно "фокус" (рамку) навколо активної кнопки? Чи не застряг ваш курсор у невидимому вікні (Keyboard Trap)? Чи можна взагалі дійти до кнопки "Купити"?
🎧 Тест із заплющеними очима (Screen Reader)У Windows є вбудований Narrator (або популярний NVDA), у macOS — VoiceOver.Увімкніть його, заплющте очі і спробуйте зрозуміти, що знаходиться на екрані.Що шукати: Якщо замість "Додати в кошик", читалка каже "іконка кошика крапка пнг" — фронтендер забув прописати атрибути alt для картинок або aria-label для кнопок. Для сліпого користувача ваш сайт — це чорна діра.
👁 Тест на контрастність (Color Contrast)Люди з порушеннями зору (або просто на яскравому сонці) не бачать світло-сірий текст на білому тлі.Як тестувати: Відкрийте Chrome DevTools -> вкладка Lighthouse -> поставте галочку Accessibility і натисніть Analyze. Браузер сам покаже вам місця, де дизайнер перемудрував із "повітряними та ніжними" кольорами, порушивши стандарти WCAG.
Висновок:Коли ви перевіряєте alt-тексти або навігацію з клавіатури, ви не просто робите нудну рутину за чек-листом. Ви буквально даєте можливість людині з інвалідністю жити повноцінним життям (і рятуєте свою компанію від позову на мільйон доларів).А у вас на проєкті приділяють увагу a11y? 👇🔥 — Так, у нас суворі вимоги до доступності, тестуємо регулярно!👀 — Іноді Lighthouse ганяємо, але без фанатизму.🤯 — Яка клавіатура? У нас би "щасливий шлях" мишкою пройти без крашів!
🚩 "Кнопка самознищення": Чому Feature Flags — це головний біль QA (і як вони спалили $460 млн)Привіт, екіпаж! ☕️Сьогодні більшість компаній не чекає місяцями, щоб викотити реліз. Вони зливають код у головну гілку щодня. Але як зробити так, щоб користувачі не побачили недороблену фічу?Для цього використовують Feature Flags (Фіча-тогли).Це просто умовний оператор if/else у коді. Розробник ховає нову кнопку за "перемикачем". На продакшені кнопка є, але вона "вимкнена" (ховається від юзерів), поки маркетологи або продакти не вирішать її увімкнути в адмінці (наприклад, через LaunchDarkly).Звучить безпечно? А тепер історія.Катастрофа Knight Capital (2012 рік)Фінансова компанія Knight Capital оновлювала свою торгову систему. Вони використовували фіча-тогли, щоб перемикатися між старими та новими алгоритмами.Але був нюанс: у їхньому коді висів старий, "мертвий" фіча-тогл, створений ще у 2003 році (9 років тому!). Про нього всі забули, але код не видалили.Під час релізу інженер випадково активував цей старий прапорець. Система "прокинулася", увімкнула застарілий тестовий алгоритм з 2003 року і почала купувати акції дорого, а продавати дешево.Систему не могли зупинити 45 хвилин. За цей час компанія втратила 460 мільйонів доларів і згодом збанкрутувала. Через один забутий if.Як QA має тестувати Feature Flags?Якщо на вашому проєкті є "тогли", ось ваші головні правила виживання:🔀 Матриця станів (Увімкнено / Вимкнено)Ви не можете протестувати тільки нову фічу. Ви зобов'язані перевірити, чи не зламався старий функціонал, коли тогл ВИМКНЕНО. Якщо у вас 3 активні фіча-тогли на одній сторінці, у вас з'являється 8 комбінацій для тестування (2 в кубі).
🧹 Тестування "Сміття" (Technical Debt)Фіча-тогл має жити максимум 1-2 спринти. Коли фічу успішно запустили для всіх, тогл ПОВИНЕН бути видалений з коду назавжди. Інакше ваш код перетвориться на мінне поле, як у Knight Capital. Заводьте баги на розробників, якщо вони залишають старі прапорці.
🕵️♂️ Перевірка доступу (Хто смикає рубильник?)Перевірте, що станеться, якщо хтось перемикне тогл прямо посеред сесії користувача. Наприклад: юзер почав заповнювати форму з вимкненим тоглом, а в цей час адмін увімкнув нову версію. Чи не крашнеться додаток при збереженні?
Висновок: Feature Flags — це крутий інструмент для плавних релізів (A/B тестування, Dark Launching). Але для QA — це множник складності. Кожен тогл — це дві паралельні реальності вашого додатка.А ви використовуєте фіча-тогли на своєму проєкті? 👇🔥 — О так, постійно ховаємо за ними недоробки!👀 — Буває, але намагаємось швидко їх видаляти.🤯 — Жодних тоглів, релізимо тільки хардкором!
🎭 Театр якості: Чому 100% автотестів та ідеальна Jira не рятують продакшен?Привіт, екіпаж! ☕️Я помітив, що наші останні обговорення в каналі виходять далеко за межі звичайних багів. Ми все частіше говоримо про те, як зламані самі процеси розробки. Тому я вирішив зібрати наші найкращі думки і написати велику, чесну статтю.Вона про те, чому сучасне IT часто займається імітацією тестування замість пошуку реальних проблем.У статті розібрав три головні пастки:
🐍 Ефект кобри: Як KPI на кількість багів змушують QA шукати пікселі, що з'їхали, ігноруючи діри в архітектурі.🪲 Парадокс пестициду: Чому ваші ідеально зелені автотести з часом стають повністю сліпими.✈️ Карго-культ автоматизації: Навіщо ми намагаємось автоматизувати 100% інтерфейсу, уподібнюючись аборигенам, які будують літаки з бамбука.
👉 Читати повну статтю на Medium: Театр якості в IT: Чому ваші “ідеальні” процеси QA не покращують продуктP.S. Буду дуже вдячний, якщо ви перейдете за посиланням і "поплескаєте" 👏 статті в самому низу (на Medium можна плескати до 50 разів одній статті!). Це дуже допоможе просунути матеріал і залучити нових крутих спеціалістів у наше ком'юніті!Повертайтеся в коментарі після прочитання, обговоримо! 👇
💣 Шпаргалка QA: 5 способів зламати будь-який API (Negative Testing)Привіт, екіпаж! ☕️Написати запит у Postman і отримати зелений статус 200 OK — це лише 10% роботи. Розробники і так знають, що їхній код працює, якщо зробити все правильно. Наше завдання — перевірити, як бекенд поведеться, якщо в нього полетить відверте сміття.Ось мій чек-лист для "краш-тесту" будь-якого нового ендпоінту:🧬 Type Mismatch (Підміна типів даних)
Бекенд чекає, що поле "age" буде числом (Integer)? Відправте туди рядок "twenty", булеве значення true або масив [20].Що очікуємо: 400 Bad Request. Якщо бекенд впав із 500 Internal Server Error — вітаю, ви знайшли баг.
🕳 Missing Keys (Видалення обов'язкових полів)У JSON-тілі запиту є обов'язкові поля (наприклад, "email" при реєстрації). Спробуйте:
🔹Відправити "email": "" (пустий рядок).🔹Відправити "email": null.🔹Взагалі видалити рядок "email" із тіла запиту.Що очікуємо: Чітку помилку валідації від сервера, яка підкаже фронтенду, якого саме поля не вистачає.
🎭 Method Tampering (Підміна HTTP-методу)У документації (Swagger) написано, що ендпоінт /api/users/1 працює тільки через метод POST. Змініть метод у Postman на GET, PUT, PATCH або DELETE і відправте запит.Що очікуємо: Статус 405 Method Not Allowed. Якщо метод DELETE раптом спрацював і видалив юзера — це критична діра в безпеці.
🐘 Boundary & Overflow (Переповнення бази)Поле "first_name" приймає ім'я? Відправте туди текст на 10 000 символів (згенеруйте через Lorem Ipsum). Поле "price" приймає суму? Відправте -100 або 999999999999.Що очікуємо: База даних не повинна "вдавитися". Сервер має обрізати запит або повернути 400 Bad Request з лімітами.
🕵️♂️ Auth Bypass (Обхід авторизації)Ендпоінт вимагає Bearer Token?
🔹Видаліть токен із Headers взагалі.🔹Змініть один символ у валідному токені.🔹Відправте токен звичайного юзера туди, де потрібні права адміна.Що очікуємо: Статуси 401 Unauthorized або 403 Forbidden. Якщо бекенд віддав дані — б'ємо на сполох.
📌 Зберігайте цей чек-лист та пересилайте джунам, щоб вони вчилися ламати, а не тільки гладити API! 👇А який ваш улюблений спосіб зламати бекенд?🔥 — Підміна типів даних, завжди працює!👀 — Переповнення текстом (Overflow).🤯 — Я просто тисну "Send" без авторизації і дивлюсь, що буде
🍻 Суботній офтоп: Професійна деформація, або Чому з QA важко житиПривіт, екіпаж! Суботній вечір, ви нарешті закрили лептоп, вимкнули сповіщення з Jira і пішли відпочивати. Але є одна проблема: мозок тестувальника вимкнути неможливо.Професійна деформація в нашій професії настає дуже швидко. Зізнайтеся, скільки пунктів із цього списку — про вас?🍽 QR-меню в ресторанахЗамість того, щоб просто обрати піцу, ви знаходите з'їхалу верстку на мобільній версії сайту закладу. Ви підсвідомо перевіряєте, чи можна додати в кошик -1 порцію картоплі фрі, а коли оплата не проходить, лізете перевіряти консоль браузера з телефону. Друзі вже доїдають, а ви шукаєте баги.
🚪Ліфти, двері та турнікетиЗвичайна людина просто натискає кнопку свого поверху. QA обов'язково спробує натиснути три кнопки одночасно (Race Condition), потримати двері рукою під час закриття (Interruption Testing) і перевірити, чи поїде ліфт, якщо перевищити вантажопідйомність на 1 кг (Boundary Value).
🛒 Покупки в інтернетіВи просто хотіли купити нові кросівки. Але випадково ввели спецсимволи <script> в поле для промокоду, побачили, що сайт впав з 500-ю помилкою, і замість шопінгу сіли писати безкоштовний баг-репорт у техпідтримку магазину.
🎮 Кіно та відеоігриВи не можете просто насолоджуватися сюжетом гри. Ви йдете в куток карти і починаєте стрибати в стіну, сподіваючись провалитися крізь текстури. А в кіно помічаєте, що в одному кадрі годинник показує 15:00, а в наступному — 12:30. "Баг стейту!", — кричить ваш внутрішній голос.
Висновок: Бути тестувальником — це не просто робота, це фільтр, через який ми дивимося на світ. Ми бачимо недосконалості там, де інші бачать норму.📌 Перешліть цей пост своїм друзям та коханим, щоб вони нарешті зрозуміли, чому ви так дивно поводитеся в побуті! 😂А тепер зізнавайтеся в коментарях: який найсмішніший (або найбезглуздіший) баг ви знаходили в реальному житті? 👇
🛠 Шпаргалка QA: 5 прихованих фіч Chrome DevTools, які економлять годиниПривіт, екіпаж! ☕️Усі ми використовуємо DevTools (F12), щоб подивитися статус 200 OK у вкладці Network або знайти червоний текст у Console. Але насправді це справжній швейцарський ніж, який використовується QA лише на 20%.Ось 5 неочевидних інструментів, які перетворять вас на ніндзя тестування:🛑 Блокування запитів (Block Request URL)
Що перевіряємо: Чи виживе ваш сайт, якщо впаде сторонній сервіс?Як зробити: Вкладка Network -> Клік правою кнопкою по будь-якому запиту (наприклад, скрипту аналітики чи підвантаженню карти) -> Block request URL. Оновлюємо сторінку.Результат: Якщо через відключену аналітику у вас відвалилася кнопка "Купити" — вітаю, ви знайшли критичний баг архітектури.
💾 Збереження логів при редиректі (Preserve Log)
Що перевіряємо: Баги при оплаті або логіні.Біль: Ви тиснете "Оплатити", система видає помилку і миттєво перезавантажує сторінку. Усі логи в Network і Console зникають, ви не встигаєте нічого заскрінити.Рішення: У вкладці Network (та Console) ставимо маленьку галочку Preserve log. Тепер навіть після 10 редиректів уся історія запитів залишиться на екрані.
🌍 Підміна Геолокації (Sensors)
Що перевіряємо: Як працює доставка чи зміна валюти для інших країн.Як зробити: Тиснемо Ctrl+Shift+P (або Cmd+Shift+P на Mac) -> пишемо Sensors. У вкладці, що з'явиться, знаходимо Location і міняємо свій Київ на Токіо, Лондон або вводимо кастомні координати. Жодних VPN не потрібно!
⏱️ Кастомне сповільнення мережі (Custom Throttling)
Що перевіряємо: Таймаути та лоадери.Біль: Стандартний "Slow 3G" іноді занадто швидкий або занадто повільний.Рішення: Network -> Throttling -> Add... Створіть свій профіль, наприклад "Жахливий інтернет", і поставте швидкість 10 kb/s. Це ідеально для тестування того, як довго крутиться лоадер на кнопці.
🎭 Маніпуляції з Local Storage
Що перевіряємо: Реєстрацію, онбординг, стан кошика.Як зробити: Вкладка Application -> Local Storage. Тут зберігаються дані сесії. Замість того, щоб щоразу чистити кеш або йти в Інкогніто, просто видаліть ключ auth_token і натисніть F5 — ви розлогінені. Змініть значення is_new_user з false на true — і ви знову побачите вікна онбордингу без створення нового акаунту!
📌 Зберігайте цей пост у "Збережене" та пересилайте колегам, щоб вони теж перестали страждати з редиректами та VPN!А якою фічею з DevTools ви користуєтесь найчастіше? 👇🔥 — Network, моє все!👀 — Elements, постійно колупаю верстку.🤯 — Тільки що дізнався(лася) про половину з цього списку!
🛑 Шпаргалка QA: Як за 3 секунди зрозуміти, чий це баг (Фронт чи Бек)?Привіт, екіпаж! ☕️Усі ми знаємо цей біль: ти знаходиш баг, кнопка не працює, крутиться вічний лоадер. Заводиш тікет на Фронтенд. Через годину Фронтендер переводить його на Бекенд із коментарем "Це API віддає помилку". Ще через годину Бекендер повертає його назад зі словами "Ти мені кривий JSON шлеш!". 🏓Щоб ваші тікети більше не грали в пінг-понг, ось залізна шпаргалка по HTTP-статусах у вкладці Network.Хто винен і що робити?🟡 400 Bad Request -> Винен ФРОНТЕНД
Бекенд каже: "Я не розумію, що ти мені прислав".Чому: Фронт відправив текст замість числа, забув обов'язкове поле або неправильно зібрав JSON.
🟡 401 Unauthorized -> Винен ФРОНТЕНД (у 90% випадків)
Бекенд каже: "Ти хто такий? Я тебе не знаю".Чому: Фронт не передав токен авторизації в Headers, або токен протух, а фронт забув його оновити (не відпрацював Refresh Token).
🟡 403 Forbidden -> Винен БЕКЕНД (або аналітики)
Бекенд каже: "Я знаю, хто ти, але сюди тобі не можна".Чому: Фронтенд показав юзеру кнопку "Видалити", хоча у юзера немає прав адміністратора. Баг бекенда або архітектури UI.
🟡 404 Not Found (в API запитах) -> Винен ФРОНТЕНД
Бекенд каже: "За цією адресою нічого немає".Чому: Фронт смикає старий або неправильний URL (наприклад, з одруківкою api/v1/usrs).
🟡 405 Method Not Allowed -> Винен ФРОНТЕНД
Бекенд каже: "Ти стукаєш не в ті двері".Чому: Фронт намагається відправити дані через GET, хоча бекенд чекає POST.
🔴 500 Internal Server Error -> ЗАВЖДИ винен БЕКЕНД
Бекенд каже: "Я впав і не можу піднятися".Чому: Навіть якщо фронт прислав абсолютну діч, бекенд ПОВИНЕН був це обробити і повернути красиву 400-ту помилку. Якщо сервер впав із 500-м статусом — це необроблений виняток у коді бека. Без варіантів.
🔴 504 Gateway Timeout -> Винні ДЕВОПСИ (або Бекенд)
Бекенд каже: "Я думав занадто довго і помер".Чому: Або відвалилася база даних, або бекенд написав настільки важкий SQL-запит, що сервер не встиг відповісти за відведені 30/60 секунд.
📌 Зберігайте цей пост у "Збережене" та пересилайте своїм джунам, щоб економити час на розслідуваннях!А який статус-код ви бачите у своєму DevTools найчастіше? 👇
TGLIST.COM.UA
