All about QA - Все про тестування ПЗ

✨ Техніки Тест-Дизайну: Тестування попарно (Pairwise/All-Pairs Testing) ✨🤔 Що робити, коли кількість комбінацій для тестування сягає тисяч?Уявіть, що ви тестуєте форму з кількома параметрами: 3 типи ОС, 4 браузери, 3 ролі користувача, 5 форматів експорту. Повне тестування вимагало б 3 * 4 * 3 * 5 = 180 тест-кейсів. Додайте ще один параметр — і кількість тестів зросте експоненційно. Це "комбінаторний вибух", який робить повне тестування неможливим. Техніки, як аналіз граничних значень чи таблиці рішень, тут не завжди допоможуть, бо вони не фокусуються на комбінації всіх параметрів.🎯 Тестування попарно: Суть технікиМета тестування попарно — створити мінімально можливий набір тест-кейсів, який покриває всі унікальні пари значень між усіма параметрами.В основі лежить емпіричне спостереження: більшість багів виникають через взаємодію одного або двох параметрів одночасно. Помилки, спричинені складною взаємодією трьох і більше параметрів, трапляються значно рідше.Отже, замість того, щоб тестувати всі можливі комбінації, ми гарантуємо, що:Кожне значення параметра А було протестоване в парі з кожним значенням параметра Б.Кожне значення параметра А було протестоване в парі з кожним значенням параметра В, і так далі.Як це працює?Визначаємо параметри та їх значення: Складаємо список всіх параметрів, які впливають на поведінку системи, та всіх можливих значень для кожного з них.Наприклад: ОС (Win, Mac), Браузер (Chrome, Firefox), Роль (Admin, User).Використовуємо інструмент для генерації: Створення оптимального набору тестів вручну — складна задача. Для цього існують спеціалізовані інструменти, які роблять це автоматично.Наприклад: PICT, AllPairs, онлайн-генератори.Отримуємо таблицю тест-кейсів: Інструмент генерує таблицю, де кожен рядок — це один тест-кейс. Кількість таких тест-кейсів буде значно меншою за повний перебір, але покриття взаємодій залишиться високим.Для прикладу вище (2*2*2=8 комбінацій) Pairwise може звести все до 4 тест-кейсів, покривши всі пари.💡 Переваги тестування попарно:Суттєве зменшення кількості тест-кейсів: Економія часу та ресурсів на 80-90% у порівнянні з повним перебором.Висока ефективність: Добре виявляє баги, пов'язані з взаємодією двох параметрів, що є найчастішим випадком.Систематичний підхід: На відміну від випадкового вибору, Pairwise гарантує покриття всіх парних взаємодій.Ідеально для тестування конфігурацій: Незамінний при перевірці сумісності ПЗ з різними ОС, браузерами, базами даних, налаштуваннями тощо.⚠️ Недоліки та Обмеження:Не гарантує 100% покриття: Техніка свідомо ігнорує комбінації трьох і більше параметрів. Якщо критичний баг виникає лише при одночасній взаємодії трьох конкретних значень, Pairwise може його пропустити.Залежить від правильного вибору параметрів: Ефективність техніки повністю залежить від того, наскільки точно тестувальник визначив усі параметри, що впливають на систему.Потребує інструментів: Ручна генерація оптимального набору тестів для реальних задач практично неможлива.Висновок:Тестування попарно — це прагматичний компроміс між повнотою покриття та обмеженістю ресурсів. Це потужна техніка чорної скриньки, яка дозволяє ефективно тестувати складні системи з великою кількістю налаштувань. Вона є обов'язковим інструментом в арсеналі будь-якого тестувальника, що працює з конфігураційним тестуванням або складними формами.#ТестДизайн #ТестуванняПЗ #ЧорнаСкринька #PairwiseTesting #AllPairsTesting #CombinatorialTesting #QA #TestDesignTechniques #AllAboutQA

