Функціональне тестування

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Вступ

1.1. Мета

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

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

1.2. Завдання

Основними завданнями функціонального тестування є:

Перевірка вимог

Функціональне тестування допомагає підтвердити, що програма відповідає задокументованим вимогам і технічним характеристикам. Виконання тестових сценаріїв на основі цих вимог гарантує, що програма відповідає запланованим цілям.

Виявлення дефектів

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

Забезпечення зручності користування

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

Регресійне тестування

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

Підтвердження бізнес-логіки

Багато програмних додатків побудовані на складних бізнес-правилах і логіці. Функціональне тестування переконується, що реалізовані правила є точними і виконують заплановані завдання.

Перевірка інтеграції

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

Відповідність і стандартизація

У деяких галузях програмне забезпечення повинно відповідати конкретним вимогам або стандартам. Функціональне тестування перевіряє, чи програма відповідає цим вимогам.

Підвищення якості продукту

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

Мінімізація ризиків

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

Задоволення клієнтів

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

1.3. Обсяг функціонального тестування

Обсяг функціонального тестування охоплює всі компоненти Платформи та реєстру в рамках Платформи реєстрів.

2. Підхід до функціонального тестування

2.1. Методології функціонального тестування

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

Ось список використовуваних методологій функціонального тестування:

Модульне тестування (Unit testing)

Модульне тестування (Unit testing) передбачає ізоляцію окремих компонентів, функцій або модулів. Кожен окремий компонент проходить через незалежне тестування, щоб гарантувати його точність і функціональність. Основною метою модульного тестування є підтвердити, що кожен блок коду працює так, як задумано. Воно допомагає виявляти дефекти на ранньому етапі циклу розробки і гарантує, що менші компоненти працюють правильно ще до їх інтеграції в більшу систему. Тестування модулів, як правило, автоматизовані і спрямовані на конкретні сценарії введення-виведення. Розробники пишуть юніт-тести в якості частини процесу розробки для забезпечення надійності та обслуговуваності коду.

Інтеграційне тестування

Інтеграційне тестування перевіряє взаємодії і інтерфейси між різними компонентами або модулями. Воно переконується, що інтегровані компоненти співпрацюють так, як очікувалося. Метою інтеграційного тестування є виявлення помилок, пов’язаних із обміном даними, зв’язком і співпрацею між компонентами. Воно допомагає виявити проблеми, що виникають під час інтеграції окремих одиниць. Існують різні стратегії для проведення інтеграційного тестування, такі як згори донизу (top-dow), знизу догори (bottom up), та "сендвіч" підхід. Тестувальники можуть використовувати заміни або моки (mocks) для моделювання поведінки залежних компонентів, які ще не доступні.

Системне тестування

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

Приймальне тестування (тестування при здачі)

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

  • Тестування на прийняття користувачем (UAT): Тестування на прийняття користувачем проводиться щорічно за участю представника клієнта. На цьому етапі тестування ми підготовлюємо тестові випадки, визначаємо регуляторні правила реєстру і проводимо тестування на реєстрі. Представник клієнта проходить кожен тестовий випадок, вказуючи на успіх чи невдачу кожного сценарію.

  • Альфа/бета-тестування: Альфа/бета-тестування проводиться з кожним релізом ітерації реєстру розробки за допомогою підготовлених ними тестових випадків.

Регресійне тестування

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

Тестування встановлення/оновлення

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

Візуальне тестування

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

2.2. Опис методологій тестування

2.2.1. Приймальне тестування

2.2.1.1. Тестування UAT (Тестування на прийняття користувачем)

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

  • Координація та створення сценаріїв прийняття разом з представниками клієнта.

  • Створення необхідної інфраструктури для тестування.

  • Пошук або створення необхідних тестових даних.

  • Пряме виконання сценаріїв прийняття та узгодження їх результатів з представниками клієнта.

Тести, які виконуються на цьому етапі, вимагають підтвердження успішного завершення - наявності знімків, журналів та докладних кроків для відтворення.

2.2.1.2. Альфа/Бета тестування

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

Бета-тестування відбувається після альфа-тестування і передбачає випуск програмного забезпечення в обмежену групу зовнішніх користувачів або клієнтів. Метою є отримання зворотного зв’язку з реального світу, виявлення проблем з використанням та ідентифікація будь-яких залишкових помилок чи проблем з продуктивністю. Цей етап тестування допомагає вдосконалити програмне забезпечення на основі відгуків користувачів перед його офіційним випуском, забезпечуючи більш вдосконалений та більш дружній до користувачів продукт.

Розробники реєстру відповідають за альфа/бета-тестування і діють на цьому етапі під час процесу релізу.

2.2.2. Тестування інтеграції

