Мої правила успішного тестування програмного забезпечення

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Всім привіт! Я Юлія, Manual QA Engineer у Kiss My Apps. У компанії ми спеціалізуємось на розробці Mobile first-продуктів. Маю понад три роки досвіду в тестуванні програмного забезпечення. У цій статті я розповім про ключові аспекти успішного тестування, які справді варті вашої уваги.

Як переконатися, що ваш продукт якісний та працює, як очікується? Ключ до забезпечення якості вашого програмного продукту — це дотримання визначених правил тестування. Це не тільки допомагає виявляти помилки та баги, але й запобігає їхній появі. А відтак робить користувачів задоволеними продуктом, а також знижує витрати на розробку та підтримку для нас.

З власного досвіду можу сказати, що значно ефективніше витратити більше часу на планування, розподіл обов’язків і оновлення документації, ніж потім намагатися в авральному режимі виправляти помилки на продакшені.

Отже, в цій статті я поділюсь з вами основними правилами під час тестування програмного забезпечення, які допомагають мені в роботі. Поїхали!

Повнота тестування

На першому етапі ми повинні врахувати всі можливі сценарії тестування. Наприклад, важливо перевірити, як застосунок працює на різних браузерах, операційних системах та пристроях.

На моєму досвіді траплялися випадки, коли критичні помилки на продакшні відтворювались лише на одній версії iOS або Android. Або ж нові функції не відпрацьовувалися саме на конкретній версії браузера.

Визначення «повноти» індивідуальне для кожного проєкту. Тут варто враховувати вибірку юзерів, на яких орієнтується ваш проєкт, та додавати аналітику. Також треба моніторити випуски оновлень операційних систем, аби запобігати можливим конфліктам вашого програмного забезпечення з тією чи іншою версією iOS або Android тощо.

Розділення обов’язків

Координація та чіткий розподіл обов’язків можуть зробити тестування значно ефективнішим. Розподіліть відповідальність за тестування між різними командами або особами, щоб забезпечити об’єктивність. Важливо, щоб кожен член команди чітко розумів свої обов’язки та ролі.

Такий розподіл можна налагодити завдяки чітким описам для кожного члена команди:

• розробники відповідають за написання модульних тестів;
• команда аналітиків бере участь у оцінці ризиків та пріоритетів у тестуванні;
• QA Automation Engineer розробляє, підтримує та оптимізує автоматизовані тести;
• Manual QA Tester створює тест-кейси, проводить функціональне, нефункціональне, регресійне, кросплатформне та адхок-тестування, документує результати.

Відокремлення тестових сценаріїв

Деякі флоу роботи програми вимагають виконання тестових сценаріїв, у яких тести повинні бути ізольованими, щоб результати одних не впливали на результати інших. Надто якщо мовиться про основну роботу програми.

Коли один тест вимагає попереднього виконання іншого, це може призвести до неправильних результатів. Це важливо, оскільки взаємозалежність тестів може призводити до складнощів у відстеженні та ідентифікації джерела проблеми. Так можна краще відстежувати помилки та швидше їх фіксити.

Наприклад, на одному з проєктів ми стикнулися з ситуацією, коли тести були залежні один від одного. Один тест перевіряв створення користувача, а інший — його видалення. Якщо тест на створення користувача провалювався, то тести на видалення автоматично теж провалювалися, хоча сама функціональність видалення раніше створеного юзера (до внесення оновлень ПЗ) відпрацьовувала без помилок. Якщо розмежувати ці кейси, матимемо чіткіші флоу відтворення багів.

Структурованість тестування

Правильна організація — половина успіху вашого тестування. Тести повинні бути структурованими та організованими для ефективного виявлення помилок. Наприклад, використання тестових кейсів та планування тестування за допомогою матриць, а також регулярне оновлення тестової документації.

На нашій практиці ми завжди створюємо тестові сценарії та підтримуємо їх в актуальному стані, що дозволяє швидко орієнтуватися в процесі тестування та оперативно реагувати на зміни у вимогах. Це як мати дорожню карту під час подорожі — допомагає не заблукати та дістатися до пункту призначення.