✨Техніки Тест Дизайну: Тестування на основі Варіантів Використання (Use Case Testing) (ч. 2).💡 Переваги Тестування на основі Варіантів Використання:Фокус на користувачеві: Тести відображають реальні сценарії використання системи.Зрозумілість: Use Cases легко зрозуміти як технічним спеціалістам, так і представникам бізнесу.Хороше покриття бізнес-логіки: Допомагає перевірити наскрізні сценарії.Раннє виявлення проблем у вимогах: Аналіз Use Cases для тестування може виявити неоднозначності або прогалини у специфікаціях.Пріоритезація: Дозволяє зосередитися на найважливіших для користувача функціях.⚠️ Недоліки:Залежність від якості Use Cases: Якщо варіанти використання погано написані або неповні, тестове покриття буде недостатнім.Не покриває всі аспекти: Може не виявити помилок на рівні окремих компонентів або нефункціональних проблем, якщо вони не описані у Use Cases.Складність для дуже великих систем: Створення та підтримка детальних Use Cases для всіх взаємодій може бути трудомістким.Висновок:Тестування на основі варіантів використання – це чудовий спосіб переконатися, що система відповідає потребам користувачів і дозволяє їм досягати своїх цілей. Воно є невід'ємною частиною тестування на системному рівні та приймального тестування. Найкраще працює в поєднанні з іншими техніками для забезпечення всебічного покриття.#ТестДизайн #ТестуванняПЗ #ВаріантиВикористання #UseCaseTesting #QA #SoftwareTesting #TestDesignTechniques #AllAboutQA #TechTips #UserExperience

✨ Техніки Тест-Дизайну: Таблиці Рішень (Decision Table Testing) ✨🤔 Коли звичайних підходів недостатньо?Уявіть ситуацію: поведінка системи залежить від комбінації кількох умов, і для кожної комбінації передбачена своя унікальна дія або результат. Наприклад, надання знижки клієнту залежить від типу його картки, суми покупки та наявності промокоду. Перебирати всі варіанти вручну може бути складно і легко щось пропустити. Ось тут на допомогу приходять Таблиці Рішень!🔍 Таблиці Рішень: Суть технікиТаблиця рішень – це структурований спосіб представити складну логіку. Вона допомагає систематизувати умови, можливі дії та правила, які пов'язують ці умови з діями.Як це працює?Ідентифікуємо Умови (Conditions): Визначаємо всі фактори, які впливають на поведінку системи. Це можуть бути вхідні дані, стани системи тощо.Ідентифікуємо Дії (Actions): Визначаємо всі можливі дії або результати, які система може виконати у відповідь на умови.Будуємо Таблицю:Рядки Умов: Кожен рядок представляє одну умову. Для кожної умови ми вказуємо можливі значення (наприклад, Так/Ні, True/False, або конкретні значення).Рядки Дій: Кожен рядок представляє одну можливу дію.Стовпці Правил (Rules): Кожен стовпець представляє унікальну комбінацію значень умов та відповідні дії, які мають бути виконані. По суті, кожен стовпець – це потенційний тест-кейс.Заповнюємо Таблицю: Для кожного правила (стовпця) визначаємо, які дії виконуються (позначаємо X або ✓) при заданій комбінації умов.Оптимізуємо (за потреби): Іноді таблицю можна скоротити, об'єднавши правила, де деякі умови не впливають на результат (позначаються - або N/A).Створюємо Тест-Кейси: Кожен стовпець (правило) в таблиці рішень стає основою для одного або кількох тест-кейсів.Приклад: Уявімо логіку реєстрації на сайті з такими умовами та діями:Умови:1. Користувач новий? (Так/Ні)2. Email валідний? (Так/Ні)3. Пароль відповідає вимогам? (Так/Ні)Дії:A. Створити акаунтB. Показати повідомлення про успішну реєстраціюC. Показати помилку "Email невалідний"D. Показати помилку "Пароль не відповідає вимогам"E. Показати помилку "Користувач вже існує"Розглянемо правила (тест-кейси):➡️ Правило 1 (Успішна реєстрація): - Умова 1: Так (новий) - Умова 2: Так (email валідний) - Умова 3: Так (пароль валідний) - Дії: A, B➡️ Правило 2 (Невалідний email): - Умова 1: Так (новий) - Умова 2: Ні (email невалідний) - Умова 3: - (не має значення) - Дія: C➡️ Правило 3 (Невалідний пароль): - Умова 1: Так (новий) - Умова 2: Так (email валідний) - Умова 3: Ні (пароль невалідний) - Дія: D➡️ Правило 4 (Новий користувач, невалідний пароль - інший сценарій, якщо потрібно): - Умова 1: Так (новий) - Умова 2: Так (email валідний) - Умова 3: Ні (пароль занадто короткий - приклад) - Дія: D (або інша специфічна помилка пароля)➡️ Правило 5 (Користувач вже існує): - Умова 1: Ні (не новий) - Умова 2: - (не має значення) - Умова 3: - (не має значення) - Дія: E💡 Переваги Таблиць Рішень:- Забезпечують систематичне покриття складної логіки.- Допомагають виявити прогалини або суперечності у вимогах.- Зменшують надлишковість тестів.- Тест-кейси, створені на основі таблиць, легко документувати та підтримувати.- Корисні для комунікації з бізнес-аналітиками та розробниками.Таблиці рішень – потужний інструмент, особливо для функціоналу з розгалуженою бізнес-логікою. Хоча їх створення може зайняти час, результат у вигляді якісного тестового покриття того вартий!#ТестДизайн #ТестуванняПЗ #ТаблиціРішень #DecisionTableTesting #QA #SoftwareTesting #TestDesignTechniques #AllAboutQA

