🪲 "Парадокс пестициду": Чому ваші найкращі тест-кейси стають сліпими

Наближаються вихідні, тож розберемо один дуже цікавий феномен. ☕️

У сільському господарстві є відома проблема: якщо фермер роками кропить поле одним і тим самим пестицидом, комахи-шкідники поступово мутують і виробляють до нього імунітет. Пестицид перестає працювати, а врожай гине.

В IT-індустрії існує абсолютно такий самий закон — Парадокс пестициду (Pesticide Paradox).

Його суть: Якщо ви будете постійно проганяти один і той самий набір тест-кейсів, з часом ці тести перестануть знаходити НОВІ баги.

Чому так відбувається?

👨‍💻 Синдром "Підготовки до іспиту"

Розробники — люди розумні. Якщо вони знають ваш стандартний чек-лист (або бачать код ваших автотестів), вони підсвідомо починають писати код так, щоб він пройшов саме ці перевірки. Вони "латають" відомі вам дірки, але можуть випадково створити нові там, куди ви ніколи не дивитесь. Ваш тест стає зеленим, але продукт — ні.

🏛 Тести перетворюються на музей

Продукт розвивається: додаються нові фічі, змінюється логіка, переписується архітектура. А старий добрий регресійний набір тестів лежить без змін роками. Він перевіряє те, що і так стабільно працює, ігноруючи нові, найнебезпечніші зони ризику.

Як оновити свій "пестицид" і знову почати знаходити критичні баги?

🌪 Зміна маршрутів (Exploratory Testing)

Хоча б 20% часу виділяйте на Дослідницьке тестування. Відкладіть документацію, вимкніть автотести і підіть туди, куди нормальний користувач ходити не повинен. Натискайте кнопки у зворотному порядку, переривайте процеси, використовуйте нестандартні дані.

🔄 Регулярна ревізія тестів

Тест-кейси мають термін придатності. Раз на кілька місяців проходьтесь по своїй базі в TestRail (чи де ви їх ведете) і безжалісно видаляйте або об'єднуйте тести, які не знаходили багів останні пів року. Вони лише крадуть ваш час.

🎲 Рандомізація даних

Якщо ваш тест завжди створює юзера з іменем "Test" і віком 25 років — змініть це. Використовуйте генератори випадкових даних (Faker). Сьогодні хай це буде "Хуан" віком 99 років, а завтра — "Оля" з від'ємним балансом.

Висновок:
Тестування — це не статичний процес. Це постійна гонка озброєнь між складністю системи та винахідливістю QA. Якщо вам стало занадто комфортно і ваші тести завжди зелені — час міняти отруту. ☠️

А як часто ви переписуєте чи видаляєте старі тест-кейси?
🔥 — Регулярно проводимо ревізію і чистимо сміття!
👀 — Пишемо нові, але старі бояться чіпати...
🤷‍♂️ — У нас взагалі немає тест-кейсів, суцільний експлораторі!

🔥 Хаос-інженерія: Навіщо 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 та ідеальних тестових даних, ви залишаєте всю брудну роботу реальним користувачам. Станьте Хаос-мавпою для свого проєкту! 🍌

А ви коли-небудь навмисно "ламали" оточення під час тестування?
🔥 — Постійно! Висмикую кабелі, мокаю помилки, влаштовую хаос!
👀 — Звучить круто, треба буде стати "мавпою" на наступному релізі.
🤷‍♂️ — Нам би позитивні сценарії встигнути пройти...

🏔 Ефект Даннінга-Крюгера: Чому Senior QA завжди відчуває себе самозванцем

Привіт, екіпаж! Понеділок — час для саморефлексії та психології. ☕️

Ви коли-небудь помічали цей парадокс? Джуніор, який закінчив тримісячні курси, впевнено розповідає, як треба будувати процеси, і вважає себе богом автоматизації після першого скрипта на Selenium. А Lead QA з 8 роками досвіду перед кожним складним релізом думає: "Господи, я ж насправді нічого не розумію, мене скоро викриють і звільнять".

