🇺🇦 Комора тестувальника | QA Info

🚀 Що перевірити під час завантаження сторінки Швидкість і стабільність завантаження впливають на весь користувацький сценарій. Навіть якщо сторінка зрештою відкривається правильно, під час завантаження можуть виникати окремі проблеми. 1. Перевірте початковий стан Подивіться, що бачить користувач одразу після відкриття сторінки. 2. Перевірте loading-стан Якщо дані завантажуються не одразу, користувач повинен бачити зрозумілий стан завантаження. 3. Перевірте повільне з'єднання Повільна мережа може показати проблеми, яких не видно при стабільному інтернеті. 4. Перевірте помилку завантаження Якщо дані не вдалося отримати, система повинна показати зрозумілу реакцію. 5. Перевірте повторну спробу Якщо завантаження завершилося помилкою, перевірте можливість повторити операцію, якщо така функція передбачена. 6. Перевірте Console та Network DevTools допомагає побачити помилки та невдалі запити, які можуть пояснити проблему. Висновок: тестувати потрібно не тільки готову сторінку, а й усі стани, через які користувач проходить під час її завантаження. Комора тестувальника

📧 Що перевірити під час тестування email-функцій Email-повідомлення можуть бути частиною реєстрації, відновлення пароля, замовлення або інших важливих сценаріїв. Тому важливо перевіряти не лише факт відправлення листа. 1. Перевірте факт відправлення Після виконання потрібної дії лист повинен надсилатися, якщо це передбачено вимогами. 2. Перевірте отримувача Переконайтеся, що повідомлення приходить на правильну адресу. 3. Перевірте тему листа Тема повинна відповідати події та допомагати користувачу зрозуміти призначення повідомлення. 4. Перевірте текст У листі не повинно бути помилок, неправильних даних або непрацюючих посилань. 5. Перевірте посилання Якщо лист містить кнопку або посилання, перевірте, що воно веде на правильну сторінку. 6. Перевірте повторну відправку Якщо користувач може запросити лист повторно, перевірте, як система поводиться з кількома запитами. Висновок: email-функції потрібно перевіряти як повноцінний користувацький сценарій — від моменту дії в системі до отримання та відкриття листа. Комора тестувальника

🔄 Чому варто перевіряти стан після оновлення сторінки Користувачі часто оновлюють сторінку випадково або навмисно. Тому важливо розуміти, які дані повинні зберігатися після refresh, а які можуть скидатися. 1. Перевірте введені дані Якщо користувач заповнив форму, подивіться, чи повинні введені значення залишатися після оновлення. 2. Перевірте вибрані фільтри Застосуйте декілька фільтрів і оновіть сторінку, щоб перевірити очікувану поведінку. 3. Перевірте авторизацію Користувач не повинен несподівано втрачати сесію, якщо за вимогами вона має залишатися активною. 4. Перевірте поточну сторінку Якщо користувач перебував на третій сторінці списку, перевірте, що відбувається після оновлення. 5. Перевірте незавершені дії Якщо під час оновлення виконується операція, система повинна коректно обробити такий сценарій. 6. Перевірте повідомлення Тимчасові повідомлення або помилки не повинні залишатися після оновлення, якщо вони більше не актуальні. Висновок: refresh — це окремий сценарій, який варто перевіряти для форм, списків, фільтрів, авторизації та інших важливих частин системи. Комора тестувальника

📄 Що перевірити під час тестування пагінації Пагінація допомагає працювати з великими списками, але саме на межі сторінок часто виникають непомітні помилки. 1. Перевірте першу сторінку На початку списку кнопка переходу назад повинна бути недоступною, якщо це передбачено дизайном. 2. Перейдіть на наступну сторінку Переконайтеся, що відображаються наступні записи, а не дублюється попередній список. 3. Перевірте останню сторінку Кнопка переходу вперед повинна працювати відповідно до кількості доступних сторінок. 4. Перевірте невелику кількість результатів Якщо результатів менше, ніж потрібно для повної сторінки, система повинна правильно відобразити останній список. 5. Перевірте зміну кількості елементів Якщо користувач може вибрати 10, 25 або 50 записів на сторінці, перевірте кожен варіант. 6. Поєднайте пагінацію з фільтрами Після застосування фільтра кількість сторінок повинна перераховуватися коректно. Висновок: основну увагу під час тестування пагінації варто приділяти першій, останній та неповній сторінкам. Комора тестувальника

