QA Co-pilot

⏰ Timezone Hell: Чому ваші юзери "старіють" на день швидше (і як це тестувати)Привіт, екіпаж! Сьогодні розберемо баг, який хоч раз у житті ламав мозок кожному айтішнику. ☕️Уявіть ситуацію: користувач заходить у свій профіль і вказує дату народження — 10 жовтня. Тисне "Зберегти". Оновлює сторінку, а там... 9 жовтня. Він знову ставить 10-те, зберігає — а сторінка вперто показує 9-те. Юзер лютує, саппорт розривається.Ласкаво просимо в Timezone Hell (Пекло часових поясів).Чому це відбувається?У програмуванні час — це не просто "10:00". Це складна структура. Головне правило здорової архітектури: Бекенд завжди зберігає час у UTC (Всесвітній координований час, +0). А фронтенд вже переводить його в локальний час користувача.Але розробники постійно в цьому плутаються: 1️⃣Фронтенд бере локальну дату Києва (UTC+3) і відправляє на сервер.2️⃣Сервер думає: "Ага, мені прислали дату, відніму-но я 3 години, щоб зберегти в UTC".3️⃣Дата народження (яка стояла як 00:00 10 жовтня) перетворюється на 21:00 9 жовтня!4️⃣При поверненні даних фронтенд забуває додати ці 3 години назад, або бекенд відрізає години взагалі. Результат — день народження змістився. Або ще гірше: юзер з Нью-Йорка купує квиток на концерт у Лондоні. У якому часі має показуватися початок події? Якщо показати в локальному часі юзера — він запізниться на рейс.Як QA має тестувати дати? (Чек-лист виживання)Зробіть це прямо сьогодні на своєму проєкті, і ви гарантовано знайдете пару багів:🌍 Тест "Мандрівника у часі"Не міняйте нічого в коді. Просто зайдіть у налаштування вашого Windows/macOS (або в DevTools Chrome: Sensors -> Location) і змініть свій часовий пояс на Токіо (UTC+9), а потім на Лос-Анджелес (UTC-8).Пройдіть флоу створення сутності (поста, транзакції, бронювання). Подивіться, чи не з'їхали дати в таблицях і графіках на вчора/завтра. 🧛‍♂️ "Вампірський" тест (Рівно північ)Більшість багів з датами вилазить на стику днів. Створюйте події або звіти з часом рівно 00:00 або 23:59. Це ідеальні крайові значення (Boundary Values), де найчастіше "відкушується" або додається зайвий день при конвертації. 🔀 Формат ISO 8601Відкрийте Network і подивіться, як фронт відправляє дати. Якщо ви бачите щось на кшталт "10-10-2025" — бийте на сполох. Формат має бути стандартизованим, наприклад: 2025-10-10T15:30:00.000Z (де літера Z в кінці означає Zulu time, тобто чистий UTC). Висновок: Якщо ваш додаток працює більш ніж в одній країні — робота з датами має бути покрита залізобетонними тестами. І ніколи не дозволяйте розробникам писати власні конвертери часу — для цього є готові перевірені бібліотеки.А ви стикалися з "магічним" зникненням або появою днів у календарях? 👇🔥 — О так, баги з UTC — це класика нашого проєкту!👀 — Завжди думав(ла), що дати це просто текст...🤯 — Прямо зараз іду міняти часовий пояс на Токіо і ламати прод!