У психології це називається Ефект Даннінга-Крюгера. Це когнітивне упередження, суть якого проста: люди з низьким рівнем кваліфікації роблять помилкові висновки, приймають невдалі рішення і... не здатні усвідомити свої помилки через свій низький рівень кваліфікації.

Як цей графік виглядає в кар'єрі тестувальника?

🚀 "Пік дурості" (0-1 рік досвіду)

Ви вивчили теорію (що таке баг-репорт, техніки тест-дизайну), навчилися відправляти GET-запити в Postman і написали автотест для логіну.
Думка в голові: "Тестування — це елементарно! Я знаю все. Розробники постійно косячать, а я їх рятую". Ви на вершині впевненості. Ви не бачите підводних каменів, бо навіть не підозрюєте про їх існування.

📉 "Долина відчаю" (2-4 роки досвіду)

Ви потрапляєте на серйозний проєкт. Виявляється, що Postman — це крапля в морі. На вас падають CI/CD пайплайни, Docker-контейнери, мікросервісна архітектура, балансувальники навантаження, Flaky-тести, які падають через анімації, і баги бази даних.
Думка в голові: "Я тупий. Я взагалі нічого не розумію в IT. Як я сюди потрапив?".
Тут народжується жорсткий Синдром самозванця. Ваша впевненість падає до нуля, хоча ваші РЕАЛЬНІ знання виросли в 10 разів.

🧗‍♂️ "Схил просвітлення" (5+ років досвіду)

Ви починаєте збирати себе до купи. Ви розумієте, що знати ВСЕ — неможливо. Ви більше не намагаєтесь покрити 100% коду автотестами. Ви вчитеся керувати ризиками, задавати правильні запитання бізнесу і тестувати архітектуру ще до написання коду.
Думка в голові: "Я знаю достатньо, щоб розібратися в чому завгодно, якщо дати мені трохи часу і документацію".

Висновок:
Якщо ви зараз сидите над складною задачею, дивитесь у код або логи і відчуваєте себе повним самозванцем, якому просто пощастило влаштуватися на роботу — видихніть і прийміть мої вітання.
Це означає, що ви злізли з "Піку дурості" і реально розвиваєтесь як професіонал.

А на якому етапі графіка ви відчуваєте себе просто зараз?
🔥 — Сиджу в "Долині відчаю", синдром самозванця б'є ключем!
👀 — Десь на "Схилі просвітлення", прийняв(ла) цей IT-дзен.
🤷‍♂️ — Я на "Піку"! Мені море по коліна, тестування — це ізі!

🚀 Як один неперевірений ліміт знищив $500 мільйонів: Магія граничних значень

Привіт, екіпаж! Вівторок — ідеальний день, щоб згадати, чому наша професія буквально рятує компаніям мільйони (а іноді й мільярди). ☕️

Всі ми вчили на курсах чи з книжок таку нудну техніку тест-дизайну, як Аналіз граничних значень (Boundary Value Analysis). Здається, що це суха теорія: "Якщо поле приймає від 1 до 100, перевір 0, 1, 100 і 101".
Але давайте подивимось, що буває, коли цю техніку ігнорують на найвищому рівні.

Історія найдорожчого багу:

4 червня 1996 року. Європейське космічне агентство запускає новітню ракету Ariane 5. Через 37 секунд після старту вона відхиляється від курсу і епічно вибухає в повітрі. Збитки склали понад $500 мільйонів.

Що сталося? Розслідування показало, що баг був у програмному забезпеченні. Софт намагався конвертувати значення горизонтальної швидкості (велике 64-бітне число) у звичайну 16-бітну змінну.
Максимальне значення, яке могла вмістити ця 16-бітна змінна, дорівнювало 32 767. Швидкість нової ракети виявилася вищою за цю межу.
Відбулося класичне переповнення (Integer Overflow), бортовий комп'ютер "зійшов з розуму", видав помилку і запустив механізм самознищення.