👀 86 відгуків на одну Front-end вакансію. А в Defense Tech — у середньому близько 9. І це привід придивитися до сфери, якщо ви думаєте, куди рухатися далі. Поки в класичному IT конкуренція залишається високою, MilTech набирає обертів: з’являються нові команди, продукти та технології — а разом із ними потрібні нові спеціалісти. І далеко не тільки розробники 👇

→ Project та Product Managers → QA-фахівці → Hardware та Embedded спеціалісти → аналітики та інші tech-фахівці

Тож MilTech може стати тим самим напрямом, куди варто зайти зараз, а не тоді, коли про нього говоритимуть уже всі. А який напрям у MilTech може підійти саме вам? GoIT створили короткий безкоштовний тест: 3 хвилини — і ви дізнаєтесь свій MilTech-напрям, його потенціал та отримаєте рекомендацію, з чого почати. 👉 Пройти тест: https://i.goit.global/2aXRO

↕️ Що перевірити під час тестування сортування Сортування може працювати правильно на простих даних, але показувати проблеми на однакових значеннях, порожніх полях або великих списках. 1. Перевірте сортування за зростанням Переконайтеся, що значення відображаються у правильному порядку. 2. Перевірте сортування за спаданням Повторіть перевірку у зворотному напрямку та порівняйте результати. 3. Перевірте однакові значення Подивіться, як система поводиться, якщо декілька записів мають однакове значення для сортування. 4. Перевірте порожні значення Якщо частина записів не має значення для вибраного поля, перевірте, де вони повинні відображатися. 5. Перевірте сортування після фільтрації Застосуйте фільтр, а потім сортування. Обидві функції повинні працювати разом без втрати результатів. 6. Перевірте сортування після оновлення Після перезавантаження сторінки зверніть увагу, чи повинне вибране сортування зберігатися. Висновок: сортування потрібно перевіряти на різних типах даних і разом із фільтрами, пошуком та пагінацією. Комора тестувальника

Найбільша українська онлайн конференція з якості та тестування «Бетельгейзе-2026». Вже цієї суботи! 📅 17-18 жовтня. День доповідей та окремий день дискусій. 🟠16 спікерів 🟠12 доповідей 🟠7 дискусій 🟠записи всіх відео. Унікальний формат: 🟠для доповідей: після кожної на "сцену" долучається експертна група для міні-обговорення про почуте 🟠для дискусій: кожна має опонента (Boogieman, Бабайка), який спробує ставити під сумнів тези обговорення Про конференцію | Спікери | Дискутанти | Програма

⚠️ Чому потрібно тестувати повідомлення про помилки Помилка в системі — це не лише проблема самої функції. Важливо також перевірити, що користувач розуміє, що сталося і що йому робити далі. 1. Перевірте текст повідомлення Воно повинно бути зрозумілим і відповідати ситуації, яка виникла. 2. Перевірте момент появи Повідомлення повинно з'являтися тоді, коли користувач дійсно стикається з проблемою. 3. Перевірте зникнення повідомлення Після виправлення помилки старе повідомлення не повинно залишатися на екрані без причини. 4. Перевірте повторну спробу Користувач повинен мати можливість повторити дію після виправлення проблеми, якщо це передбачено функціоналом. 5. Перевірте різні сценарії Одна функція може мати декілька причин для помилки, і для кожної з них повідомлення може відрізнятися. 6. Перевірте мобільну версію Довгий текст помилки не повинен ламати верстку або перекривати інші елементи. Висновок: повідомлення про помилки теж потрібно тестувати, адже зрозуміла реакція системи є важливою частиною користувацького сценарію. Комора тестувальника

