QA Co-pilot

📝 Ультимативна Шпаргалка: Стан елемента в DOM (Visible vs Attached)Привіт, екіпаж! Скільки разів ви ловили помилку Element is not visible, хоча в DevTools його чітко видно в HTML-коді? Сьогодні розбираємо життєвий цикл елемента на сторінці. Це база, без якої ваші асерти (перевірки) завжди будуть нестабільними. ☕️У сучасних інструментах (Playwright, Cypress) елемент перед кліком проходить 4 стадії зрілості. Знати їх — обов'язок QA.👻 Attached (Прикріплений)Елемент фізично існує в DOM-дереві.Пастка: Він може бути повністю прозорим (opacity: 0), мати display: none або нульовий розмір (0x0). Ви бачите його код у DevTools, але юзер на екрані його не бачить.(В Angular це зазвичай відбувається при використанні [hidden]="true"). 👁Visible (Видимий)Елемент прикріплений (Attached), має реальні розміри (bounding box не нульовий) і не захований стилями.Пастка: Він видимий, але може бути перекритий іншим елементом зверху (наприклад, напівпрозорим лоадером або невидимим тултипом). 🟢Enabled (Активний)Елемент видимий, не перекритий, і на ньому немає атрибута disabled. Тільки на цій стадії з ним можна взаємодіяти. 🛑 Stable (Стабільний)Елемент повністю завершив свою CSS-анімацію. Він більше не летить через половину екрану. Якщо фреймворк спробує клікнути до цієї стадії — він просто клікне в порожнечу. Золоте правило перевірок (Asserts):Тестуючи зникнення елемента, завжди питайте розробників, ЯК він зникає.Якщо використовується умовний рендеринг (наприклад, новий синтаксис @if або старий *ngIf в Angular) — елемент ПОВНІСТЮ видаляється з DOM. Перевіряємо так:await expect(locator).toHaveCount(0) або toBeAttached({ attached: false }). Якщо ж елемент просто ховається через CSS — він залишається Attached, але перестає бути Visible. Перевіряємо так:await expect(locator).toBeHidden().А ви плутали Attached і Visible? 👇🔥 — Знаю цю базу, мої тести надійні як швейцарський годинник!👀 — Постійно ліплю .toBeVisible() на все підряд і страждаю...🤯 — Чекайте, тобто елемент може бути в DOM, але не бути Visible?!

⚔️ Битва підходів: Cucumber (BDD) проти Чистого КодуП'ятниця — час для найкривавіших архітектурних холіварів. Сьогодні на арені зійшлися два табори, суперечки між якими змушують інженерів звільнятися, а менеджерів — хапатися за серце. Розбираємо тестування через текст проти тестування через код. ☕️🥊 Підхід 1: BDD / Gherkin (Свідки Cucumber)Ви пишете тести людською мовою через ключові слова Given / When / Then.🔹Як це нам продають: "Бізнес, продакти та мануальні тестувальники зможуть самі читати і навіть писати автотести! У нас буде жива документація!"🔹Сувора реальність: Це гігантський милиця. Під кожен текстовий рядок When я натискаю кнопку "Купити" AQA-інженер змушений писати мапінг у коді (регулярки або декоратори). Рефакторинг перетворюється на пекло: ви змінили текст кроку — код впав. І найголовніше — за кілька років роботи бізнес жодного разу не відкриє ваш репозиторій, щоб почитати ці тести. 🥊 Підхід 2: Code-First (Чистий Playwright/Cypress на TypeScript)Ви викидаєте текстовий прошарок і пишете сценарії одразу кодом, використовуючи паттерни на кшталт Page Object або Action Classes.🔹Переваги: Максимальна швидкість розробки. Строга типізація (TypeScript), миттєвий автокомпліт в IDE, рефакторинг однією кнопкою (F2). Ваші тести гнучкі та легко підтримуються.🔹Недоліки: Менеджер не зрозуміє, що написано у файлі checkout.spec.ts. ⚖️ Вердикт QA Co-pilot: BDD — це красива ілюзія, яка добре звучить на конференціях, але на практиці додає 50% оверхеду до часу розробки і підтримки. Для переважної більшості проєктів це абсолютно зайвий баласт.Здоровий підхід: Пишіть тести чистим кодом, а для менеджерів та мануальників генеруйте красиві HTML-звіти (наприклад, через Allure), де назва тесту test('User can buy item') перетворюється на зрозумілий читабельний рядок. Не робіть інженерів заручниками текстових парсерів. А в якому таборі ви? 👇🔥 — Пишу на чистому TS/JS, ніяких "огірків" у моєму коді!👀 — У нас BDD... Код перетворився на кашу з декораторів, допоможіть.🤯 — А що, бізнес реально мав читати наші тести?!