Як це стосується нашої щоденної роботи?

Ця історія — ідеальний доказ того, що баги майже ніколи не живуть у центрі бізнес-логіки. Вони обожнюють ховатися на краях.

Коли ви тестуєте будь-який ліміт (кількість символів у паролі, суму переказу, вік користувача), ваш головний удар має припадати саме на межі:

📏 Класичний підхід (3 значення)
Якщо ліміт введення — 100 символів, ви зобов'язані перевірити:

🔹99 (Just below) — має пройти успішно.

🔹100 (On the boundary) — має пройти успішно (тут розробники часто плутають < та <=).

🔹101 (Just above) — система має видати коректну помилку, а не впасти з 500-м статусом.

🕳 "Невидимі" архітектурні межі
Досвідчені QA знають, що існують системні ліміти, про які не пишуть у вимогах, але які обов'язково треба тестувати:

🔹255 / 256 символів (класичний ліміт для текстових полів у старих базах даних).

🔹2 147 483 647 (максимальне позитивне значення для 32-бітного Integer). Саме через це число свого часу зламався лічильник переглядів кліпу "Gangnam Style" на YouTube, змусивши Google терміново переписувати базу на 64-бітну.

Висновок:
Ніколи не вірте розробникам на слово, коли справа стосується "від і до". Комп'ютери ненавидять невизначеність на межах. Завжди перевіряйте той самий +1 і -1, щоб ваш проєкт не вибухнув, як Ariane 5.

А які у вас улюблені значення для краш-тестів полів вводу?
🔥 — Обожнюю перевіряти нулі та від'ємні числа!
👀 — Завжди б'ю по 256, класика ніколи не вмирає.
🤷‍♂️ — Вводжу 999999999, поки база даних не почне плакати!

🛑 Шпаргалка 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 найчастіше? 👇

🧠 QA-розминка #6: Пастка бази даних, яка ламає звіти

Привіт, екіпаж! Екватор тижня, час трохи розім'яти мізки. ☕️

Сьогоднішня задачка — це абсолютна класика SQL, через яку в компаніях розвалюються фінансові звіти, а QA пропускають критичні баги в аналітиці. Подивимось, чи потрапите ви в цю пастку.

Ситуація: Ви тестуєте адмінку. У базі даних є таблиця users, в якій рівно 10 записів.

Статуси користувачів розподілені так:

✅ status = 'active' (5 користувачів)
🚫 status = 'banned' (3 користувачі)
👻 status = NULL (2 користувачі, ще не підтвердили email)

Менеджер просить вас: "Виведи мені кількість усіх користувачів, які зараз НЕ забанені".
Ви, як справжній QA, швидко пишете логічний запит:

SELECT COUNT(*) FROM users WHERE status != 'banned';

Питання: Яку цифру поверне вам база даних після виконання цього запиту?

👇 Голосуйте в анонімному опитуванні! Перешліть цю задачку своїм колегам — подивимось, скільки з них дадуть правильну відповідь. Розбір пастки опублікую ввечері!

🎯 Розбір задачки: Куди зникли люди з бази?

Дякую за ваші голоси! Якщо ви обрали варіант "5 (База знайде тільки 'active')" — ви суперзірка SQL і не потрапили в пастку! 🏆

Більшість людей інтуїтивно обирає 7, міркуючи так: "Ну, якщо статус NULL (пусто), то він же точно не дорівнює 'banned', правда?".

А от і ні. У SQL інша математика.
SQL використовує так звану Тризначну логіку (True, False, Unknown).
NULL — це не нуль і не пустий рядок. Це Невідомість.