🎯 Що перевірити під час тестування фільтрів Фільтри часто працюють разом із пошуком, сортуванням та пагінацією. Через це помилка в одному елементі може вплинути на весь список. 1. Перевірте кожен фільтр окремо Виберіть одне значення та переконайтеся, що список змінюється відповідно до вибраної умови. 2. Перевірте кілька фільтрів Спробуйте одночасно вибрати декілька параметрів і перевірте, чи система правильно поєднує їх. 3. Перевірте скидання фільтрів Після натискання кнопки скидання всі вибрані значення повинні повертатися до початкового стану. 4. Перевірте відсутність результатів Якщо жоден елемент не відповідає умовам, користувач повинен побачити зрозуміле повідомлення. 5. Перевірте фільтри після оновлення сторінки Зверніть увагу, чи повинні вибрані параметри зберігатися після перезавантаження. 6. Перевірте поєднання з пагінацією Після застосування фільтра кількість сторінок і доступні результати повинні оновлюватися правильно. Висновок: фільтри варто тестувати не тільки окремо, а й у комбінації з іншими елементами, які працюють зі списком даних. Комора тестувальника

💻 Чому варто перевіряти різні ролі користувачів Одна й та сама сторінка може працювати по-різному залежно від прав користувача. Тому тестування лише під одним акаунтом може залишити важливі проблеми непоміченими. 1. Перевірте звичайного користувача Переконайтеся, що він бачить лише ті функції, які йому доступні. 2. Перевірте адміністратора Адміністратор може мати додаткові можливості, тому їх потрібно перевірити окремо. 3. Перевірте доступ до сторінок Спробуйте відкрити захищену сторінку напряму, без відповідних прав. 4. Перевірте дії з обмеженнями Користувач не повинен мати можливості виконати заборонену дію лише через пряме посилання або API-запит. 5. Порівняйте поведінку ролей Переконайтеся, що різниця між ролями відповідає вимогам і налаштуванням доступу. Висновок: тестування різних ролей допомагає знаходити проблеми з доступами, які неможливо побачити під час перевірки одного типу користувача. Комора тестувальника

🔎 Що перевірити під час тестування пошуку Пошук може здаватися простим функціоналом, але він має багато сценаріїв, які легко пропустити під час звичайної перевірки. 1. Перевірте точний запит Введіть повну назву або точне значення та переконайтеся, що система показує очікувані результати. 2. Перевірте частину слова Спробуйте ввести лише кілька символів. Пошук повинен працювати відповідно до логіки, передбаченої вимогами. 3. Перевірте неправильний запит Введіть значення, якого немає в системі. Повідомлення про відсутність результатів повинно бути зрозумілим. 4. Перевірте пробіли Спробуйте додати пробіли на початку, в кінці або між словами та подивіться, як система обробляє такий запит. 5. Перевірте регістр Якщо пошук не залежить від регістру, результати для великих і маленьких літер повинні бути однаковими. 6. Перевірте очищення пошуку Після видалення запиту або натискання кнопки очищення результати повинні оновлюватися коректно. Висновок: хороший пошук потрібно перевіряти не лише на правильному запиті, а й на порожніх, неправильних, коротких та нестандартних значеннях. Комора тестувальника

⏱️ Що перевірити після тривалого очікування Не всі проблеми виникають одразу. Деякі баги проявляються після довгого очікування, великої кількості дій або тривалого перебування користувача в системі. 1. Залиште сторінку відкритою Перевірте, чи не виникають помилки після тривалого простою. 2. Перевірте завершення сесії Користувач повинен отримати правильну поведінку після завершення авторизаційної сесії. 3. Повторіть дію після очікування Переконайтеся, що кнопки, форми та інші елементи продовжують працювати. 4. Перевірте дані Після тривалого очікування введена інформація не повинна зникати або ставати некоректною. 5. Перевірте Console і Network Подивіться, чи не з'являються помилки після тривалої бездіяльності. Висновок: перевірка після тривалого очікування допомагає знаходити проблеми із сесіями, таймаутами, кешем та станом застосунку. Комора тестувальника