🩻 Рентген співбесіди: "Бекенду ще немає, але треба тестувати"Питання від ліда:"Фронтендери (наприклад, на вашому улюбленому Angular) вже все зверстали. Але бекенд (на NestJS) ще навіть не починав писати API. У нас є тільки узгоджений Swagger-файл. Як QA гарантувати, що коли вони нарешті зійдуться на тестовому середовищі, все не вибухне?"❌ Відповідь рівня Junior (Хибний шлях):"Я просто напишу моки (фейкові дані) для E2E-тестів у Playwright і буду тестувати фронтенд ізольовано. А коли бекенд буде готовий — проженемо реальні тести."Чому це провал: Ваші моки дуже швидко застаріють. Якщо через тиждень бекендер вирішить перейменувати поле userId на user_id, ваші фронтенд-тести залишаться зеленими (бо моки старі), а на продакшені все впаде.✅ Відповідь рівня Senior (Підхід Архітектора):"Нам потрібне Contract Testing (Контрактне тестування), наприклад, через інструмент Pact." Алгоритм:1️⃣ Фронтенд пише тест, який генерує "Контракт" (JSON-файл). У ньому чітко написано: "Я відправляю запит X і очікую отримати поле userId у форматі числа".2️⃣ Цей контракт автоматично завантажується в Pact Broker (спільний репозиторій).3️⃣ Коли бекендер пише свій код, його CI/CD пайплайн автоматично стягує цей контракт і перевіряє свій API проти нього.4️⃣ Якщо бекендер перейменував поле або змінив тип даних — його пайплайн падає ще до деплою. Золоте правило: E2E-тести занадто повільні для перевірки інтеграції двох команд. Контрактні тести — це автоматизований "договір" між клієнтом і сервером, який не дозволяє їм зламати один одного.А як ви тестуєте розірвані команди? 👇🔥 — Pact — наш бро! Ловимо невідповідності ще в пайплайнах.👀 — Пишемо E2E з моками і молимось, щоб бекенд нічого не змінив.🤯 — Стоп, тобто фронтенд може диктувати бекенду, які дані повертати?!