Коли база даних перевіряє користувача з status = NULL, вона запитує себе:
"Чи дорівнює Невідомість рядку 'banned'?".
Відповідь бази: "Я не знаю (Unknown)".

А оператор WHERE пропускає у фінальну вибірку ТІЛЬКИ ті рядки, де умова дала чітке TRUE. Усе, що Unknown, мовчки відкидається. Тому двоє людей з NULL просто зникають зі звіту, і менеджер отримує неправильні дані.

Як це фіксять здорові QA?
Якщо вам треба врахувати NULL, запит має виглядати так:

SELECT COUNT(*) FROM users WHERE status != 'banned' OR status IS NULL;

(Або через використання функції COALESCE).

Висновок:
Ніколи не порівнюйте NULL через знаки = або !=. Тільки IS NULL або IS NOT NULL. Якщо ви перевіряєте аналітику або експорти — завжди згадуйте про цю пастку!

🔥 — якщо знали про цю фічу SQL!
🤯 — якщо сьогодні дізналися щось нове.

🛠 Шпаргалка 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 важко жити

Привіт, екіпаж! Суботній вечір, ви нарешті закрили лептоп, вимкнули сповіщення з Jira і пішли відпочивати. Але є одна проблема: мозок тестувальника вимкнути неможливо.

Професійна деформація в нашій професії настає дуже швидко. Зізнайтеся, скільки пунктів із цього списку — про вас?

🍽 QR-меню в ресторанах

Замість того, щоб просто обрати піцу, ви знаходите з'їхалу верстку на мобільній версії сайту закладу. Ви підсвідомо перевіряєте, чи можна додати в кошик -1 порцію картоплі фрі, а коли оплата не проходить, лізете перевіряти консоль браузера з телефону. Друзі вже доїдають, а ви шукаєте баги.

🚪Ліфти, двері та турнікети

Звичайна людина просто натискає кнопку свого поверху. QA обов'язково спробує натиснути три кнопки одночасно (Race Condition), потримати двері рукою під час закриття (Interruption Testing) і перевірити, чи поїде ліфт, якщо перевищити вантажопідйомність на 1 кг (Boundary Value).

🛒 Покупки в інтернеті

Ви просто хотіли купити нові кросівки. Але випадково ввели спецсимволи <script> в поле для промокоду, побачили, що сайт впав з 500-ю помилкою, і замість шопінгу сіли писати безкоштовний баг-репорт у техпідтримку магазину.

🎮 Кіно та відеоігри

Ви не можете просто насолоджуватися сюжетом гри. Ви йдете в куток карти і починаєте стрибати в стіну, сподіваючись провалитися крізь текстури. А в кіно помічаєте, що в одному кадрі годинник показує 15:00, а в наступному — 12:30. "Баг стейту!", — кричить ваш внутрішній голос.

Висновок: Бути тестувальником — це не просто робота, це фільтр, через який ми дивимося на світ. Ми бачимо недосконалості там, де інші бачать норму.

📌 Перешліть цей пост своїм друзям та коханим, щоб вони нарешті зрозуміли, чому ви так дивно поводитеся в побуті! 😂

А тепер зізнавайтеся в коментарях: який найсмішніший (або найбезглуздіший) баг ви знаходили в реальному житті? 👇

💣 Шпаргалка 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" без авторизації і дивлюсь, що буде

🎭 Театр якості: Чому 100% автотестів та ідеальна Jira не рятують продакшен?

Привіт, екіпаж! ☕️

Я помітив, що наші останні обговорення в каналі виходять далеко за межі звичайних багів. Ми все частіше говоримо про те, як зламані самі процеси розробки. Тому я вирішив зібрати наші найкращі думки і написати велику, чесну статтю.

Вона про те, чому сучасне IT часто займається імітацією тестування замість пошуку реальних проблем.

У статті розібрав три головні пастки:

🐍 Ефект кобри: Як KPI на кількість багів змушують QA шукати пікселі, що з'їхали, ігноруючи діри в архітектурі.