🕵️ Як зрозуміти, що баг потрібно дослідити глибше Іноді QA знаходить проблему, але перший опис не пояснює, за яких саме умов вона виникає. Додаткове дослідження допомагає краще зрозуміти проблему та передати розробнику корисну інформацію. 1. Спробуйте повторити баг Переконайтеся, що проблема справді відтворюється, і визначте точні кроки. 2. Змініть одну умову Наприклад, використайте інший акаунт або браузер. Це допоможе зрозуміти, від чого залежить проблема. 3. Перевірте Console Помилки браузера можуть дати підказку щодо причини несправності. 4. Перевірте Network Подивіться, чи правильно виконуються запити та які відповіді повертає сервер. 5. Спробуйте знайти закономірність Якщо баг виникає лише за певних умов, обов'язково зафіксуйте їх у баг-репорті. Висновок: чим краще QA досліджує проблему до створення баг-репорту, тим більше корисної інформації отримує команда для її виправлення. Комора тестувальника

📊 Data Analytics — одна з тих сфер, де попит на спеціалістів зростає швидше, ніж ринок встигає їх готувати. Причина проста. Компанії вже давно навчилися збирати дані. Тепер їм потрібні люди, які можуть ці дані зрозуміти та перетворити на конкретні рішення для бізнесу. Саме тому аналітиків шукають у:

▪️ IT ▪️ e-commerce ▪️ маркетингу ▪️ фінансах ▪️ логістиці ▪️ продуктових компаніях

На безкоштовному марафоні від GoIT покажемо, як виглядає професія зсередини та які навички потрібні для розвитку в цьому напрямі. Ви дізнаєтесь: 🔖 як працюють аналітики даних 🔖 де використовується SQL 🔖 які кар'єрні можливості відкриває Data Analytics 🕓 Онлайн | Безкоштовно 👉 Реєстрація: https://i.goit.global/gaZ5F

🗂 Що важливо перевірити під час роботи з файлами Функціонал завантаження файлів часто виглядає простим, але має багато можливих сценаріїв, які потрібно протестувати. 1. Завантажте правильний файл Переконайтеся, що підтримуваний формат успішно завантажується та обробляється системою. 2. Перевірте неправильний формат Спробуйте завантажити файл, який система не повинна приймати. 3. Перевірте розмір файлу Використайте файл на межі допустимого розміру та файл, який перевищує встановлене обмеження. 4. Перевірте назву файлу Довгі назви, пробіли та спеціальні символи можуть спричинити несподівану поведінку. 5. Перевірте повторне завантаження Спробуйте завантажити той самий файл кілька разів і переконайтеся, що система правильно обробляє дублікати. Висновок: під час тестування файлів потрібно враховувати не лише формат, а й розмір, назву, кількість завантажень та поведінку системи при помилках. Комора тестувальника

🧪 Як перевіряти нову кнопку Навіть звичайна кнопка може мати багато різних сценаріїв поведінки. Не варто перевіряти лише те, що після одного кліку відбувається очікувана дія. 1. Натисніть кнопку один раз Переконайтеся, що запускається саме та дія, яка описана у вимогах. 2. Натисніть кілька разів Перевірте, чи не створюються дублікати або повторні запити. 3. Перевірте стан кнопки Зверніть увагу на disabled, loading та інші стани, якщо вони передбачені. 4. Перевірте помилковий сценарій Якщо дія не може бути виконана, користувач повинен отримати зрозуміле повідомлення. 5. Перевірте мобільну версію Кнопка повинна залишатися доступною та зручною для натискання на маленькому екрані. Висновок: навіть один елемент інтерфейсу потрібно перевіряти в різних станах і сценаріях, а не лише за основним позитивним випадком. Комора тестувальника

