QA Co-pilot

🛡 Золотий квиток на співбесіді: Чому QA має вивчити TypeScript просто заразПривіт, екіпаж! Минулого разу ми розібрали магію чистого JavaScript у консолі. Сьогодні я зніму шапку тестувальника і скажу вам дещо з позиції фронтендера, який щодня по вуха занурений в Angular та жорстку типізацію. ☕️Коли на технічному інтерв'ю кандидат каже: "Я пишу автотести на JS", це звучить нормально. Але коли він додає: "Я використовую TypeScript", рівень поваги від команди розробки злітає в космос.Сучасний Enterprise вже давно перейшов на TS. І ось 3 причини, чому для QA це найкраща інвестиція у свою кар'єру:🧱 Читання думок бекенду та фронтенду (Інтерфейси)Уявіть, що вам треба протестувати новий API-ендпоінт. Якщо ви знаєте TypeScript, ви просто відкриваєте Pull Request розробника і шукаєте interface.Ви одразу бачите:age?: number (ага, поле не обов'язкове, можна відправити без нього).status: 'active' | 'banned' (ага, треба спробувати відправити 'deleted' і подивитися, чи впаде 400-та помилка).Ви знаходите баги в архітектурі ще до того, як код потрапить на тестове середовище! 🛑 Смерть "дурним" багам в автотестахУ чистому JS ви можете передати текст у функцію, яка чекає на число. Тест успішно запуститься, пропрацює 15 хвилин і з ганьбою впаде десь на CI/CD пайплайні.TypeScript зловить вас за руку ще в редакторі коду. Він підкреслить помилку червоним і не дасть навіть запустити цей скрипт. Ви економите години на дебагу власних тестів. 🚀 Ідеальна синергія з сучасними інструментами Playwright та Cypress (сучасні королі автоматизації) працюють з TypeScript просто фантастично. Завдяки типізації, ваш редактор коду (VS Code) сам підказує вам усі доступні методи (автокомпліт). Вам не треба запам'ятовувати, як правильно написати перевірку — IDE зробить це за вас. Висновок: Вивчити базис TS після того, як ви вже знаєте трохи JS — це справа кількох вечорів. Там не так багато магії. Але на співбесідах (до речі, питання про різницю між JS та TS зараз задають майже кожному AQA) це дає вам величезну перевагу.А які у вас стосунки з TypeScript? 👇🔥 — Пишу на TS, сувора типізація — це любов!👀 — Поки вистачає чистого JS, але придивляюсь...🤯 — Я мануальник, для мене це поки що набір страшних літер!

💻 Хакни свою рутину: Чому мануальному QA життєво необхідно знати базис JavaScriptПривіт, екіпаж! Сьогодні поговоримо про те, як перестати бути "клікальщиком" і почати економити години свого життя, не вивчаючи при цьому складні фреймворки автоматизації. ☕️Уявіть біль: вам треба протестувати видалення товарів з кошика. У вас там 50 позицій. Ви будете сидіти і 50 разів клікати на іконку смітника, чекаючи на оновлення сторінки? А якщо треба заповнити форму з 20 полів уже десятий раз за день? Це прямий шлях до вигорання.Справжня магія починається у вкладці Console (F12). Якщо ви знаєте хоча б основи JS, браузер стає вашим особистим терміналом для автоматизації на льоту.Ось 3 консольні трюки, які можна використовувати прямо зараз:✅ "Клікнути все" за 1 мілісекундуТреба вибрати всі 50 чекбоксів на сторінці? Забудьте про мишку. Відкриваємо консоль і пишемо один рядок:document.querySelectorAll('input[type="checkbox"]').forEach(cb => cb.click());Бум! Усі чекбокси активовані одночасно. 📝 Автозаповнення нудних формПостійно вводите "test" у всі поля при реєстрації? Напишіть один раз міні-скрипт, збережіть його в сніпети браузера (DevTools -> Sources -> Snippets) і запускайте кліком:🔹document.querySelector('#email').value = '[email protected]';🔹document.querySelector('#phone').value = '+380999999999'; 👁 Заморозка часу (для невловимих багів)Шукаєте елемент, який з'являється на долю секунди (наприклад, тултип або дропдаун при наведенні), і не можете зловити його в Elements, бо він одразу зникає? Пишемо в консолі:setTimeout(() => { debugger; }, 3000);У вас є рівно 3 секунди, щоб навести мишку на елемент і викликати тултип. Після цього браузер ставиться на жорстку паузу, і ви спокійно інспектуєте його верстку! Висновок: Щоб бути крутим тестувальником, не обов'язково одразу лізти в Cypress чи Playwright і ставати AQA. Почніть з вивчення фундаменту — базового синтаксису JavaScript (змінні, селектори, цикли). Це дасть вам абсолютну владу над фронтендом і повагу від розробників.А ви використовуєте консоль браузера для таких міні-хаків? 👇🔥 — О так, пишу скрипти прямо в консолі постійно!👀 — Знаю тільки як подивитися помилки червоним кольором...🤯 — Ніколи не думав(ла), що так можна, іду клікати чекбокси магією!

🔥 Оффтоп: Коли технічні таски відходять на другий планСьогодні п'ятниця, і ми не будемо шукати вразливості в архітектурі чи розбирати баги. Сьогодні день для іншого релізу.Крім того, що ми тут щодня говоримо про тестування та якість, у мене є мій музичний проєкт Veymir. І саме сьогодні вийшов мій новий трек — «Лють».У тексті є рядки, які, думаю, відгукнуться багатьом з вас:Старий дід заряджає рушницюМолодий айтішник прошив синицюЦе не ритуал це просто роботаВипалити зло випалити болото Це трек про те, що тримає нас на плаву. Про сталевий аркан нашої злості, яка перетворилася на чисту, холодну дію. Коли кожен на своєму місці робить свою роботу — чи то зі зброєю в руках, чи за монітором, "прошиваючи синицю".🎧 Послухати можна тут або на будь-якій іншій музичній платформі: https://youtu.be/W3Er07mhhuc?si=nDzY3jYuMIk_iRd5Якщо вам потрібен жорсткий, агресивний саундтрек для того, щоб розвалити складний таск на роботі або просто зарядитися — вмикайте на повну.Як вам такий вайб? Напишіть у коментарях, чи зрезонувало! 👇

🧟‍♂️ Повстання мерців: Чому кнопка "Видалити акаунт" генерує найгірші баги (і як їх знайти)Привіт, екіпаж! Сьогодні поговоримо про фічу, яку є на кожному проєкті, але яку майже завжди тестують неправильно. ☕️Уявіть тест-кейс: ви заходите в налаштування профілю, тиснете "Видалити акаунт", підтверджуєте. Вас викидає на екран логіну. Ви пробуєте зайти зі старим паролем — не пускає.Статус: Pass? Ні, це лише верхівка айсберга.Бізнес ненавидить втрачати дані (особливо для аналітики). Тому розробники майже ніколи не видаляють ваш рядок із бази даних фізично (DELETE FROM users). Вони використовують Soft Delete (М'яке видалення) — просто ставлять у базі невидиму галочку is_deleted = true. Юзер ніби "вмирає" для інтерфейсу, але його тіло залишається в системі.І тут починається справжній зомбі-апокаліпсис, який QA зобов'язаний протестувати:🚫 Пастка нової реєстрації (Унікальний імейл)Ви видалили акаунт [email protected]. Через тиждень ви вирішили повернутися і реєструєтесь наново з цим же імейлом.Що стається на дірявому бекенді? База даних кричить: "Стоп! Такий імейл вже є в таблиці!" (бо працює обмеження UNIQUE, а розробник забув додати умову, що імейли мають бути унікальними тільки серед НЕ видалених юзерів).Бекенд падає з помилкою 500 Internal Server Error. Користувач застряг у лімбі: він не може ні увійти, ні зареєструватися. 🧟‍♂️ Зомбі-токен (JWT)Ви видалили акаунт, але ваш Access Token все ще "живий" (наприклад, лежить у Postman або в Local Storage браузера). Відправте будь-який запит (наприклад, на створення поста або зміну аватарки) з цим старим токеном.Дуже часто бекенд валідує підпис токена, бачить, що він ще не протермінувався, і пропускає запит! Сервер забуває перевірити ту саму галочку is_deleted у базі. У результаті "мертвий" користувач продовжує публікувати контент. 👻 Привиди в коментарях (Orphaned Data)Юзер видалився. Але до цього він залишив 100 коментарів під статтями або зробив 5 замовлень. Що з ними сталося?Зайдіть на сторінку товару. Якщо замість коментаря фронтенд показує порожній білий екран або взагалі крашиться (бо намагається прочитати user.name, а user тепер повертає null) — це серйозний баг архітектури. Система має вміти граціозно заміняти видалених авторів на "Невідомий користувач". Висновок: Видалення сутності — це найскладніший процес в архітектурі баз даних. Коли тестуєте видалення, не перевіряйте, чи зникла картинка. Перевіряйте, чи не залишив покійник після себе розруху в інших частинах додатку.А як у вас на проєкті працює видалення? 👇🔥 — Знаю всі наші Soft Deletes, токени "вбиваємо" миттєво!👀 — Здається, ми тестували тільки "щасливий шлях" кнопки...🤯 — Іду пробувати зареєструватися на видалений імейл, відчуваю, буде 500-ка!

🅰️ Анатомія Angular: 3 специфічні баги, які зводять QA з розуму (і як їх ламати)Привіт, екіпаж! Сьогодні розриваємо шаблони. ☕️Більшість QA тестують веб-додатки однаково, не задумуючись, на чому вони написані — React, Vue чи Angular. Але це фатальна помилка.Як людина, яка щодня пише код на Angular, я зіллю вам наші головні "гріхи". Angular — це важкий, суворий enterprise-фреймворк зі своїми унікальними правилами гри. І якщо ви знаєте його слабкі місця, ви зможете знаходити критичні баги за лічені хвилини.Ось 3 вектори атаки специфічно під Angular-проєкти:🚰 Витік пам'яті (Прокляття RxJS)Angular побудований на реактивному програмуванні (RxJS). Ми постійно "підписуємося" (subscribe) на потоки даних — події кліків, таймери, відповіді від API. Головний гріх джуна-ангулярщика: забути "відписатися" (unsubscribe) при закритті сторінки.Як тестувати: Зайдіть на сторінку, де дані оновлюються самі (наприклад, дашборд із графіками). Перейдіть на іншу сторінку. Поверніться назад. Зробіть так 10 разів швидко. Відкрийте вкладку Network. Якщо ви бачите, що один і той самий API-запит тепер відправляється 10 разів одночасно — вітаю, ви знайшли витік пам'яті. Додаток скоро намертво зависне. 👻 "Мертвий" UI (Проблема Change Detection)В Angular є магічний механізм (Zone.js), який розуміє, коли треба перемалювати екран. Але для оптимізації ми часто вмикаємо стратегію OnPush (перемальовувати тільки якщо змінилося посилання на об'єкт). Якщо розробник схалтурив і просто змінив поле в об'єкті, дані під капотом оновляться, а екран — ні.Як тестувати: Зробіть дію, яка оновлює дані "збоку" (наприклад, дочекайтеся повідомлення через WebSocket або закінчення довгого таймера). Екран не змінився? А тепер просто клікніть мишкою в будь-яке порожнє місце сторінки. Якщо нові дані раптом магічно з'явилися тільки ПІСЛЯ вашого кліку — це класичний баг Change Detection. ♻️ Привиди минулого (Синглтон-сервіси)В Angular сервіси (класи, які зберігають дані) часто існують в єдиному екземплярі (Singleton) на весь додаток. Вони живуть, навіть коли ви переходите між сторінками.Як тестувати: Відкрийте Профіль Користувача №1. Потім перейдіть на головну. Тепер відкрийте Профіль Користувача №2. Якщо на частку секунди ви бачите фото або ім'я першого користувача, перш ніж завантажиться другий — розробник забув очистити стан (State) сервісу при знищенні компонента (ngOnDestroy). Висновок: Знання інструменту, на якому написаний ваш продукт — це ваша суперсила. Якщо ви прийдете до розробника і скажете не просто "тут лагає", а "здається, ти забув відписатися від Observable в цьому компоненті", рівень поваги до вас злетить у космос.А ви знаєте, на якому фреймворку написаний ваш поточний проєкт? 👇🔥 — Звісно, я знаю весь стек технологій!👀 — Здається, React... або Vue... яка різниця, кнопки ж клікаються.🤯 — Піду швидко спитаю розробників, поки ніхто не бачить!

⏰ 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 і спробуйте провести оплату. Зрозумійте, як продукт працює "під капотом".Практичний скіл і розуміння архітектури б'ють будь-який сертифікат. Завжди.📌 Скиньте цей пост тим, хто зараз готується до співбесід і витрачає час на зазубрювання глосарію замість практики!А тепер чекаю вас у коментарях для холівару 👇🔥 — Абсолютно згоден, на співбесідах питаю тільки хардкор і практику!👀 — Теорія і сертифікати дають базу, без неї нікуди, ви не праві.🤯 — Маю сертифікат, але на реальній роботі він жодного разу не знадобився...