✨ Техніки Тест-Дизайну: Аналіз Граничних Значень (Boundary Value Analysis) ✨🤝 Класи Еквівалентності та Аналіз Граничних Значень йдуть пліч-о-пліч?Якщо Класи Еквівалентності допомагають нам вибрати типових представників з кожної групи даних, то Аналіз Граничних Значень фокусується на "краях" або "межах" цих груп. Саме на стиках діапазонів найчастіше ховаються підступні баги! 🐛🔍 Аналіз Граничних Значень: Суть технікиІдея BVA полягає в тому, що помилки частіше виникають на граничних значеннях вхідних даних, а не всередині діапазонів. Тому ми тестуємо значення:- Безпосередньо на межі- Трохи менше за межу- Трохи більше за межуЦе дозволяє перевірити, як система обробляє переходи між різними станами або діапазонами.Як це працює?Визначаємо Класи Еквівалентності: Так, спочатку ми все одно ідентифікуємо класи (як у попередньому пості).Знаходимо Границі: Для кожного валідного та невалідного класу визначаємо його чіткі межі.Обираємо Тестові Значення:Для валідного діапазону: мінімальне значення, (мінімальне значення + 1), максимальне значення, (максимальне значення - 1).Для невалідних діапазонів, що прилягають до валідного: значення, що на одиницю менше мінімального валідного, та значення, що на одиницю більше максимального валідного.Приклад (продовжуємо з полем віку):Нагадую, поле для введення віку користувача (ціле число) приймає значення від 18 до 60 років включно.Класи еквівалентності ми вже визначили. Тепер застосуємо BVA:Нижня межа (18):17 (невалідний, безпосередньо перед межею)18 (валідний, на межі)19 (валідний, безпосередньо після межі)Верхня межа (60):59 (валідний, безпосередньо перед межею)60 (валідний, на межі)61 (невалідний, безпосередньо після межі)📋 Тест-кейси, що випливають з BVA (для цього прикладу):Ввести 17 -> очікуваний результат: помилка/відхилення.Ввести 18 -> очікуваний результат: успішне прийняття.Ввести 19 -> очікуваний результат: успішне прийняття.Ввести 59 -> очікуваний результат: успішне прийняття.Ввести 60 -> очікуваний результат: успішне прийняття.Ввести 61 -> очікуваний результат: помилка/відхилення.📌 Важливо! BVA не замінює Класи Еквівалентності, а доповнює їх. Тобто, ми б також залишили тест-кейс з представником валідного класу (наприклад, 35), щоб перевірити "середнє" значення.💡 Переваги BVA:Дуже ефективний для виявлення помилок типу "off-by-one" (помилка на одиницю).Дозволяє ретельно протестувати поведінку системи на межах діапазонів.Легко застосовується, коли класи еквівалентності вже визначені.Значно підвищує надійність тестування без надмірного збільшення кількості тест-кейсів.Аналіз Граничних Значень – це простий, але надзвичайно дієвий інструмент в арсеналі кожного тестувальника. Комбінуючи його з Класами Еквівалентності, ви значно підвищуєте шанси знайти важливі дефекти!#ТестДизайн #ТестуванняПЗ #АналізГраничнихЗначень #BoundaryValueAnalysis #QA #SoftwareTesting #TestDesignTechniques #AllAboutQA