Цей метод тестування використовує такий підхід:

  • Створення сценаріїв тестування для перерахованих інтеграцій та підготовка тестових даних.

  • Розробка автоматизованого рішення для тестування інтегрованих даних та формування тестових груп, якщо це можливо.

  • Регулярне виконання ручних тестів, що входять до набору для регресії, і їх оновлення. Вони повинні бути додані до відповідних тестових груп у репозиторії Git і визначений мовою Gherkin.

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

Артефакти, отримані в результаті такого тестування:

  • Автоматизовані тести, додані до відповідних тестових груп (щоденні запуски, інтеграція і т. д.).

  • Ручні тести, додані до відповідних тестових груп (регресія, інтеграція і т. д.).

  • Оновлені матриці покриття вимог тестами та автоматизованими тестами.

  • Результати запусків тестів повинні бути структурованими та доступними всім зацікавленим сторонам:

    • Звіти про автоматизовані запуски тестів на Jenkins.

    • Звіти про ручні запуски тестів у репозиторії Git, описаному за допомогою мови Gherkin.

  • Сформульовані підтвердження виконання тестів — знімки екрану (снепшоти), додатки та журнали.

2.2.3. Регресійне тестування

Цей метод тестування використовує такий підхід:

  • Розробка автоматизованого рішення для управління цілями тестування.

  • Автоматизовані рішення розробляються на основі рівнів доступу:

    • Бекенд — цей рівень включає прямий доступ до договорів та їх взаємодій під час тестування.

    • UI — цей рівень передбачає створення автоматизованих рішень для перевірки функціональності користувацького інтерфейсу Платформи.

  • Автоматизоване тестування включає такі методи:

    • Функціональне тестування

    • Тестування встановлення

    • Інтеграційне тестування

  • Розроблені автоматизовані тести додаються до відповідних контрольних точок якості (quality gates).

  • Розроблені автоматизовані тести посилаються на вимоги, які вони перевіряють.

  • Кількість тестів повинна рівномірно розподілятися між рівнями тестування, утворюючи збалансовану тестову піраміду.

  • До процесу CI/CD інтегруються кілька рівнів контрольних точок якості.

  • Тестові дані включають синтетичні дані, які схожі на промислові дані або вибірку реальних промислових даних (якщо доступні).

  • Для забезпечення стабільності автоматизованого рішення використовуються інструменти для віртуалізації.

Артефакти цього тестування включають в себе:

  • Документований дизайн автоматизованого рішення.

  • Розроблені конвенції і керівні принципи для розробників автоматизованих тестів.

  • Встановлені принципи та правила проведення рецензій коду.

  • Опис рівнів якості та категорій тестів.

2.2.4. Тестування встановлення/оновлення

Ця функціональність передбачає лише ручне тестування; ми додаємо її до набору тестів для регресії. Оскільки тестування вимагає багато ресурсів і потребує окремого середовища, ми узгодимо з командою інфраструктури, коли воно буде виконуватися за потреби.

Артефакти цього тестування включають в себе:

  • Ручні тести, додані до відповідних тестових груп (регресія, інтеграція і т. д.).

  • Результати запусків тестів повинні бути структурованими та доступними всім зацікавленим сторонам.

2.2.5. Візуальне тестування

Цей метод тестування використовує такий підхід:

  • Розробка автоматизованого рішення для управління цілями тестування.

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

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

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

Артефакти цього тестування включають в себе:

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

2.2.6. Модульне тестування

Цей метод тестування використовує такий підхід:

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

  • Кожен модульний тест є незалежним і не повинен покладатися на порядок виконання інших тестів. Цей підхід дозволяє паралельне виконання тестів і точне виявлення невдач.

  • Модульні тести виявляють дефекти і проблеми на ранніх етапах розробки, що зменшує вартість і зусилля для виправлення помилок на пізніших стадіях.

Артефакти цього тестування включають в себе:

  • Пройдений конвеєр рецензування коду, який підтверджує покриття коду на рівні 80% за допомогою Sonar

  • Згенеровані звіти з покриття коду.

2.3. Ворота якості (Quality gates)

Всі описані типи тестування складають ворота якості. Ми структуруємо процес CI/CD (неперервної інтеграції / неперервної доставки) на кілька етапів:

Стадійний кластер (Stage cluster)

Ми впроваджуємо нову розроблену функціональність на кластер етапу та виконуємо початкове тестування:

  • Модульні тести

  • Перевірка покриття модульних тестів за допомогою Sonar

  • Інтеграційні тести

  • Візуальні тести

Кластер встановлення (Install cluster)

Ми розгортаємо зібрану платформу на окремому кластері і виконуємо тестування встановлення з подальших етапів:

  • Регресійні тести

  • Інтеграційні тести

  • Системні тести

  • Візуальні тести

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

Оновлення кластеру

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

  • Регресійні тести

  • Інтеграційні тести

  • Системні тести

  • Візуальні тести

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

Кластер передпродукції (Pre-production cluster)

Після підтвердження можливості платформи для оновлень і встановлення ми встановлюємо оновлення на кластер передпродукції, і тестування включає в себе:

  • Виконання ручних тестів на прийняття користувачем (UAT)

  • Альфа/бета-тести з командами розробників реєстру

