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

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

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

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

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

📋 Як написати тест-кейс, який буде корисним команді Тест-кейс повинен допомагати іншому тестувальнику повторити перевірку та отримати зрозумілий результат. Якщо кроки описані нечітко, тестування стає менш передбачуваним. 1. Сформулюйте зрозумілу назву Назва повинна коротко пояснювати, яку функцію або сценарій потрібно перевірити. 2. Опишіть передумови Зазначте, які умови повинні бути виконані перед початком тесту. 3. Додайте тестові дані Вкажіть необхідні значення, акаунти або інші дані для перевірки. 4. Розпишіть кроки Кожен крок повинен бути конкретним і зрозумілим без додаткових пояснень. 5. Опишіть очікуваний результат Зазначте, що саме повинна зробити система після виконання сценарію. 6. Уникайте неоднозначності Фрази на кшталт «перевірити, чи все працює» не пояснюють, який результат вважається правильним. Висновок: якісний тест-кейс має бути зрозумілим, відтворюваним і давати можливість однозначно оцінити результат перевірки. Комора тестувальника

🐛 Як правильно визначати пріоритет бага Не кожен баг потрібно виправляти негайно. QA має допомогти команді зрозуміти, наскільки проблема впливає на користувачів і роботу продукту. 1. Оцініть вплив на функціонал Якщо через баг не працює важлива функція, проблема може потребувати швидкого виправлення. 2. Перевірте кількість користувачів Зверніть увагу, чи проблема стосується всіх користувачів або лише окремого сценарію. 3. Оцініть наявність обходу Якщо користувач може виконати дію іншим способом, це може впливати на пріоритет. 4. Врахуйте бізнес-контекст Помилка в критичному процесі може бути важливішою за візуальний дефект на другорядній сторінці. 5. Відокремте severity від priority Severity описує серйозність впливу бага, а priority — терміновість його виправлення. Висновок: пріоритет бага варто визначати за його впливом, ризиками та потребами продукту, а не лише за тим, наскільки помітною здається помилка. Комора тестувальника

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

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

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

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

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

⚡️ Думка про зміну роботи з'являється все частіше, але незрозуміло — куди йти далі? Data Analytics — один із напрямів, куди можна перейти з абсолютно різним бекграундом. Тут не потрібно ставати розробником: основа професії — логіка, робота з даними та вміння знаходити в цифрах відповіді на реальні питання бізнесу. І найкраще — професію не обов'язково обирати навмання. GoIT запускає безкоштовний 4-денний марафон, де можна спочатку спробувати себе в ролі Data Analyst 👇

🔹 попрацювати з SQL та Google BigQuery 🔹 проаналізувати реальні дані 🔹 створити власний аналітичний проєкт 🔹 побачити, як виглядає робота аналітика зсередини

4 дні — щоб замість «треба щось змінювати» нарешті спробувати конкретний напрям. Можливо, саме Data Analytics стане вашим наступним професійним кроком. 🕓 Онлайн 💰 Безкоштовно 👉 Спробувати себе в Data Analytics: https://i.goit.global/iaVuG

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

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

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

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

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

✈️ У web або mobile QA баг можна відтворити ще раз. У тестуванні БПЛА помилка може означати втрачений борт, зірваний виліт і краш, причину якого ще потрібно знайти. Як перенести QA-навички в UAV та зробити світч в MilTech — навчитеся на курсі «UAV QA Engineer» від robot_dreams. Після 19 занять ви: 🔹 переноситимете частину ризикових перевірок у SITL 🔹 тестуватимете прошивки, режими польоту та failsafe-сценарії 🔹 перевірятимете hardware і радіотракт до виїзду на полігон 🔹 працюватимете з ArduPilot, Betaflight і наземними станціями керування 🔹 аналізуватимете Blackbox і телеметрію після збоїв 🔹 визначатимете, де причина проблеми: у hardware, firmware, конфігурації чи зв’язку 🔹 оформлюватимете тест-кейси й баг-репорти так, щоб результат міг відтворити інший інженер У фіналі — підготуєте повний QA-кейс БПЛА та аргументований висновок щодо готовності борта до подальших випробувань. Старт: 26 листопада Деталі, програма та реєстрація ⬅️

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

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