Вступ до Технік Тест-Дизайну та Класи Еквівалентності.Розпочинаємо серію постів, присвячену надзвичайно важливій темі – технікам тест-дизайну. Навіщо вони потрібні і як можуть полегшити наше життя? 🤔📝 Що таке техніки тест-дизайну?Це систематичні підходи до створення ефективних тест-кейсів. Замість того, щоб тестувати "навмання" або намагатися перевірити абсолютно все (що часто неможливо!), ці техніки допомагають нам:🎯 Зосередитися на найважливішому: Виявити області, де помилки найбільш імовірні.⏱️ Зменшити кількість тестів: Оптимізувати тестове покриття без втрати якості.📈 Підвищити ефективність тестування: Знаходити більше дефектів за менший час.📄 Покращити структуру тестів: Робити тест-кейси більш зрозумілими та підтримуваними.Сьогодні поговоримо про одну з базових і найчастіше використовуваних технік – Класи Еквівалентності (Equivalence Partitioning).🔍 Класи Еквівалентності: Суть технікиІдея проста: ми ділимо всі можливі вхідні (або вихідні) дані на групи (класи), де система, як очікується, буде обробляти всі значення з одного класу однаково. Якщо один елемент з класу працює коректно, ми припускаємо, що й інші елементи цього класу будуть працювати так само.Як це працює?Ідентифікуємо вхідні/вихідні дані: Визначаємо, які параметри ми тестуємо.Розбиваємо на класи: Для кожного параметра виділяємо:- Валідні класи еквівалентності: Групи даних, які система повинна успішно обробити.- Невалідні класи еквівалентності: Групи даних, які система повинна відхилити або обробити як помилку.Вибираємо представників: З кожного класу беремо один типовий представник для створення тест-кейсу.Приклад:Уявімо поле для введення віку користувача (ціле число), яке приймає значення від 18 до 60 років включно.Валідні класи еквівалентності:Цілі числа від 18 до 60 (наприклад, беремо 35).Невалідні класи еквівалентності:Цілі числа менше 18 (наприклад, беремо 15).Цілі числа більше 60 (наприклад, беремо 65).Нецілі (дробові) числа (наприклад, 18.5, 30.7) – якщо система очікує саме ціле число років.Нечислові значення (наприклад, "abc").Порожнє значення.Спеціальні символи (наприклад, "!@#").Нуль (0) або від'ємні числа (-5) – можна виділити в окремі класи або включити до "менше 18", залежно від специфіки.💡 Переваги:Значно скорочує кількість необхідних тест-кейсів.Забезпечує хороше базове покриття.Допомагає структурувати мислення при аналізі вимог.#ТестДизайн #ТестуванняПЗ #КласиЕквівалентності #QA #SoftwareTesting #TestDesignTechniques #AllAboutQA