📝 Ультимативна Шпаргалка: Ієрархія локаторів (від крихких до куленепробивних)Скільки разів ваші автотести ставали "червоними" просто тому, що фронтендер змінив колір кнопки або обгорнув її в новий <div>?Сьогодні розбираємо піраміду локаторів для Playwright/Cypress. Збережіть це, щоб більше ніколи не витрачати години на фікси впавших селекторів. ☕️🔴 Рівень 1: Шлях у нікуди (CSS класи та XPath) Приклади: xpath=/html/body/div[2]/button або .btn.btn-primary.mt-2Чому це сміття: Вони прив'язані до візуального стилю або структури DOM. Верстальник перейменував клас або додав обгортку — ваш тест вмер. Використовувати тільки під дулом пістолета. 🟡 Рівень 2: Ілюзія надійності (ID елементів) Приклади: #submit-order-btnЧому це не ідеал: Звучить добре, але в сучасних фреймворках ID часто генеруються динамічно, щоб уникнути конфліктів. Плюс, розробники часто забувають робити їх унікальними на сторінці. 🟢 Рівень 3: Золотий стандарт тестувальника (Data-атрибути) Приклади: [data-testid="submit-order"] або [data-qa="login-button"]Чому це круто: Ці атрибути додаються виключно для QA. Дизайнер може повністю перемалювати сторінку, змінити теги та стилі, але data-testid залишиться на місці. Це ваш залізобетонний контракт із фронтенд-командою. 👑 Рівень 4: Рівень Архітектора (Accessibility / ARIA) Приклади: getByRole('button', { name: 'Оплатити' })Чому це топ: Це підхід сучасного Playwright. Користувач не шукає очима data-testid. Він шукає сутність "Кнопка" з текстом "Оплатити". Тестуючи через Accessibility (ролі), ви перевіряєте не просто наявність елемента, а те, чи правильно він доступний для користувачів (і скрінрідерів). Золоте правило: Якщо ви не можете знайти елемент через getByRole або getByText, вимагайте у розробників додати data-testid. Ніколи не прив'язуйтесь до CSS-класів!За що чіпляються ваші тести? 👇🔥 — Тільки data-testid або getByRole, мої тести куленепробивні!👀 — Пишу через класи (.button-active), страждаю під час кожного релізу.🤯 — Щойно скопіював XPath із DevTools на 5 рядків... Допоможіть!

🧨 Руйнівники IT-міфів: "Справжній E2E-тест має клікати по реальному Google Auth чи Stripe"Привіт, екіпаж! Сьогодні розбираємо міф, через який автотести обростають "милицями", падають на CAPTCHA і блокуються сторонніми сервісами. ☕️❌ Міф: "Ми ж пишемо End-to-End! Тому мій Playwright-тест повинен чесно відкрити вікно авторизації Google, ввести реальний логін і пароль, або відкрити справжній віджет Stripe і ввести тестову картку".💥 Реальність (Бум!):Ви не працюєте в Google і не працюєте в Stripe.Ви не повинні тестувати чужий UI. 🔹CAPTCHA вас знищить: Алгоритми безпеки Google, Facebook або платіжних систем миттєво розпізнають автоматизований браузер (headless mode). Рано чи пізно ваш тест впреться у нескінченну капчу або блокування IP-адреси CI/CD сервера.🔹Нестабільність (Flakiness): Сторонній сервіс може проводити А/В тестування свого UI, змінити селектори або просто мати мікро-збій. Ваш тест впаде, хоча ВАШ додаток працює ідеально. ✅ Як має бути (Підхід Архітектора):Тестуйте лише кордони свого додатку. Вас цікавить лише те, як ваша система реагує на успішну чи неуспішну відповідь від стороннього сервісу.🔹Для авторизації (OAuth): Замість кліків по UI Google, зробіть один API-запит до вашого бекенду, щоб згенерувати тестовий JWT-токен, і покладіть його в localStorage браузера (ми розбирали це в "Битві підходів"). Або використовуйте page.route(), щоб замокати відповідь від провайдера авторизації.🔹Для платежів: Якщо ви змушені клікати по віджету Stripe — використовуйте їхні офіційні тестові API-ключі або спеціальні інструменти CLI (Stripe CLI) для тригерингу вебхуків про успішну оплату, минаючи UI. Золоте правило: E2E-тест гарантує, що ваші мікросервіси спілкуються між собою. Чужі мікросервіси хай тестують їхні власні QA.А ваші тести намагаються обдурити Google чи платіжки? 👇🔥 — Ніколи! Мокаємо сторонні сервіси або юзаємо API-токени.👀 — Грішу... Мої тести реально вводять логін і пароль у попапі Google.🤯 — То ось чому мої тести періодично падають з помилкою Access Denied!