📱 Що перевіряти під час тестування мобільного застосунку Мобільний застосунок має працювати в різних умовах, а користувач може взаємодіяти з ним зовсім не так, як із вебверсією. 1. Перевірте різні розміри екрана Елементи інтерфейсу не повинні виходити за межі екрана або перекривати один одного. 2. Перевірте поворот пристрою Після переходу з вертикального режиму в горизонтальний інтерфейс повинен залишатися коректним. 3. Перевірте роботу клавіатури Клавіатура не повинна перекривати важливі поля або кнопки. 4. Перевірте роботу без інтернету Якщо застосунок передбачає offline-режим, перевірте, що відбувається після втрати з'єднання. 5. Перевірте переривання Вхідний дзвінок, повідомлення або згортання застосунку не повинні призводити до втрати даних. Висновок: мобільне тестування потребує перевірки не лише самого інтерфейсу, а й різних умов, у яких користувач може опинитися. Комора тестувальника

🔄 Що перевірити після зміни існуючого функціоналу Будь-яка зміна в системі може вплинути на функції, які раніше працювали без проблем. Саме тому після оновлення важливо перевірити не лише нову поведінку, а й старий функціонал. 1. Перевірте змінену функцію Переконайтеся, що вона тепер працює відповідно до нових вимог. 2. Перевірте старий сценарій Спробуйте виконати звичні дії, які працювали до внесення змін. 3. Перевірте пов'язані функції Якщо один модуль використовує дані іншого, зміни можуть вплинути на обидва. 4. Перевірте різні ролі Різні користувачі можуть мати різні права та бачити різний функціонал. 5. Проведіть regression Пройдіться по ключових сценаріях, щоб переконатися, що оновлення нічого не зламало. Висновок: після зміни функціоналу важливо перевіряти не тільки те, що було змінено, а й те, що може залежати від цих змін. Комора тестувальника

🐞 Чому один і той самий баг варто перевіряти на різних даних Багато багів залежать не лише від дій користувача, а й від даних, з якими працює система. Тому один успішний тест ще не гарантує, що функціонал працює правильно в усіх ситуаціях. 1. Перевірте звичайні дані Спочатку використайте стандартні значення, які найчастіше вводитиме користувач. 2. Перевірте порожні значення Залиште поля порожніми та подивіться, як система обробляє таку ситуацію. 3. Перевірте мінімальні та максимальні значення Якщо поле має обмеження, протестуйте значення на самій межі та за її межами. 4. Використайте довгий текст Дуже довгі значення можуть спричинити проблеми з валідацією, версткою або збереженням. 5. Перевірте спеціальні символи Спробуйте символи, пробіли, емодзі та інші нестандартні значення, якщо вони можуть бути введені користувачем. Висновок: чим різноманітніші тестові дані, тим більше шансів знайти баги, які не проявляються на стандартних значеннях. Комора тестувальника

🔐 Що перевірити під час тестування авторизації Авторизація здається простим функціоналом, але саме тут можуть виникати проблеми з даними, сесіями та доступом до різних частин системи. Тому перевіряти її потрібно не лише на правильний логін і пароль. 1. Перевірте правильні дані Користувач повинен успішно увійти до системи, якщо вводить коректний логін і пароль. 2. Перевірте неправильний пароль Система не повинна дозволяти вхід і має показати зрозуміле повідомлення про помилку. 3. Перевірте порожні поля Спробуйте натиснути кнопку входу, нічого не вводячи. Повідомлення про помилки повинні бути зрозумілими для користувача. 4. Перевірте вихід із системи Після натискання кнопки виходу користувач не повинен залишатися авторизованим. 5. Перевірте повторний вхід Після виходу спробуйте знову авторизуватися та переконайтеся, що сесія створюється правильно. 6. Перевірте відновлення пароля Переконайтеся, що користувач може пройти весь сценарій відновлення пароля та отримати необхідне повідомлення або посилання. 7. Перевірте доступ після завершення сесії Якщо сесія користувача завершилася, він не повинен отримувати доступ до захищених сторінок без повторної авторизації. Висновок: авторизація потребує перевірки не лише позитивного сценарію, а й усіх ситуацій, які можуть виникнути під час входу, виходу та роботи із сесією. Комора тестувальника