🪲 Парадокс пестициду: Чому ваші ідеально зелені автотести з часом стають повністю сліпими.

✈️ Карго-культ автоматизації: Навіщо ми намагаємось автоматизувати 100% інтерфейсу, уподібнюючись аборигенам, які будують літаки з бамбука.

👉 Читати повну статтю на Medium: Театр якості в IT: Чому ваші “ідеальні” процеси QA не покращують продукт

P.S. Буду дуже вдячний, якщо ви перейдете за посиланням і "поплескаєте" 👏 статті в самому низу (на Medium можна плескати до 50 разів одній статті!). Це дуже допоможе просунути матеріал і залучити нових крутих спеціалістів у наше ком'юніті!

Повертайтеся в коментарі після прочитання, обговоримо! 👇

🚩 "Кнопка самознищення": Чому 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 — це множник складності. Кожен тогл — це дві паралельні реальності вашого додатка.

А ви використовуєте фіча-тогли на своєму проєкті? 👇
🔥 — О так, постійно ховаємо за ними недоробки!
👀 — Буває, але намагаємось швидко їх видаляти.
🤯 — Жодних тоглів, релізимо тільки хардкором!

🍕 Баг вартістю в мільйони: Чому 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 ганяємо, але без фанатизму.
🤯 — Яка клавіатура? У нас би "щасливий шлях" мишкою пройти без крашів!

🪄 Магія 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 для такого.
🤯 — Просив(ла) розробників хардкодити помилки... Тепер буду робити сам!

💳 Подвійне списання грошей: Що таке Ідемпотентність 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!

🚨 Пастка "200 OK": Чому GraphQL ламає ваші звички в тестуванні API

Всі ми звикли до класичного REST API. Там усе логічно: запитав неіснуючу сторінку — отримав 404 Not Found. Сервер впав — тримай 500 Internal Server Error. Немає прав — 403 Forbidden. Більшість наших автотестів роками трималися на простому assert(response.status == 200).

Але якщо ваш проєкт переходить на GraphQL (сучасну альтернативу REST), забудьте все, що ви знали.

Головний біль GraphQL для QA:

GraphQL — оптиміст. Він майже ЗАВЖДИ повертає HTTP-статус 200 OK.
Навіть якщо запит був кривим. Навіть якщо юзер не авторизований. Навіть якщо база даних у цей момент палає.

Як виглядає ця "зрада"?

Ви відправляєте запит у Postman, бачите зелений 200 OK, радісно закриваєте тікет... А фронтенд чомусь падає з білим екраном.
Ви відкриваєте тіло відповіді (Response Body), а там:

{
  "data": null,
  "errors": [
    {
      "message": "Internal Server Error: Database connection timeout",
      "locations": [ { "line": 2, "column": 3 } ]
    }
  ]
}

Сервер буквально каже: "Запит я прийняв успішно (тому 200), але виконати його не зміг, ось тобі масив з помилками".

Чому це катастрофа для автоматизації?

Якщо ваші старі автотести просто перевіряють статус-коди, ваш CI/CD пайплайн буде ідеально зеленим, поки продакшен лежить у руїнах. Тест побачив 200 і пішов далі, проігнорувавши масив errors усередині.

Як тестувати GraphQL правильно?

🕵️‍♂️ Завжди парсіть тіло відповіді (Body)

У Postman (або в коді автотестів) ваша перша перевірка має виглядати не як перевірка статусу, а як перевірка на відсутність масиву помилок:

pm.expect(pm.response.json().errors).to.be.undefined;

✂️ Тестуйте часткові збої (Partial Failures)

Фіча GraphQL у тому, що в одному запиті можна попросити ім'я юзера і список його покупок. Якщо сервіс покупок впав, GraphQL все одно поверне статус 200, віддасть ім'я юзера, а замість покупок напише null і додасть помилку в масив errors. Перевіряйте, як ваш UI реагує на такі "напівробочі" відповіді!