⚔️ Битва підходів: Підготовка стану (UI-логін проти API-ін'єкції)Сьогоднішня битва присвячена найчастішій дії в автотестах — авторизації. Уявіть, що у вас 100 тест-кейсів, і для кожного юзер має бути залогінений. Як ми це робимо? ☕️🥊 Підхід 1: UI-авторизація (Як роблять новачки)У блоці beforeEach тест відкриває сторінку /login, знаходить поле email, вводить текст, знаходить password, вводить пароль, натискає кнопку і чекає на редирект.Плюси: Тест на 100% імітує дії реального користувача.Мінуси: Це катастрофічно повільно. Якщо UI-логін займає 3 секунди, на 100 тестах ви втрачаєте 5 хвилин просто на введення паролів. А якщо фронтендери змінять дизайн або додадуть капчу — впадуть усі 100 тестів одночасно. 🥊 Підхід 2: API-ін'єкція стану (Рівень Архітектора)Ви взагалі не відкриваєте сторінку логіну. Ви робите один швидкий HTTP-запит POST /api/auth, отримуєте JWT-токен або Cookie, і напряму "впорскуєте" його в контекст браузера.Плюси: Авторизація займає 50 мілісекунд замість 3 секунд. Тести повністю ізольовані від змін в UI екрану логіну.Мінуси: Виникає страх "А раптом сама форма логіну зламалася, а ми це пропустили?". ⚖️ Вердикт QA Co-pilot: Запам'ятайте золоте правило автоматизації: Тестуйте UI логіну тільки в тестах на логін.Вам потрібен рівно ОДИН тест, який чесно проходить через UI форму авторизації (перевіряє валідацію, повідомлення про помилки тощо).Для всіх інших 99 тестів (кошик, профіль, пошук) екран логіну — це просто перешкода. Використовуйте API-ін'єкцію (у Playwright це робиться через request.post та browserContext.addCookies()), щоб миттєво підготувати стан і тестувати саме те, що треба.

💩 Код з душком: Спільні тестові дані (або Прокляття [email protected])Привіт, екіпаж! П'ятниця — час вивітрювати антипатерни. Сьогодні говоримо про звичку, яка працює на локальному комп'ютері, але перетворює CI/CD пайплайн на суцільне мінне поле. ☕️Знайдіть проблему в цьому підході:// ❌ Антипатерн "Гуртожиток" (Shared State)test.beforeEach(async ({ page }) => { // Усі тести у сьюті логіняться під ОДНИМ юзером await loginPage.login('[email protected]', 'Qwerty1234');});test('Користувач може видалити товар з кошика', async ({ page }) => { await cartPage.deleteItem(); await expect(page.locator('.empty-cart')).toBeVisible();}); Чому цей код тхне:Коли ви запускаєте ці тести по одному на своєму ноуті — все ідеально. Але щойно ви налаштовуєте паралельний запуск (наприклад, workers: 4 у Playwright), починається хаос.Один тест намагається покласти товар у кошик, а паралельний тест ТІЄЇ Ж СЕКУНДИ натискає кнопку "Очистити кошик" (бо вони сидять під одним акаунтом!). Тести починають вбивати один одного. З'являються сотні "плаваючих" (flaky) багів. ✅ Як це виглядає після код-рев'ю Senior-інженера:Тести мають дотримуватись принципу F.I.R.S.T. (зокрема, бути Isolated/Ізольованими). Кожен тест повинен жити у своєму вакуумі і генерувати власні унікальні дані.// 🚀 Ідеально чистий код (Data Isolation)test.beforeEach(async ({ page, api }) => { // Динамічно створюємо УНІКАЛЬНОГО юзера для КОЖНОГО тесту через API const testUser = await api.createUser(); await loginPage.login(testUser.email, testUser.password);});test('Користувач може видалити товар з кошика', async ({ page }) => { // Тест працює у повній ізоляції. Ніхто інший не чіпає цей кошик. await cartPage.deleteItem(); await expect(page.locator('.empty-cart')).toBeVisible();}); Золоте правило: Ніколи не хардкодьте імейли чи ID сутностей у тестах. Використовуйте патерн Data Factory / API-генерацію. Тест має сам створити собі "пісочницю", погратися в ній і (бажано) прибрати за собою.А ваші тести б'ються за один імейл? 👇🔥 — Ні, у нас API генерує унікальні дані для кожного прогону!👀 — Грішу... У мене є файл test-users.json на 5 акаунтів...🤯 — То ось чому мої паралельні тести вічно падають!

💩 Код з душком: Тести-Доміно (або Гріх спільного стану)Привіт, екіпаж! П'ятниця — час вивітрювати "смердючий" код. Сьогодні препаруємо архітектурний антипатерн, який на початку здається геніальною оптимізацією, а через півроку перетворює ваш CI/CD на повільне пекло. Говоримо про залежність тестів (Test Interdependence). ☕️Знайдіть проблему в цьому коді:// ❌ Як пишуть "оптимізатори" (Антипатерн "Доміно")let orderId: string;test.describe('Флоу замовлення', () => { test('Крок 1: Створити замовлення', async ({ page }) => { orderId = await createOrderThroughUI(page); expect(orderId).toBeDefined(); }); test('Крок 2: Оплатити замовлення', async ({ page }) => { // Використовує ID з попереднього тесту! await payForOrder(page, orderId); expect(await getOrderStatus()).toBe('Paid'); }); test('Крок 3: Видалити замовлення', async ({ page }) => { await deleteOrderThroughUI(page, orderId); });}); Чому цей код тхне:Ви порушили головне правило автоматизації — F.I.R.S.T. (Isolated). Ваші тести тепер склеєні суперклеєм. 1️⃣ Крихкість ланцюга: Якщо "Крок 1" падає через випадковий мікро-лаг мережі або рендеру, "Крок 2" і "Крок 3" автоматично стають червоними, бо змінна orderId порожня. У звіті у вас три зламаних тести, хоча реальна проблема лише в одному місці.2️⃣ Паралельність мертва: Ви не зможете запустити ці тести паралельно на кількох воркерах у Playwright (fullyParallel: true), бо вони вимагають суворої послідовності. Ваш пайплайн ніколи не буде швидким.3️⃣ Неможливість локального дебагу: Ви не можете просто взяти і запустити "Крок 3" ізольовано, щоб перевірити логіку видалення. Вам доведеться щоразу чекати, поки проклікаються попередні кроки. ✅ Як це виглядає після код-рев'ю Senior-інженера:Кожен тест має бути повністю незалежним. Він сам готує для себе ідеальні умови (бажано за мілісекунди через API) і сам за собою прибирає.// 🚀 Ідеально чистий код (Повна ізоляція)test('Повинен успішно оплатити замовлення', async ({ request, page }) => { // 1. Arrange: Блискавично створюємо замовлення "під капотом" (через бекенд) const order = await request.post('/api/orders').then(r => r.json()); // 2. Act: Тестуємо саме UI оплати await page.goto(`/orders/${order.id}/pay`); await page.getByRole('button', { name: 'Оплатити' }).click(); // 3. Assert: Перевіряємо результат await expect(page.locator('.status')).toHaveText('Paid');}); Золоте правило: Тест не повинен знати про існування інших тестів. Використовуйте API-виклики (request) або Fixtures для підготовки даних перед дією page.goto(). Кожен запуск — це чиста сторінка.А як у вас справи із залежністю тестів? 👇🔥 — Повна ізоляція, кожен тест готує дані через API за мілісекунди!👀 — У мене величезний test.describe.serial, інакше все ламається...🤯 — А що, тести можна запускати в довільному порядку?!

🔥 Прожарка інструментів: Cucumber (або Чому бізнес ніколи не читатиме ваші тести)Привіт, екіпаж! Четвер — час розпалювати гриль. Сьогодні на нашій решітці лежить інструмент, який продають менеджерам як "срібну кулю", а для інженерів він часто перетворюється на архітектурні кайдани. Зустрічайте — Cucumber та його синтаксис Gherkin. ☕️🟢 Як нам це продавали (Очікування):"Давайте писати тести людською мовою! Given, When, Then. Бізнес-аналітики та продакт-менеджери будуть самі писати сценарії, а автоматизатори — лише підкладати під них код. У нас буде ідеальна жива документація, яку зрозуміє навіть CEO!" 🥩 Прожарка (Сувора реальність): Бізнес ніколи не пише тести. Це найголовніший міф індустрії. У 99% випадків аналітику немає коли гратися зі специфічним синтаксисом і відступами. У результаті QA-інженер сам вигадує сценарій на Gherkin, а потім сам же пише під нього код. Ви просто робите подвійну роботу.Прокляття текстових рядків: Замість гнучкого та типізованого TypeScript ви будуєте крихкий міст. Змінили формулювання кроку з "я натискаю кнопку Зберегти" на "я клікаю на кнопку Зберегти" — і тест відвалився, бо не спрацював регулярний вираз (Regex) під капотом.Біль рефакторингу та дебагу: Уявіть, що змінилася бізнес-логіка і треба переписати 50 тестів. У чистому Playwright з Page Object ви міняєте один метод, і IDE миттєво підсвічує всі місця, де він використовується. З Cucumber ви шукаєте зламані кроки по всьому проєкту через "Find in Files", створюючи жахливе нагромадження дублюючих Step Definitions. ⚖️ Вердикт QA Co-pilot: BDD (Behavior-Driven Development) — це чудовий процес для обговорення вимог між розробником, тестувальником і бізнесом на етапі планування. Але тягнути BDD у код автотестів — це жорсткий оверінжиніринг. Сучасний Playwright з гарно названими кроками test.step('Заповнення форми оплати', ...) та згенерованим HTML-звітом дає максимально зрозумілу картину для будь-якого менеджера. Без жодних прошарків із "огірків". А у вас в проєкті ростуть огірки? 👇🔥 — Давно викинули BDD, пишемо чистий код на TS і кайфуємо!👀 — Пишу на Gherkin, бо так сказав замовник. Плачу і підтримую регулярки...🤬 — Не згоден, Cucumber дисциплінує і робить тести читабельними для всіх!

🗂 Ультимативна шпаргалка: Жорсткі vs. М'які перевірки (Soft Assertions)Коротка шпаргалка про те, як зібрати максимум багів за один прогін і не переривати скрипт на півдорозі. Зберігайте! ☕️🛑 expect() (Жорстка перевірка — Класика) Як працює: Знайшов помилку ➡️ Тест миттєво впав (Fatal Error) ➡️ Усі наступні кроки скасовано.Коли юзати: Критичні бізнес-кроки. Якщо після логіну юзер не потрапив у дашборд, немає сенсу намагатися клікати далі. // Якщо сторінка не завантажилась, тест падає тут...await expect(page).toHaveURL('/dashboard'); // ...цей клік ніколи не виконаєтьсяawait page.getByRole('button', { name: 'Створити' }).click(); ☁️ expect.soft() (М'яка перевірка — Рятівник часу) Як працює: Знайшов помилку ➡️ Записав у лог (червоним) ➡️ Пішов виконувати тест далі! Скрипт впаде лише в самому кінці, але збере всі помилки.Коли юзати: Перевірка великих форм, таблиць, візуальних атрибутів, де один баг (наприклад, неправильний колір тексту) не блокує перевірку інших полів. // Якщо ім'я не збігається, тест запише помилку, але ВСЕ ОДНО перевірить вік та email!await expect.soft(page.locator('#name')).toHaveValue('Ivan');await expect.soft(page.locator('#age')).toHaveValue('25');await expect.soft(page.locator('#email')).toHaveValue('[email protected]'); Золоте правило:Використовуйте expect() для навігації та перевірок станів, від яких залежить наступний крок. Використовуйте expect.soft(), коли тестуєте "пачку" незалежних даних (наприклад, перевіряєте всі дані у профілі користувача після збереження).А ви використовуєте "м'які" перевірки? 👇🔥 — Так, expect.soft() ідеально підходить для перевірки таблиць!👀 — Пишу звичайний expect, хай падає одразу, мені так спокійніше.🤯 — Почекайте, Playwright вміє не зупиняти тест при помилці?!