QA Co-pilot

🎭 Театр якості: Чому 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 найчастіше? 👇

🏔 Ефект Даннінга-Крюгера: Чому Senior QA завжди відчуває себе самозванцемПривіт, екіпаж! Понеділок — час для саморефлексії та психології. ☕️Ви коли-небудь помічали цей парадокс? Джуніор, який закінчив тримісячні курси, впевнено розповідає, як треба будувати процеси, і вважає себе богом автоматизації після першого скрипта на Selenium. А Lead QA з 8 роками досвіду перед кожним складним релізом думає: "Господи, я ж насправді нічого не розумію, мене скоро викриють і звільнять".У психології це називається Ефект Даннінга-Крюгера. Це когнітивне упередження, суть якого проста: люди з низьким рівнем кваліфікації роблять помилкові висновки, приймають невдалі рішення і... не здатні усвідомити свої помилки через свій низький рівень кваліфікації.Як цей графік виглядає в кар'єрі тестувальника?🚀 "Пік дурості" (0-1 рік досвіду)Ви вивчили теорію (що таке баг-репорт, техніки тест-дизайну), навчилися відправляти GET-запити в Postman і написали автотест для логіну.Думка в голові: "Тестування — це елементарно! Я знаю все. Розробники постійно косячать, а я їх рятую". Ви на вершині впевненості. Ви не бачите підводних каменів, бо навіть не підозрюєте про їх існування. 📉 "Долина відчаю" (2-4 роки досвіду)Ви потрапляєте на серйозний проєкт. Виявляється, що Postman — це крапля в морі. На вас падають CI/CD пайплайни, Docker-контейнери, мікросервісна архітектура, балансувальники навантаження, Flaky-тести, які падають через анімації, і баги бази даних.Думка в голові: "Я тупий. Я взагалі нічого не розумію в IT. Як я сюди потрапив?".Тут народжується жорсткий Синдром самозванця. Ваша впевненість падає до нуля, хоча ваші РЕАЛЬНІ знання виросли в 10 разів. 🧗‍♂️ "Схил просвітлення" (5+ років досвіду)Ви починаєте збирати себе до купи. Ви розумієте, що знати ВСЕ — неможливо. Ви більше не намагаєтесь покрити 100% коду автотестами. Ви вчитеся керувати ризиками, задавати правильні запитання бізнесу і тестувати архітектуру ще до написання коду.Думка в голові: "Я знаю достатньо, щоб розібратися в чому завгодно, якщо дати мені трохи часу і документацію". Висновок:Якщо ви зараз сидите над складною задачею, дивитесь у код або логи і відчуваєте себе повним самозванцем, якому просто пощастило влаштуватися на роботу — видихніть і прийміть мої вітання.Це означає, що ви злізли з "Піку дурості" і реально розвиваєтесь як професіонал.А на якому етапі графіка ви відчуваєте себе просто зараз?🔥 — Сиджу в "Долині відчаю", синдром самозванця б'є ключем!👀 — Десь на "Схилі просвітлення", прийняв(ла) цей IT-дзен.🤷‍♂️ — Я на "Піку"! Мені море по коліна, тестування — це ізі!