Пріоритезація тестів

Як у щоденному житті ми ставимо в пріоритет якісь задачі перед іншими, так і тести повинні бути відсортовані залежно від їхньої важливості та впливу на продукт. Якщо критичні помилки будуть виявлені та виправлені на ранніх етапах, ризик невдачі під час релізу значно знижується. Це особливо важливо в умовах обмежених ресурсів та стислих термінів.

Наприклад, у продуктах, де транзакції користувачів є найважливішою частиною системи, ми пріоритезуємо тести для перевірки коректності обробки транзакцій, залишивши менш критичні функції на пізніший етап. Зрештою маємо таку послідовність визначення пріоритетів: аналіз бізнес цілей -> визначення критичності функцій -> регулярний перегляд пріоритетів.

Ретельне планування тестування

Тестування може здаватися складним, але правильний підхід та планування — ключ до успіху. Плануйте тестування заздалегідь, враховуючи ресурси та час релізів. Це допоможе уникнути затримок та отримати справді якісний продукт. Але з чого ж починати?

Першим кроком буде визначення чітких цілей тестування. Треба відповісти собі на низку запитань:

1. Що саме ви хочете досягти?
2. Які аспекти продукту потребують найбільшої уваги?

Другим кроком стане визначення ключових метрик, які ви будете використовувати для оцінки успіху. Я також рекомендую робити планування з запасом часу, адже це дозволяє врахувати потенційні ризики та непередбачені проблеми, що можуть виникнути в процесі тестування. Це також допоможе бути готовими до можливих затримок через виявлення та виправлення помилок.

Регулярне виконання тестів

З чого починається ваш ранок? Знаю, з щоденної перевірки своїх соціальних мереж на нові повідомлення. Те саме можна сказати й про тести, їх слід виконувати регулярно. Це допомагає швидко виявляти проблеми та забезпечувати стабільність програмного забезпечення.

Наприклад, автоматизовані тести мають бути запущені щоденно у визначений командою час. Це особливо важливо для великих проєктів з частими змінами в коді, де кожна нова функція або виправлення можуть вплинути на роботу системи. Регулярне тестування дозволяє відстежувати продуктивність системи в різних умовах і виявляти потенційні проблеми до їхньої появи в реальному середовищі.

Використання різних методів тестування

Тестування — це неодмінна та цікава частина розробки. Існує безліч різних методів тестування, як-от модульне тестування, інтеграційне тестування, відмовостійке тестування тощо. Для максимального покриття під час планування тестів слід враховувати кожен з них.

Не варто також нехтувати оновленнями у світі IT. Тримайте руку на пульсі подій індустрії та сміливо залучайте нові підходи в тестуванні своїх продуктів. Комунікація в команді та шеринг досвідом також є важливим фактором. Переконайтесь, що вся команда на одній хвилі та має доступ до всіх необхідних ресурсів.

Врахування користувацьких потреб

Важливо не забувати, що тести повинні орієнтуватися на потреби користувачів. Наприклад, варто перевірити, чи відповідає інтерфейс програми очікуванням користувачів, чи задовольняє вимоги робота продукту на найпопулярніших платформах.

Не варто нехтувати спеціальними інструментами для відстежування поведінки користувачів, такими як, наприклад, Hotjar. За допомогою цього сервісу ви можете знайти як точки інтересу юзерів, так і блокери.

Постійне вдосконалення тестування

Процес тестування повинен постійно вдосконалюватися на основі отриманих результатів. Наприклад, аналіз результатів попередніх тестів для покращення стратегії тестування у майбутньому, інтеграція та взаємодія з новими технологіями.

Висновок

Отже, з мого досвіду — ці правила є основними під час тестування програмного забезпечення. Вони допомагають забезпечити якість, стабільність та задоволеність користувачів, що є важливими аспектами успішного релізу та підтримки програмного забезпечення. А які принципи тестування ви вважаєте ключовими? Буду рада почитати та обговорити ваші думки з цього приводу!

Рецензент статті — Геннадій Міщевський.