Кластер продукції (Production cluster)

Після року розробки ми проводимо наступне тестування в середовищі продукції:

  • Виконання ручного тестування на прийняття користувачем (UAT) разом з представниками клієнта.

enable-mocking-flow

2.4. Використовувані інструменти та технології

Під час функціонального тестування використовуються наступні типи, інструменти та технології:

Тип функціонального тестування Інструменти Статус

Модульне тестування

JUnit, Mockito

Автоматизоване

Інтеграційне тестування

JUnit, AssertJ, RestAssured

Автоматизоване

Системне тестування

JUnit, Selenide, RestAssured

Автоматизоване

Візуальне тестування

Selenide, Moon

Автоматизоване

Приймальне тестування

JUnit, Selenide

Автоматизоване /Ручне

Регресійне тестування

JUnit, Selenide, Moon, RestAssured

Автоматизоване

3. Управління дефектами

3.1. Реєстрація та обробка дефектів

Ми категоризуємо новознайдені дефекти за трьома групами в залежності від їх походження:

  • Дефекти виробництва (Production defects)

  • Дефекти регресії (Regression defects)

  • Функціональні дефекти (Functional defects)

3.1.1. Дефекти виробництва (Production defects)

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

Дефекти, виявлені виробничим середовищем, повинні бути пов’язані з епіком обробки дефектів, пов’язаної з виробничим середовищем. Вони повинні мати мітки, такі як JSM компетенції: DevOps, Backend, Frontend і т. д., і включати посилання на опис дефекту, який був повідомлений користувачем. Для дефектів, повідомлених користувачами, слід надати посилання на відповідний дефект Jira.

3.1.2. Дефекти регресії (Regression defects)

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

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

3.1.3. Функціональні дефекти (Functional defects)

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

Ми посилаємо будь-які виявлені дефекти під час тестування нової функціональності на відповідну користувацьку історію, де ми їх виявили.

3.2. Обробка дефектів

Обробка дефектів виглядає так:

  • Ми визначаємо пріоритети всіх дефектів відповідно до умов, викладених у розділі Пріоритезація дефектів та переглядаємо їх у розділі Визначення важливості дефектів.

  • Дефект, який було усунено, позначається як Готовий для тестування і пересилається до реєстратора дефектів. Якщо реєстратор дефектів представляє клієнта, ми пересилаємо його до керівника команди тестування.

  • Реєстратор дефектів переглядає дефект і, якщо його було усунено, позначає його як закритий на валідному рівні якості. Якщо дефект відтворюється знову, він повертається до розробки зі статусом Переробка.

3.3. Визначення пріоритетів дефектів

Враховуйте наступні критерії (які не включені в таблицю) для визначення серйозності дефектів та їх впливу на подальший розвиток:

Рівень пріоритету Опис Вплив на тестування

0: Blocker (Блокер)

Платформа припиняє свою роботу, і немає обхідного шляху.

Команда тестування повертає збірку розробникам.

1: Critical (Критичний)

Функціональність не працює.

Команда тестування надає звіт з тестування розробникам і керівництву. Керівництво вирішує питання про подальші дії (переробку, гарячий виправлення).

2: Major (Важливий)

Порушені критичні бізнес-вимоги.

Присутність дефектів із пріоритетом 2 вимагає додаткової узгодженості з бізнес-командою і управлінням проекту.

3: Minor (Мінорний)

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

Бізнес і розробницькі команди узгоджують необхідність вирішення дефекту в поточному релізі.

4: Trivial (Дрібний)

Потрібні незначні зміни в функціональності — естетичні або косметичні зміни.

Бізнес і розробницькі команди узгоджують необхідність вирішення дефекту в поточному релізі.

3.4. Визначення важливості дефекту

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

Лідер команди тестування та реєстратор дефектів відповідають за закриття дефектів.

Статус Пояснення Чи буде вирішено?

Не дефект: Дефект, який на даний момент не може бути відтворений

Дефект на даний момент не може бути відтворений

Ні

Не дефект: Дублікат

Дефект вже залоговано

Ні

Виконано

Тестування проведено ретельно, і функціональність працює

Так

Переробка

Тестування було проведено ретельно, і функціональність не працює після виправлення

Ні

Не буде виправлено

Дефект має мінімальний вплив на бізнес і не буде виправлено

Ні

Виправлено

Після внесення змін було проведено ретельний процес тестування.

Так

Застарілий

Дефект застарів

Ні

Скасовано

Скасована функціональність

Ні

Реалізовано

Технічна помилка, яка не потребує тестування

Так

Відкладено

Чекає вирішення в майбутніх випусках і запланованій функціональності

Так

Не дефект

Не є дефектом

Ні

4. Звітність

Звіти з тестування включають два типи:

  • Звіт з автоматизації ReportPortal, який може бути наданий зацікавленим сторонам.

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