🔥 Хаос-інженерія: Навіщо Netflix навмисно вбиває власні сервери на продакшеніПривіт, екіпаж! Субота — ідеальний час для неймовірних історій зі світу великого IT. ☕️Уявіть ситуацію: розпал вихідного дня, мільйони користувачів дивляться серіали на вашому сервісі. І тут ваш власний системний адміністратор бере "віртуальну кувалду" і навмисно вимикає випадкові бойові сервери. Звучить як саботаж і миттєве звільнення?А для компаній рівня Netflix чи Amazon це — щоденна рутина.Цей підхід називається Хаос-інженерія (Chaos Engineering), і він руйнує класичне уявлення про тестування стабільності.Як виникла ця ідея?Коли Netflix переїжджав на хмарні сервери AWS, вони усвідомили сувору правду: у хмарі сервери будуть падати. Завжди. Замість того, щоб молитися на стабільність інфраструктури, вони створили програму під назвою Chaos Monkey (Хаос-мавпа).Ця "мавпа" буквально бігала по їхньому продакшену і випадково вимикала робочі сервіси.Навіщо ламати власний продукт?Логіка геніальна: якщо ви знаєте, що сервер впаде у вівторок о 15:00, коли всі інженери сидять в офісі з кавою і готові до інциденту, це набагато краще, ніж коли він впаде сам о 3-й ночі в неділю.Команда була змушена писати архітектуру так, щоб відключення будь-якого вузла проходило непомітно для користувача. Впав сервер з рекомендаціями фільмів? Не біда, покажемо базовий каталог, але сам плеєр продовжить працювати. Додаток має елегантно деградувати, а не вмирати повністю.Як QA може використовувати цей підхід? (Не ламаючи прод)Ми можемо застосувати мислення "Хаос-мавпи" до наших щоденних завдань.🐒 Мережевий хаос: Під час завантаження великого файлу чи оплати кошика різко перемкніться з Wi-Fi на 3G (через DevTools) або взагалі вимкніть інтернет на 5 секунд. Додаток крашнувся чи поставив дію на паузу і відновив потім? 🐒 Хаос даних: Підмініть відповідь від бекенду через інструменти типу Charles Proxy або Postman. Замість очікуваного масиву товарів відправте null, пустий об'єкт {} або взагалі текст 500 Server Error. Фронтенд впаде з білим екраном чи покаже красиву заглушку "Щось пішло не так"? 🐒 Хаос ресурсів: Запустіть стрес-тест на своєму комп'ютері (щоб забити 100% процесора та пам'яті) і спробуйте попрацювати у вашому веб-додатку. Чи не відвалюються тайм-аути? Чи не "розсипаються" анімації? Висновок:Ідеальних умов не існує. Якщо ви тестуєте продукт тільки в "тепличних" умовах стабільного Wi-Fi та ідеальних тестових даних, ви залишаєте всю брудну роботу реальним користувачам. Станьте Хаос-мавпою для свого проєкту! 🍌А ви коли-небудь навмисно "ламали" оточення під час тестування?🔥 — Постійно! Висмикую кабелі, мокаю помилки, влаштовую хаос!👀 — Звучить круто, треба буде стати "мавпою" на наступному релізі.🤷‍♂️ — Нам би позитивні сценарії встигнути пройти...

🦠 "Хто тестує ваші тести?": Знайомтесь із Мутаційним тестуваннямПривіт, екіпаж! З п'ятницею! ☕️Сьогодні розберемо техніку, яка руйнує головну ілюзію в IT і змушує навіть Senior QA покриватися холодним потом.Уявіть ситуацію: команда автоматизаторів написала сотні тестів. Ви запускаєте CI/CD — усе зелене. Менеджер бачить красивий звіт "Code Coverage (Покриття кодом) 95%" і радісно відкриває шампанське.Але чи гарантує це, що ваші тести дійсно здатні знайти баг? Насправді, ні. Вони можуть просто виконувати код, але забути перевірити сам результат (немає assert).Як перевірити якість самих тестів? На сцену виходить Мутаційне тестування (Mutation Testing).Як це працює?Замість того, щоб шукати баги в програмі, спеціальний інструмент (наприклад, Stryker або PIT) навмисно ламає код вашого продукту.Він створює так званих "Мутантів", вносячи в код дрібні помилки: 🔹Змінює > на < (було "вік > 18", стало "вік < 18").🔹Змінює + на -.🔹Видаляє виклики важливих функцій.🔹Змінює true на false. Далі система запускає ваші ідеальні "зелені" автотести на цьому зламаному коді.Що має статися?Ваш тест ПОВИНЕН впасти (почервоніти). Якщо автотест упав — він "вбив мутанта". Ви молодець, ваш скрипт дійсно контролює логіку.Але якщо код зламаний, а ваш тест залишився зеленим... Вітаю, Мутант вижив! 🧟‍♂️Це означає, що ваш автотест — пустушка. Ви витратили час на написання тесту, який ніколи не знайде реальну помилку на продакшені, бо він просто ігнорує ці зміни.Чому це важливо?Звична метрика Code Coverage бреше. Можна написати тест, який пройде по всіх рядках коду, але нічого не перевірить. А от Mutation Score (відсоток вбитих мутантів) — це найчесніший показник якості тестування.Висновок для Manual QA:Цей принцип геніально працює і в ручному тестуванні! Іноді корисно навмисно ввести абсолютно абсурдні дані (створити свого "мутанта"), щоб перевірити, чи ваша система взагалі здатна видати помилку, чи ви просто звикли ходити лише "щасливим шляхом".А ви коли-небудь чули про Мутаційне тестування?🔥 — Знаю і бачив(ла), як це працює!👀 — Вперше чую, концепція просто вогонь!🤷‍♂️ — Нам би звичайні тести написати, які там мутанти...

📱 «А що, якщо подзвонить мама?» Головний кошмар мобільного тестувальникаПривіт, екіпаж! Четвер — саме час поговорити про біль, який знайомий кожному, хто хоч раз тестував мобільні додатки. ☕️Сьогодні розберемо вид тестування, про який часто забувають новачки, але який приносить найобразливіші (і найдорожчі) баги на продакшені. Це Interruption Testing (Тестування переривань).Уявіть типовий сценарій:Користувач заповнює величезну форму заявки в банківському додатку або вводить дані картки для оплати. Він витратив 5 хвилин, заповнив 20 полів, натискає «Підтвердити»... і в цю саму частку секунди йому дзвонить мама.Або спрацьовує будильник.Або на весь екран вилазить системне сповіщення «Залишилося 10% заряду батареї».Додаток іде у фон. Користувач розмовляє по телефону пару хвилин, а потім повертається у ваш продукт. Що він там побачить?Погляд "під капот" (чому все ламається):Мобільні ОС (Android та iOS) — це дуже агресивне середовище. На відміну від десктопу, оперативна пам'ять тут суворо обмежена. Коли додаток переходить у фоновий режим (Background), операційна система може в будь-який момент безжалісно «вбити» його процес, щоб звільнити пам'ять для "дзвонилки" або важкої гри.Якщо розробник забув реалізувати State Restoration (Збереження та відновлення стану), станеться катастрофа. Повернувшись, користувач побачить білий екран перезавантаження. Всі його дані зникнуть, кошик очиститься, а флоу оплати зависне в невизначеному статусі (гроші списалися, а екран успіху не показався). Підсумок — лють і видалення додатка.Як крутий QA має це тестувати?☎️ Дзвінки та сповіщенняПрямо в момент завантаження важкого екрана або відправки форми подзвоніть на тестовий девайс з іншого телефону. Скиньте дзвінок через 10 секунд. Додаток не повинен «крашнутися» або втратити фокус. 🎮 Стрес-тест пам'яті (Don't keep activities)Згорніть тестований додаток, відкрийте камеру, Google Maps і пару важких ігор (щоб забити RAM), а потім поверніться назад. В Android для цього навіть є спеціальна галочка в налаштуваннях розробника: «Не зберігати дії (Don't keep activities)», яка вбиває UI відразу при згортанні. Це ідеальний спосіб перевірити збереження стану. 🔌 Апаратні перериванняВитягніть зарядний кабель, підключіть Bluetooth-навушники або різко увімкніть «Авіарежим» прямо під час анімації лоадера. Система повинна відпрацювати це елегантно. Висновок:Мобільний телефон — це хаос. Ваш додаток там не головний, і юзера будуть постійно відволікати. Завдання професійного QA — переконатися, що додаток вміє виживати в цих умовах і поважає час користувача, зберігаючи кожен введений ним символ.А як у вас із мобільним тестуванням?🔥 — Постійно дзвоню на тестові девайси і згортаю апки!👀 — Перевіряли тільки авіарежим, про дзвінки якось забули...🤷‍♂️ — Я тестую тільки Web, у мене таких проблем немає!

🏎 "Стан перегонів" (Race Condition): Як подвійний клік краде гроші бізнесуПривіт, екіпаж! Екватор тижня — ідеальний час для технічної магії. ☕️Уявіть ситуацію: користувач купує останній акційний ноутбук в інтернет-магазині. Інтернет трохи "тупить", кнопка "Оплатити" не реагує миттєво. Користувач нервує і клікає на неї тричі поспіль.Що відбувається далі? З картки списуються гроші три рази, система створює три замовлення на один і той самий "останній" ноутбук, а на складі починається паніка.Вітаю, ви зустріли Race Condition (Стан перегонів).Чому це відбувається "під капотом"?Коли сервер отримує три запити одночасно, він починає обробляти їх паралельно (у різних потоках). 🔹Потік 1 питає базу: "Ноутбуки є?". База: "Так, 1 штука".🔹Потік 2 в ту саму мілісекунду питає: "Ноутбуки є?". База ще не встигла оновитися і відповідає: "Так, 1 штука".🔹Потік 3 чує те саме. У результаті сервер радісно продає один фізичний товар трьом різним людям, заганяючи залишки на складі в мінус.Як крутий QA має це тестувати?👆 "Паркінсон" на UIНайпростіший тест — просто швидко-швидко клікати на будь-які деструктивні кнопки: "Зберегти", "Відправити", "Оплатити", "Видалити".Часто розробники забувають зробити кнопку неактивною (disabled) одразу після першого кліку, залишаючи вікно вразливості. 🐌 Метод "Повільного інтернету"Якщо інтернет швидкий, ви просто не встигнете клікнути двічі. Тому відкриваємо DevTools -> Network -> ставимо Slow 3G. Тепер запит "висить" 5 секунд, і у вас є купа часу, щоб натиснути кнопку ще 10 разів. 🤖 API-бомбардуванняUI-блокування кнопки — це лише захист від дурня. Хакер просто обійде UI і відправить запити напряму. Беремо Postman або JMeter і відправляємо 20 однакових POST-запитів в одну секунду паралельно. Якщо створилося 20 записів — архітектура бекенда дірява. Як це фіксять здорові команди?Надійні системи використовують Ідемпотентність (idempotency keys) — коли разом із запитом передається унікальний ID транзакції. Навіть якщо клієнт надішле 10 однакових запитів, сервер зрозуміє, що це дублі, і виконає дію лише один раз. Інший варіант — строгі блокування (Locks) на рівні самої бази даних.А ви перевіряєте критичні форми на подвійний клік?🔥 — Завжди клікаю як скажений(а)!👀 — Тестую на UI, але в API не ліз...🤷‍♂️ — Якщо юзер клікає двічі, це його проблеми!