🏎 Як вкрасти подвійний бонус: Що таке Race Condition і чому мишка тут не допоможеПривіт, екіпаж! Сьогодні заліземо в ту частину бекенду, від якої сивіють розробники та власники бізнесу. ☕️Уявіть класичну ситуацію: ви реєструєтесь у додатку доставки і отримуєте промокод на 500 грн. Ви додаєте в кошик піцу, вводите код і тиснете «Застосувати». Все працює, знижка зарахована.А тепер уявіть, що ви відкрили свій акаунт одночасно на телефоні, планшеті та комп'ютері. Ви підготували кошики і натиснули кнопку «Застосувати промокод» на всіх трьох пристроях в одну й ту саму мілісекунду.Якщо бекенд написаний без урахування паралелізму, станеться магія, яка називається Race Condition (Стан гонитви).Що відбувається "під капотом"?Сервер отримує три запити одночасно і починає їх обробляти в трьох паралельних потоках: 🔹Потік 1: Промокод ще дійсний? Так.🔹Потік 2: Промокод ще дійсний? Так (бо Потік 1 ще не встиг позначити його як використаний!).🔹Потік 3: Промокод ще дійсний? Так. Далі всі три потоки нараховують вам по 500 грн знижки, і лише після цього ставлять у базі даних галочку is_used = true. Вітаю, ви щойно отримали 1500 грн знижки з одного промокоду на 500.Такі ж баги дозволяють знімати гроші в мінус з банківських карток, купувати два товари, коли на складі залишився лише один, або накручувати лайки.Як QA має це тестувати? (Краш-тест на паралельність)Звичайним швидким кліканням мишки ви цей баг не зловите (фронтенд просто заблокує кнопку після першого кліку). Нам потрібна важка артилерія.⚔️ Запускаємо паралельні потоки через PostmanБагато хто знає про Collection Runner у Postman, але за замовчуванням він відправляє запити по черзі (один за одним). Це не створить Race Condition.Щоб вдарити по серверу одночасно, вам потрібен інструмент рівня JMeter або крута фіча в самому Postman, яка з'явилася не так давно — скрипти з асинхронними запитами (pm.sendRequest), які запускаються циклом for без очікування відповіді.Або ще простіше — консольна утиліта cURL + трохи магії терміналу (Bash):Відкриваєте термінал і пишете команду, яка відправляє 10 однакових запитів на використання промокоду, ставлячи знак & в кінці кожного. Вони полетять на бекенд ідеально паралельно. Висновок: Якщо ваш продукт працює з грошима, знижками, складом або балансами — ви зобов'язані тестувати API на Race Condition. Бо якщо цього не зробите ви, це зроблять дуже хитрі користувачі.А ви коли-небудь ловили баги паралелізму на своєму проєкті? 👇🔥 — Так, блокуємо таблиці в базі даних (Pessimistic/Optimistic Locks), все надійно!👀 — Жодного разу так не тестував(ла), сподіваюсь, у нас все ок...🤯 — Прямо зараз піду мультиплікувати свої бонуси на проді!

🟢 Відповідь на вчорашній тест: Чому статус 404 від бекенда може "вбити" ваш фронтендПривіт, екіпаж! ☕️Вчора я закинув вам задачку з реальної співбесіди: Який статус має повернути запит GET /api/users, якщо в базі ще немає жодного користувача?Багато хто злякався відповідати публічно (і я вас розумію, питання із зірочкою!), але респект тим сміливцям, хто не побоявся піти в коментарі! 🤝Давайте розбирати, чому неправильна відповідь гарантовано кладе продакшен.❌ Варіант 1: 404 Not Found (Найпопулярніша помилка) Логіка кандидата: "Ну юзерів же немає, значить Not Found".Чому це фатально: Статус 404 означає, що не знайдено сам ресурс (ендпоінт), а не дані в ньому. Уявіть папку на комп'ютері. Якщо папка "Фото" порожня — вона все одно існує! 404 доречний тільки тоді, коли ми шукаємо конкретну людину: GET /api/users/99, а 99-го юзера немає. Якщо ж ми просимо весь список і отримуємо 404, фронтенд подумає, що сервер зламався або API змінилося, і покаже юзеру екран із червоною помилкою. ❌ Варіант 2: 204 No Content Логіка кандидата: "Запит пройшов, але віддавати нічого".Чому це фатально для фронтенду: Сучасний фронтенд (Angular/React) малює списки через цикли (наприклад, метод .map()). Він очікує отримати масив. Статус 204 повертає абсолютно порожнє тіло відповіді. Коли фронтенд спробує зробити null.map(), додаток просто крашнеться з помилкою і юзер побачить білий екран. ✅ Правильна відповідь: 200 OK (і порожній масив [] у тілі)Логіка здорової архітектури: Запит був коректним? Так. Ендпоінт /users існує? Так. Ми успішно звернулися до бази даних? Так.Те, що зараз там немає людей — це нормальний бізнес-стан системи.Сервер повертає 200 OK та порожній масив [].Фронтенд отримує цей масив, розуміє, що його довжина дорівнює 0, і спокійно малює на екрані красиву заглушку: "Тут поки що нікого немає. Будь першим!". Ніяких крашів. Ніякої паніки. Висновок для QA:Коли тестуєте API, завжди перевіряйте "порожні" стани. Якщо ваш бекендер повертає 404 на порожній список — заводьте баг, поки фронтендери не прийшли до нього з вилами.А ви вгадали вчора правильну відповідь подумки? Зізнавайтесь реакціями! 👇🔥 — Так, знав(ла) що це 200 і порожній масив!👀 — Думав(ла) на 404, добре що не написав(ла) в коменти🤯 — Трясця, піду перевіряти, що віддає наш бекенд...