Висновок: Нові технології вимагають нових підходів. У світі GraphQL довіряти статусу 200 — це як вірити напису "На паркані написано". Завжди заглядайте всередину!

А на вашому проєкті використовують GraphQL чи сидите на старому доброму REST? 👇
🔥 — У нас GraphQL, і ми парсимо кожну помилку в Body!
👀 — Тільки REST, нам ці ваші нововведення не потрібні.
🤯 — Трясця, піду перевірю наші автотести... здається, ми перевіряємо тільки статуси!

⚡️ Магія реального часу: Як тестувати WebSockets (і чому REST тут безсилий)

Привіт, екіпаж! ☕️

Уявіть ситуацію: ви дивитесь фінал Ліги Чемпіонів або напружений титульний бій UFC. Рахунок на табло або коефіцієнти в лайві змінюються кожну секунду, залежно від того, хто зараз атакує. Ви ж не сидите і не натискаєте F5 щосекунди, щоб побачити нові цифри? Вони оновлюються самі, миттєво.

Як це працює? Тут закінчується влада класичного REST API і починається територія WebSockets (WS).

У чому різниця "на пальцях"?

🔹REST API — це як відправка листів поштою. Клієнт питає: "Який зараз коефіцієнт?", сервер відповідає: "Ось такий", і вони прощаються. Щоб дізнатися нову цифру, треба писати новий лист.

🔹WebSocket — це телефонна розмова. Клієнт дзвонить серверу, вони "тиснуть руки" (Handshake) і не кладуть слухавку. Тепер сервер може сам, без запиту, кричати в трубку: "Гол! Коефіцієнт змінився!". Зв'язок постійний і двосторонній.

Як Manual QA має тестувати цю магію?
Звичайні інструменти тут працюють інакше. Ось ваш план дій:

🕵️‍♂️ Як їх взагалі побачити?

Відкрийте Chrome DevTools (F12) -> вкладка Network -> фільтр WS (замість звичного Fetch/XHR).

Оновіть сторінку. Ви побачите один запит зі статусом 101 Switching Protocols. Клікніть на нього і перейдіть у вкладку Messages. Саме тут ви побачите безперервний потік "зелених" (відправлених) і "червоних" (отриманих) повідомлень у реальному часі.

✂️ Тест на "Обрив зв'язку" (Reconnect Strategy)

Це найголовніший тест для сокетів. Що буде, якщо юзер зайшов у ліфт і втратив мережу на 10 секунд?

Як перевірити: Увімкніть Offline у DevTools (Network -> Throttling). Почекайте 5 секунд. Потім знову увімкніть No Throttling.

Очікуваний результат: Додаток не повинен "зависнути" назавжди або викинути білий екран. Він має тихо перепідключити WebSocket і "довантажити" ті повідомлення чи зміни коефіцієнтів, які юзер пропустив у ліфті.

🏓 Пінг-Понг (Heartbeat)

Щоб сервер знав, що ви ще живі і не закрили вкладку, браузер постійно шле йому короткі повідомлення (Ping), а сервер відповідає (Pong).

Відкрийте вкладку Messages і переконайтеся, що цей обмін відбувається (зазвичай раз на 30-60 секунд). Якщо цього немає — з'єднання буде постійно відвалюватись по тайм-ауту.

Висновок: Якщо ви тестуєте чати, біржі, крипту, стрімінги або лайв-події — ви зобов'язані вміти читати трафік WebSockets. Без цього ви будете заводити баги на фронтенд, хоча насправді просто відвалилася "телефонна лінія" з сервером.

А ви тестували коли-небудь WebSockets? 👇
🔥 — Так, постійно сиджу у вкладці Messages!
👀 — Тільки REST, до сокетів ще не дійшли.
🤯 — Я думав(ла), дані самі магічно оновлюються...