Chrome DevTools для QA - вкладка Security! 🛡️Продовжуємо інструментів розробника! На черзі, вкладка Security (Безпека) в Chrome DevTools. Хоча вона може здатися не такою часто використовуваною, як Elements або Network, вона надає важливу інформацію про безпеку поточного з'єднання та сертифікат сайту.Як QA може використовувати вкладку Security?🔐 Перевірка HTTPS та Сертифіката:Це основне призначення вкладки. Вона наочно показує, чи є поточне з'єднання безпечним (HTTPS).Main origin (Основне джерело): Ви бачите основний домен сторінки. Клікнувши на нього, можна отримати детальну інформацію про сертифікат:Certificate validity (Валідність сертифіката): Ким виданий, кому виданий, термін дії. QA може перевірити, чи сертифікат не прострочений, чи виданий довіреним центром сертифікації (CA), чи відповідає домену.Connection (З'єднання): Який протокол використовується (наприклад, TLS 1.2, TLS 1.3), який набір шифрів (cipher suite).Certificate transparency (Прозорість сертифіката): Інформація про публічні логи, де зареєстрований сертифікат.Чому це важливо для QA: Перевірка правильності налаштування HTTPS є базовою вимогою безпеки. Проблеми з сертифікатом можуть призвести до попереджень у браузері та недовіри користувачів.🚫 Виявлення Небезпечного (Mixed) Контенту: Вкладка Security допоможе виявити, якщо безпечна HTTPS-сторінка намагається завантажити ресурси (зображення, скрипти, стилі) по незахищеному HTTP. Це називається змішаним контентом.Що шукати: У секції "Secure Origins" (Безпечні джерела) та "Non-Secure Origins" (Небезпечні джерела) ви побачите, з яких доменів завантажуються ресурси. Якщо є "Non-Secure Origins" на HTTPS-сторінці, це проблема. Також на це вкажуть помилки в Console.Чому це важливо для QA: Змішаний контент знижує рівень безпеки сторінки та може бути заблокований браузером, що призведе до некоректного відображення або роботи сайту.🚦 Загальний Огляд Стану Безпеки: Вкладка дає швидкий візуальний індикатор:Зелений замок (або "Connection is secure"): Все гаразд із сертифікатом та з'єднанням основного домену.Попередження (жовтий трикутник або "Not secure" / "Your connection to this site is not secure"): Вказує на проблеми (невалідний сертифікат, змішаний контент, використання HTTP).Інформація про інші джерела: Якщо сторінка завантажує ресурси з інших доменів (наприклад, CDN, аналітика, реклама), вкладка покаже інформацію про безпеку їхніх сертифікатів.🔍 Деталі для Баг-Репортів: Якщо ви знайшли проблему, пов'язану з безпекою (наприклад, попередження про сертифікат), скріншот вкладки Security з деталями сертифіката або інформацією про змішаний контент буде дуже корисним для розробників.Як відкрити:F12 або права кнопка миші -> Inspect (Перевірити), а потім перейдіть на вкладку "Security".Хоча глибокий аналіз безпеки – це окрема сфера, вкладка Security в Chrome DevTools надає QA швидкий та зручний спосіб перевірити базові аспекти безпеки веб-сторінки, що є невід'ємною частиною забезпечення якості.

Chrome DevTools для QA - вкладка Lighthouse! 💡Ми продовжуємо нашу серію оглядів Chrome DevTools, і сьогодні на черзі вкладка, яка може стати вашим експрес-аудитором – Lighthouse! Це вбудований інструмент з відкритим кодом від Google, призначений для автоматизованого аналізу якості веб-сторінок за ключовими показниками.Як QA може використовувати вкладку Lighthouse?📊 Комплексний Аудит Сторінки:Lighthouse проводить перевірку за декількома основними категоріями:Performance (Продуктивність): Оцінює, наскільки швидко завантажується та стає інтерактивною ваша сторінка. Вимірює метрики, такі як First Contentful Paint (FCP), Largest Contentful Paint (LCP), Time to Interactive (TTI), Total Blocking Time (TBT), Cumulative Layout Shift (CLS).Accessibility (Доступність): Перевіряє, наскільки сторінка доступна для людей з обмеженими можливостями, виявляючи поширені проблеми (наприклад, відсутність alt-текстів для зображень, недостатній контраст кольорів).Best Practices (Найкращі практики): Оцінює відповідність сучасним рекомендаціям веб-розробки (використання HTTPS, відсутність помилок у консолі браузера, безпечне завантаження ресурсів тощо).SEO (Пошукова оптимізація): Проводить базові перевірки, які допомагають пошуковим системам краще індексувати вашу сторінку (наприклад, наявність тега <title>, мета-опису, коректність robots.txt).Progressive Web App (PWA): Якщо ви тестуєте PWA, Lighthouse перевірить, чи відповідає застосунок критеріям PWA (швидкість, надійність, можливість встановлення).🚀 Швидка Оцінка "Здоров'я" Сторінки:Запустивши аудит, ви отримуєте оцінку (від 0 до 100) для кожної категорії, а також детальний звіт з виявленими проблемами та рекомендаціями щодо їх виправлення. Це чудовий спосіб швидко отримати загальне уявлення про якість сторінки.🎯 Виявлення Потенційних Проблем:Lighthouse підсвічує "вузькі місця". Наприклад, якщо оцінка продуктивності низька, звіт покаже, які саме фактори на це впливають (великі зображення, блокуючі рендеринг ресурси, неефективний JavaScript).📈 Відстеження Прогресу та Регресій:Можна зберігати звіти та порівнювати їх з часом, щоб бачити, як зміни в коді впливають на якість сторінки. Це допомагає виявляти регресії продуктивності або доступності.🤝 Аргументований Фідбек для Розробників:Замість суб'єктивного "сторінка повільна", ви можете надати розробникам конкретний звіт Lighthouse з метриками та рекомендаціями, що значно полегшує діагностику та виправлення.📱 Аудит для Мобільних та Десктопних Версій:Lighthouse дозволяє проводити аудит, симулюючи перегляд з мобільного пристрою або десктопа.Як запустити аудит:Відкрийте вкладку Lighthouse.Виберіть категорії, які хочете перевірити (за замовчуванням вибрані всі основні).Виберіть режим (Mobile або Desktop).Натисніть кнопку "Analyze page load" (або "Generate report").Дочекайтеся завершення аналізу та вивчіть звіт.Важливі моменти:Результати Lighthouse можуть дещо варіюватися залежно від умов мережі та завантаженості вашого комп'ютера. Для більш стабільних результатів запускайте аудит в режимі Інкогніто та з вимкненими розширеннями.Lighthouse – це інструмент для автоматичного аналізу, він не замінює ручне тестування, особливо для перевірки логіки та UX.Рекомендації Lighthouse є цінними, але не завжди всі з них можуть бути реалізовані на 100% через специфіку проєту.Як відкрити:F12 або права кнопка миші -> Inspect (Перевірити), а потім перейдіть на вкладку "Lighthouse".Вкладка Lighthouse дає QA можливість швидко та об'єктивно оцінити різні аспекти якості веб-сторінки, надаючи корисні інсайти та допомагаючи покращити кінцевий продукт. Не бійтеся натискати "Generate report"!

Chrome DevTools для QA - вкладка Recorder! 🎬Продовжуємо досліджувати Chrome DevTools! Сьогодні в центрі уваги відносно нова, але надзвичайно перспективна вкладка – Recorder (Записувач). Це ваш особистий помічник для запису, відтворення та аналізу користувацьких сценаріїв прямо в браузері.Як QA може використовувати вкладку Recorder?📝 Запис користувацьких сценаріїв (User Flows):Замість ручного проходження одних і тих самих кроків знову і знову (наприклад, реєстрація, логін, додавання товару в кошик), ви можете один раз записати їх. Recorder фіксує кліки, введення тексту, навігацію та інші взаємодії.🤖 Генерація коду для автотестів (Puppeteer, @puppeteer/replay, JSON та ін.):Найцікавіше! Recorder може експортувати записаний сценарій у вигляді коду, наприклад, для Puppeteer (популярна Node.js бібліотека для автоматизації Chrome) або у форматі JSON для бібліотеки @puppeteer/replay. Це чудовий старт для написання простих автотестів або для швидкого прототипування, навіть якщо ви тільки починаєте вивчати автоматизацію.▶️ Відтворення та налагодження сценаріїв:Записаний сценарій можна відтворити прямо у вкладці, щоб перевірити, чи все працює, як очікувалося. Якщо щось пішло не так, можна переглянути кожен крок, додати/видалити/змінити його (наприклад, селектори, значення), або встановити точки зупинки (breakpoints) для детального аналізу.⏱️ Вимірювання продуктивності (базове):Під час відтворення можна отримати деякі дані про продуктивність виконання сценарію. Хоча для глибокого аналізу краще підійде вкладка Performance, Recorder дає швидкий огляд "на місці".🐛 Допомога у відтворенні багів:Записали складний баг? Експортуйте сценарій (наприклад, як JSON) і прикріпіть до баг-репорту. Це може значно допомогти розробникам відтворити проблему, побачивши точну послідовність дій.🔄 Автоматизація рутинних перевірок:Швидко перевірити базовий функціонал після невеликих змін? Запустіть записаний сценарій. Це не замінить повноцінні автотести, але може зекономити час на простих регресійних перевірках.💡 Важливо розуміти:Recorder – це не повноцінна заміна для фреймворків автоматизації (Selenium, Cypress, Playwright), особливо для складних тестів з динамічним контентом, великою кількістю перевірок чи інтеграцій.Згенерований код часто потребує доопрацювання та рефакторингу для стабільності (наприклад, використання надійніших селекторів, додавання явних очікувань).Добре підходить для простих, лінійних сценаріїв та як допоміжний інструмент.Як відкрити: F12 або права кнопка миші -> Inspect (Перевірити). Якщо вкладки Recorder немає одразу, натисніть три крапки (More options) -> More tools -> Recorder.Вкладка Recorder відкриває нові можливості для QA, особливо для тих, хто хоче спробувати себе в автоматизації або просто прискорити рутинні перевірки. Експериментуйте, записуйте, автоматизуйте!

Chrome DevTools для QA - вкладка Console! ⚙️Продовжуємо подорож по Chrome DevTools! На черзі вкладка Console (Консоль) – ваш командний центр для взаємодії з JavaScript сторінки та відстеження її "здоров'я". Якщо вкладка Elements – це про структуру та вигляд, то Console – про логіку та події "під капотом".Як QA може використовувати вкладку Console?🐞 Відстеження помилок JavaScript:Перше, що кидається в очі – червоні повідомлення про помилки. Консоль показує помилки JavaScript, які виникають на сторінці під час її завантаження або взаємодії. Це критично важливо для репортингу багів – точне повідомлення про помилку та інформація, звідки вона походить, допомагають розробникам швидше знайти проблему.📜 Перегляд логів від розробників (і не тільки):Розробники часто використовують console.log(), console.warn(), console.error() для виведення налагоджувальної інформації. Це може дати підказки про те, що відбувається "під капотом", які дані обробляються, або на якому етапі щось пішло не так. Ви також можете використовувати ці команди для власних перевірок!⚡ Виконання JavaScript "на льоту":Консоль дозволяє виконувати будь-який JavaScript-код прямо на сторінці.Що це дає QA?Змінити значення змінної: Наприклад, app.user.isAdmin = true; щоб перевірити адмінські функції без реального входу як адмін.Викликати функцію: validateForm(); щоб протестувати валідацію форми без заповнення всіх полів.Перевірити стан об'єктів: console.log(window.currentUserData); щоб побачити, які дані користувача завантажені.Швидко симулювати сценарії: Наприклад, змінити стан якогось перемикача програмно.🖐️ Взаємодія з DOM (альтернативно до Elements):Хоча вкладка Elements краще для візуального аналізу, з консолі теж можна маніпулювати DOM.Отримати елемент: let myButton = document.getElementById('submitBtn');Симулювати клік: document.querySelector('.important-button').click(); – корисно для перевірки обробників подій.🔍 Фільтрація та очищення виводу:Якщо логів забагато, використовуйте фільтри (за типом: Errors, Warnings, Info, Verbose; або за текстом). Іконка "Очистити консоль" (або Ctrl+L / Cmd+K на macOS) допоможе почати з чистого аркуша.⏳ Розуміння асинхронних операцій:Часто баги виникають через проблеми з асинхронними запитами (наприклад, до API). Помилки або логи, пов'язані з Promise або fetch, часто з'являються саме тут, даючи зрозуміти, чи успішно виконався запит.Як відкрити:Так само, як і Elements: клавіша F12 або права кнопка миші -> Inspect (Перевірити), а потім перейдіть на вкладку "Console".Вкладка Console – це потужний інструмент для діагностики, швидких перевірок та глибшого розуміння роботи JavaScript на вашому сайті. Не бійтеся експериментувати з нею!

Chrome DevTools для QA - вкладка Elements! 🔍Chrome DevTools - один з найкорисніших інструментів у нашому арсеналі. Почнемо з вкладки Elements у Chrome DevTools (і подібних інструментах в інших браузерах). Це наше вікно у HTML-структуру та CSS-стилі сторінки.Як QA може використовувати вкладку Elements?🕵️‍♀️ Пошук локаторів для автотестів:Найпростіше: Правою кнопкою на елемент -> Copy -> Copy selector / Copy XPath.Надійніше: Аналізуйте структуру, шукайте унікальні id, інформативні class, data-testid або інші атрибути для створення стабільних CSS-селекторів чи XPath.✅ Перевірка наявності та атрибутів елементів:Чи існує кнопка/поле/текстовий блок на сторінці?Чи правильні id, class, name, placeholder, value, href та інші атрибути?Чи містить елемент очікуваний текст?🐛 Відловлення UI багів:Елемент не видно? Шукайте стилі display: none;, visibility: hidden;, opacity: 0; або перевірте, чи не перекритий він іншим елементом (z-index).Елемент "поїхав"? Досліджуйте margin, padding, position, width, height у панелі "Styles".🎨 Аналіз CSS-стилів:Чи відповідають кольори, шрифти, розміри, відступи макету/вимогам? Панель "Styles" показує всі застосовані стилі та звідки вони успадковані (зручно для розуміння каскадності). Вкладка "Computed" показує фінальні, розраховані браузером стилі.✍️ Динамічна зміна контенту/стилів "на льоту":Хочете перевірити, як виглядатиме дуже довгий текст у полі? Двічі клікніть на текст в HTML і змініть його.Хочете швидко перевірити інший колір кнопки? Знайдіть відповідний стиль у панелі "Styles" і змініть значення.Це дозволяє швидко експериментувати та знаходити граничні випадки без залучення розробників.📱 Тестування адаптивності (Responsiveness):Натисніть іконку "Toggle device toolbar" (схожа на телефон/планшет).Вибирайте різні пристрої (iPhone, Pixel, iPad...), змінюйте орієнтацію та перевіряйте, як верстка адаптується.🖱️ Перегляд Event Listeners:Хочете знати, що відбувається при кліку на елемент? Вкладка "Event Listeners" (зазвичай підпанель у "Styles") покаже, які обробники подій (click, mouseover тощо) прив'язані до вибраного елемента.Як відкрити:Найпростіше – клавіша F12 або клік правою кнопкою миші на будь-якому елементі сторінки -> Inspect (Перевірити).Вкладка Elements – це не просто перегляд коду, це потужний інструмент для аналізу, налагодження та глибшого розуміння того, як працює фронтенд.