🚦 Тест на жадібність: Чому ваш API зобов'язаний вміти казати "Стоп" (і як це перевірити)Привіт, екіпаж! Сьогодні поговоримо про те, як захистити продукт від надто активних користувачів (або від ботів-шкідників). ☕️Уявіть ситуацію: конкурент вирішив "покласти" ваш сайт або хтось намагається підібрати пароль до адмінки (Brute-force). Вони пишуть простенький скрипт, який відправляє 10 000 запитів на секунду до вашого ендпоінту /login.Якщо ваш бекенд намагатиметься чесно обробити кожен із цих запитів — база даних "задихнеться", процесор перегріється, і продакшен впаде для всіх реальних клієнтів (класична DDoS атака).Щоб цього не сталося, нормальна архітектура використовує Rate Limiting (Обмеження запитів).Система запам'ятовує вашу IP-адресу (або токен) і каже: "Так, цьому хлопцю можна робити не більше 5 запитів на хвилину". Якщо ви відправите 6-й запит, сервер навіть не буде його обробляти. Він миттєво відіб'є його зі статусом 429 Too Many Requests.Як Manual QA має тестувати Rate Limiting?Не обов'язково бути хакером або писати складні скрипти на JMeter. Можна влаштувати міні-DDoS своїми руками:🏃‍♂️Метод Postman RunnerВідкриваєте Postman, створюєте звичайний запит (наприклад, на відновлення пароля). У правому нижньому кутку тиснете Runner. Перетягуєте туди свій запит, ставите Iterations: 50 і Delay: 0ms. Тиснете Run.Що шукати: Дивимось на статуси. Перші кілька мають бути 200 OK, а далі система має "захлопнути двері" і видавати суцільні 429. 🔁 Метод "Нервовий юзер" (cURL + Terminal) Клікаєте по запиту в DevTools -> Copy as cURL. Відкриваєте термінал (або командний рядок), вставляєте запит, додаєте в кінці & і так 20 разів підряд. Або просто швидко затискаєте Enter.Що шукати: Переконайтеся, що сервер не тільки віддає 429, але й додає заголовок Retry-After: 60 (який підказує фронтенду, що треба почекати 60 секунд перед наступною спробою). 📱UI-БлокуванняЯкщо ви зловили 429, як на це реагує інтерфейс? Фронтенд не повинен показувати користувачу "білий екран смерті" або сирі логи. Він має показати красиве повідомлення: "Ви відправляєте запити надто часто. Спробуйте через хвилину", а сама кнопка має заблокуватися (стати сірою), щоб уникнути подальших кліків. Висновок: Якщо ви тестуєте форми логіну, реєстрації, SMS-верифікації або використання промокодів — Rate Limiting має бути у вашому чек-листі під номером один. Інакше ваш бюджет на SMS з'їдять боти за півгодини.А у вас на проєкті налаштовані ліміти запитів? 👇🔥 — Так, 429 статус ловимо регулярно, все під контролем!👀 — Сподіваюсь, девопси там щось налаштували...🤯 — Завтра ж піду DDoS-ити нашу форму логіну через Postman!

🛑 Жорстока правда: Чому ваше зубріння теорії (і сертифікат ISTQB) не допоможуть пройти співбесідуПривіт, екіпаж! Сьогодні кидаю на вентилятор. Це тема, від якої у багатьох "книжкових" тестувальників почне палати, але хтось має це сказати прямо. ☕️Щодня на ринок виходять сотні кандидатів, які ідеально відскакують від зубів "7 принципів тестування". Вони можуть серед ночі розбудити вас і розповісти різницю між Severity та Priority, або намалювати таблицю класів еквівалентності. Вони витрачають місяці життя і сотні доларів на підготовку до сертифікації.А потім приходять на технічну співбесіду.Їм дають просту життєву задачу: "Ось мобільний додаток. При спробі логіну крутиться нескінченний спінер, помилки на екрані немає. Твої дії?"І тут настає тиша. Бо в підручниках не пишуть, що треба підключити телефон до проксі, подивитися, чи взагалі йде запит на бекенд, перевірити, чи не відвалився токен авторизації, і глянути логи бази даних.Чому чиста теорія мертва?📚Ілюзія компетентності Знати визначення багу — це не вміти його знаходити. Співбесідуючі (технічні ліди, а не ейчари) вже давно не питають термінологію. Їм плювати, як ви назвете дефект — аномалією чи інцидентом. Їм важливо, чи розумієте ви архітектуру клієнт-серверної взаємодії. 🗑 Відірваність від сучасної реальностіУ жодному базовому глосарії не написано, як тестувати мікросервіси, що робити з брокерами повідомлень (Kafka/RabbitMQ), як перехоплювати трафік або читати JSON. А саме це зараз вимагають на реальних проєктах, де крутяться серйозні гроші і де платять зарплати, здатні швидко закрити будь-які фінансові цілі. ⚔️ Синдром "Чек-ліста"Люди, які вчилися тільки за підручниками, тестують механічно. Вони йдуть тільки "щасливим шляхом". Вони бояться відхилитися від тест-кейсу, не намагаються зламати систему нестандартними даними і пасують перед плаваючими багами. Що з цим робити?Зупиніться. Перестаньте зубрити терміни. Почніть ламати.Відкрийте будь-який улюблений сайт, увімкніть DevTools, подивіться, які запити летять у Network. Змініть швидкість інтернету на 3G і спробуйте провести оплату. Зрозумійте, як продукт працює "під капотом".Практичний скіл і розуміння архітектури б'ють будь-який сертифікат. Завжди.📌 Скиньте цей пост тим, хто зараз готується до співбесід і витрачає час на зазубрювання глосарію замість практики!А тепер чекаю вас у коментарях для холівару 👇🔥 — Абсолютно згоден, на співбесідах питаю тільки хардкор і практику!👀 — Теорія і сертифікати дають базу, без неї нікуди, ви не праві.🤯 — Маю сертифікат, але на реальній роботі він жодного разу не знадобився...

💀 Найтупіший спосіб вбити будь-який мобільний додаток (і чому 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 — це множник складності. Кожен тогл — це дві паралельні реальності вашого додатка.А ви використовуєте фіча-тогли на своєму проєкті? 👇🔥 — О так, постійно ховаємо за ними недоробки!👀 — Буває, але намагаємось швидко їх видаляти.🤯 — Жодних тоглів, релізимо тільки хардкором!