From 34fa405fe5f72cc57099112605688c542929d221 Mon Sep 17 00:00:00 2001
From: Olha_Kotselko <olha_kotselko@epam.com>
Date: Thu, 14 Sep 2023 19:02:56 +0300
Subject: [PATCH] [EDP-DDM-28546] The functional-testing doc

Change-Id: Ibc87574b4de1a41c3d0f37d50dfd7fdd750f378c
---
 .../functional-testing.adoc                   |  21 +-
 .../functionalTesting/quality-gates.puml      |  44 ++
 .../functional-testing.adoc                   | 671 +++++++++++++++++-
 3 files changed, 699 insertions(+), 37 deletions(-)
 create mode 100644 docs/ua/modules/testing/images/functionalTesting/quality-gates.puml

diff --git a/docs/en/modules/testing/pages/functional-testing/functional-testing.adoc b/docs/en/modules/testing/pages/functional-testing/functional-testing.adoc
index f86ec03882..8362d1ffb1 100644
--- a/docs/en/modules/testing/pages/functional-testing/functional-testing.adoc
+++ b/docs/en/modules/testing/pages/functional-testing/functional-testing.adoc
@@ -1,22 +1,7 @@
-:toc-title: On this page:
-:toc: auto
-:toclevels: 5
-:experimental:
-:important-caption:     ВАЖЛИВО
-:note-caption:          ПРИМІТКА
-:tip-caption:           РЕСУРС
-:warning-caption:       ПОПЕРЕДЖЕННЯ
-:caution-caption:       УВАГА
-:example-caption:           Приклад
-:figure-caption:            Зображення
-:table-caption:             Таблиця
-:appendix-caption:          Додаток
-:sectnums:
-:sectnumlevels: 5
-:sectanchors:
-:sectlinks:
-
 = Functional testing
+include::platform:ROOT:partial$templates/document-attributes/default-set-en.adoc[]
+
+include::platform:ROOT:partial$admonitions/language-en.adoc[]
 
 == Introduction
 
diff --git a/docs/ua/modules/testing/images/functionalTesting/quality-gates.puml b/docs/ua/modules/testing/images/functionalTesting/quality-gates.puml
new file mode 100644
index 0000000000..d7fb2084a5
--- /dev/null
+++ b/docs/ua/modules/testing/images/functionalTesting/quality-gates.puml
@@ -0,0 +1,44 @@
+@startuml
+actor Тестувальник
+
+participant "Кластер стейджингу" as Stage
+participant "Встановити кластер" as Install
+participant "Оновити кластер" as Update
+participant "Пре-продакшен кластер" as PreProd
+participant "Продакшен кластер" as Prod
+
+Tester -> Stage: Виконати модульне тестування
+Tester -> Stage: Виконати інтеграційне тестування
+Tester -> Stage: Виконати візуальне тестування
+Tester -> Stage:  Виконати аналіз Sonar
+
+activate Stage
+Stage -> Install: Виконати регресійне тестування
+Stage -> Install: Виконати інтеграційне тестування
+Stage -> Install: Виконати системне тестування
+Stage -> Install: Виконати візуальне тестування
+Stage -> Install: Встановити ручне тестування
+
+activate Install
+Install -> Update: Виконати регресійне тестування
+Install -> Update: Виконати інтеграційне тестування
+Install -> Update: Виконати системне тестування
+Install -> Update: Виконати візуальне тестування
+Install -> Update: Оновити ручне тестування
+
+activate Update
+Update -> PreProd: Виконати тестування на прийняття
+
+activate PreProd
+PreProd -> Prod: Виконати тестування на прийняття
+
+activate Prod
+Prod -> Prod: Провести тести на прийомку з представником клієнта
+
+deactivate Стейджинг
+deactivate Встановлення
+deactivate Оновлення
+deactivate ПреПродакшен
+deactivate Продавшен
+
+@enduml
diff --git a/docs/ua/modules/testing/pages/functional-testing/functional-testing.adoc b/docs/ua/modules/testing/pages/functional-testing/functional-testing.adoc
index c67e0a0ed8..f242a4813a 100644
--- a/docs/ua/modules/testing/pages/functional-testing/functional-testing.adoc
+++ b/docs/ua/modules/testing/pages/functional-testing/functional-testing.adoc
@@ -1,21 +1,654 @@
-:toc-title: On this page:
-:toc: auto
-:toclevels: 5
-:experimental:
-:important-caption:     ВАЖЛИВО
-:note-caption:          ПРИМІТКА
-:tip-caption:           РЕСУРС
-:warning-caption:       ПОПЕРЕДЖЕННЯ
-:caution-caption:       УВАГА
-:example-caption:           Приклад
-:figure-caption:            Зображення
-:table-caption:             Таблиця
-:appendix-caption:          Додаток
-:sectnums:
-:sectnumlevels: 5
-:sectanchors:
-:sectlinks:
-
+//= Functional testing
 = Функціональне тестування
+include::platform:ROOT:partial$templates/document-attributes/default-set-ua.adoc[]
+
+include::platform:ROOT:partial$admonitions/language-ua.adoc[]
+
+//== Introduction
+== Вступ
+
+//=== Purpose
+=== Мета
+
+//Functional testing is a crucial aspect of the software development lifecycle that verifies whether a software application's functions or features work as intended and meet the specified requirements.
+Функціональне тестування є критичним аспектом життєвого циклу розробки програмного забезпечення, що перевіряє, чи працюють функції та можливості програмного забезпечення так, як було задумано, і чи відповідають ці функції встановленим вимогам.
+
+//The primary goal of functional testing is to ensure that the software behaves correctly according to the defined specifications and user expectations. It helps identify defects and discrepancies in the software's behavior, ensuring it delivers the intended value to users.
+Основною метою функціонального тестування є переконатися, що програма поводить себе відповідно до визначених специфікацій та очікувань користувача. Воно допомагає виявити дефекти і розходження в роботі програми, гарантуючи, що вона надає користувачам заплановану цінність.
+
+//=== Objectives
+=== Завдання
+
+//The *main objectives of functional testing* are:
+*Основними завданнями функціонального тестування є*:
+
+//Validating requirements::
+Перевірка вимог::
+//Functional testing helps verify the software application meets the documented requirements and specifications.
+//Executing test scenarios based on these requirements ensures the software meets the intended objectives.
+Функціональне тестування допомагає підтвердити, що програма відповідає задокументованим вимогам і технічним характеристикам. Виконання тестових сценаріїв на основі цих вимог гарантує, що програма відповідає запланованим цілям.
+
+//Detecting defects::
+Виявлення дефектів::
+//Functional testing aims to identify software defects, bugs, and errors. By systematically testing various functions and features, QA teams can uncover issues that might negatively impact the user experience or hinder the application's functionality.
+Функціональне тестування спрямоване на виявлення дефектів, помилок і вад програми. Систематичне тестування різних функцій і можливостей допомагає виявити проблеми, які можуть негативно вплинути на досвід користувача або ж обмежити функціональність додатка.
+
+//Assuring User Experience::
+Забезпечення зручності користування::
+//Functional testing ensures the software provides a seamless and user-friendly experience.
+//It validates that end-users can interact with the application without encountering unexpected errors or incorrect behavior.
+Функціональне тестування гарантує, що програма надає безперебійний і зручний для користувача досвід. Воно перевіряє, що кінцеві користувачі можуть взаємодіяти з додатком без неочікуваних помилок чи неправильної поведінки.
+
+//Regression testing::
+Регресійне тестування::
+//Performing functional testing is crucial to prevent regression issues as software advances and new features are added.
+//It ensures that recent code changes do not break existing functionality, maintaining the application's overall stability.
+Проведення функціонального тестування є важливим для запобігання проблемам регресії, коли розробка програми продовжується і додаються нові функції. Воно гарантує, що останні зміни в коді не руйнують існуючу функціональність, забезпечуючи стабільність додатка в цілому.
+
+//Validating business logic::
+Підтвердження бізнес-логіки::
+//Many software applications rely on complex business rules and logic.
+//Functional testing ensures the implemented rules are accurate and generate the intended outcomes.
+Багато програмних додатків побудовані на складних бізнес-правилах і логіці. Функціональне тестування переконується, що реалізовані правила є точними і виконують заплановані завдання.
+
+//Verifying integration::
+Перевірка інтеграції::
+//Functional testing ensures that different software components and modules integrate correctly and collaborate as intended.
+//This method helps identify integration issues early in the development process.
+Функціональне тестування гарантує, що різні компоненти і модулі програмного забезпечення правильно інтегруються і співпрацюють так, як задумано. Цей підхід допомагає виявити проблеми інтеграції на ранніх етапах розробки.
+
+//Compliance and standardization::
+Відповідність і стандартизація::
+//In some industries, software must comply with specific regulations or standards. Functional testing verifies that the software adheres to these requirements.
+У деяких галузях програмне забезпечення повинно відповідати конкретним вимогам або стандартам. Функціональне тестування перевіряє, чи програма відповідає цим вимогам.
+
+//Enhancing product quality::
+Підвищення якості продукту::
+//By identifying and rectifying defects early in the development cycle, functional testing contributes to overall product quality improvement.
+//This results in a more reliable and robust software application.
+Завдяки виявленню і виправленню дефектів на ранніх етапах розробки функціональне тестування сприяє підвищенню загальної якості програмного продукту. Це забезпечує більшу надійність і стійкість програмного забезпечення.
+
+//Mitigating risks::
+Мінімізація ризиків::
+//Effective functional testing minimizes the risk of releasing a faulty or substandard product to end-users.
+//Identifying and resolving issues before deployment helps mitigate potential financial, reputation, and legal risks.
+Ефективне функціональне тестування допомагає зменшити ризик випуску на ринок програми з дефектами або низькою якістю. Виявлення і вирішення проблем перед розгортанням допомагають мінімізувати потенційні фінансові, репутаційні та юридичні ризики.
+
+//Customer Satisfaction::
+Задоволення клієнтів::
+//Ultimately, functional testing ensures the software meets user expectations and delivers value. By identifying and addressing available issues, it enhances customer satisfaction and loyalty.
+У кінцевому підсумку, функціональне тестування гарантує, що програмне забезпечення відповідає очікуванням користувачів і надає цінність. Шляхом виявлення та вирішення наявних проблем воно підвищує задоволення та лояльність клієнтів.
+
+//=== Functional testing scope
+=== Обсяг функціонального тестування
+
+//The scope of functional testing encompasses all the platform and registry components within the *Platform for state registries*.
+Обсяг функціонального тестування охоплює всі компоненти Платформи та реєстру в рамках *Платформи реєстрів*.
+
+//== Functional testing approach
+== Підхід до функціонального тестування
+//=== Functional testing methodologies
+=== Методології функціонального тестування
+
+//Functional testing follows a combination of manual and automated testing approaches.
+//It includes unit testing, integration testing, system testing, acceptance testing, regression testing, and functional testing best practices.
+Функціональне тестування використовує комбінацію ручних та автоматизованих методів тестування. До нього включають модульне тестування, інтеграційне тестування, системне тестування, тестування на прийняття, регресійне тестування та найкращі практики функціонального тестування.
+
+//Here is the list of used *functional testing methodologies*:
+Ось список використовуваних *методологій функціонального тестування*:
+
+//Unit testing::
+Модульне тестування (Unit testing)::
+//Unit testing involves isolating individual components, functions, or modules. Every unit undergoes independent testing to guarantee its accuracy and functionality. The primary goal of unit testing is to validate that each unit of code performs as intended. It helps identify defects early in the development cycle and ensures that smaller components work correctly before being integrated into the more extensive system. Unit tests are typically automated and focus on specific input-output scenarios. Developers write unit tests as part of the development process to ensure code reliability and maintainability.
+Модульне тестування (Unit testing) передбачає ізоляцію окремих компонентів, функцій або модулів. Кожен окремий компонент проходить через незалежне тестування, щоб гарантувати його точність і функціональність. Основною метою модульного тестування є підтвердити, що кожен блок коду працює так, як задумано. Воно допомагає виявляти дефекти на ранньому етапі циклу розробки і гарантує, що менші компоненти працюють правильно ще до їх інтеграції в більшу систему. Тестування модулів, як правило, автоматизовані і спрямовані на конкретні сценарії введення-виведення. Розробники пишуть юніт-тести в якості частини процесу розробки для забезпечення надійності та обслуговуваності коду.
+
+//Integration testing::
+Інтеграційне тестування::
+//Integration testing verifies the interactions and interfaces between different components or modules. It ensures that integrated components work together as expected. Integration testing aims to detect errors related to data exchange, communication, and collaboration between components. It helps identify issues that arise due to the integration of individual units. Different strategies for conducting integration testing exist, such as top-down, bottom-up, or sandwich approaches. Testers might use stubs or mocks to simulate the behavior of dependent components that are not yet available.
+Інтеграційне тестування перевіряє взаємодії і інтерфейси між різними компонентами або модулями. Воно переконується, що інтегровані компоненти співпрацюють так, як очікувалося. Метою інтеграційного тестування є виявлення помилок, пов'язаних із обміном даними, зв'язком і співпрацею між компонентами. Воно допомагає виявити проблеми, що виникають під час інтеграції окремих одиниць. Існують різні стратегії для проведення інтеграційного тестування, такі як згори донизу (top-dow), знизу догори (bottom up), та "сендвіч" підхід. Тестувальники можуть використовувати заміни або моки (mocks) для моделювання поведінки залежних компонентів, які ще не доступні.
+
+//System testing::
+Системне тестування::
+//System testing evaluates the entire software application as a complete and integrated entity. It involves testing the application's functionalities, interfaces, and interactions holistically. System testing aims to validate that the software meets the specified requirements and behaves as expected in different scenarios. It covers end-to-end scenarios and assesses the software's overall behavior. System testing often includes various tests, such as functional, performance, security, and usability testing. It focuses on user scenarios and real-world usage.
+Системне тестування оцінює весь програмний додаток як цілісний і інтегрований об'єкт. Воно включає в себе тестування функціональностей, інтерфейсів та взаємодій програми як цілого. Системне тестування має за мету підтвердити, що програмне забезпечення відповідає встановленим вимогам і веде себе відповідно до очікувань в різних сценаріях. Воно охоплює сценарії від початку до кінця та оцінює загальну поведінку програми. Системне тестування часто включає різні види тестів, такі як функціональне, продуктивність, безпека та тестування зручності використання. Воно акцентує на сценаріях користувача та реальному використанні.
+
+//Acceptance testing::
+Приймальне тестування (тестування при здачі)::
+//Acceptance testing evaluates whether the software meets the acceptance criteria defined by stakeholders and users.
+//It determines whether the software is ready for deployment. The purpose of acceptance testing is to ensure that the software aligns with user expectations and business requirements. It aims to verify that the software delivers value and meets the needs of its intended users.
+//It comprises two sections:
+Приймальне тестування оцінює, чи відповідає програмне забезпечення критеріям прийняття, визначеним зацікавленими сторонами та користувачами. Воно визначає, чи програмне забезпечення готове до впровадження. Метою приймального тестування є забезпечення відповідності програми очікуванням користувачів та бізнес-вимогам. Воно спрямоване на підтвердження того, що програмне забезпечення надає вартість і відповідає потребам його призначених користувачів. Воно включає дві секції:
++
+//* *_UAT Testing_* +
+* *Тестування на прийняття користувачем (UAT)*:
+//User Acceptance Testing (UAT) is conducted yearly with the customer representative. In this testing phase, we prepare test cases, define registry regulations, and conduct testing on the registry. The customer representative goes through each test case, indicating the success or failure of each scenario.
+Тестування на прийняття користувачем проводиться щорічно за участю представника клієнта. На цьому етапі тестування ми підготовлюємо тестові випадки, визначаємо регуляторні правила реєстру і проводимо тестування на реєстрі. Представник клієнта проходить кожен тестовий випадок, вказуючи на успіх чи невдачу кожного сценарію.
+//* *_Alpha/Beta Testing_* +
+* *Альфа/бета-тестування*:
+//Alpha/beta testing is performed with each release iteration by the registry development teams using the test cases they have prepared.
+Альфа/бета-тестування проводиться з кожним релізом ітерації реєстру розробки за допомогою підготовлених ними тестових випадків.
+
+//Regression testing::
+Регресійне тестування::
+//Regression testing ensures that a software application's recent code changes or enhancements do not negatively impact its existing functionality. It involves re-running a predefined set of test cases to validate that new code changes have not introduced unintended side effects or defects.
+Регресійне тестування гарантує, що останні зміни в коді або покращення в програмному додатку не матимуть негативного впливу на його поточну функціональність. Цей вид тестування включає в себе повторний запуск заздалегідь визначеної множини тестових випадків для перевірки того, що нові зміни в коді не призвели до непередбачених побічних ефектів або дефектів.
+
+//Installation/Update testing::
+Тестування встановлення/оновлення::
+//The purpose of installation/update testing is to ensure that the software can be installed, updated, configured, and uninstalled smoothly without any issues, mistakes, or harmful impacts on the targeted system. This type of testing is essential because even a well-developed software application can suffer from installation-related or update-related issues that might disrupt its functionality or cause conflicts with other software components.
+Метою тестування встановлення/оновлення є забезпечення того, що програмне забезпечення може бути встановлене, оновлене, налаштоване та видалене без будь-яких проблем, помилок або негативного впливу на цільову систему. Цей тип тестування є важливим, оскільки навіть добре розроблене програмне додаток може мати проблеми, пов'язані з встановленням чи оновленням, які можуть розривати його функціональність або спричиняти конфлікти з іншими компонентами програмного забезпечення.
+
+//Visual testing::
+Візуальне тестування::
+//Visual testing is a critical aspect of quality assurance that focuses on evaluating the visual appearance and layout of a software application or website. It ensures that the user interface elements, such as fonts, colors, images, and graphical components, are displayed correctly and consistently across various devices, browsers, and resolutions. Visual testing utilizes automated tools to capture screenshots of the application's different states and then compares these images to a set of baseline images representing the expected appearance. This process helps identify discrepancies, visual regressions, or layout issues, ensuring a visually appealing and consistent user experience.
+Візуальне тестування є важливою частиною забезпечення якості, яка спрямована на оцінку візуального вигляду і розташування програмного додатка або веб-сайту. Воно забезпечує, що елементи користувацького інтерфейсу, такі як шрифти, кольори, зображення і графічні компоненти, відображаються правильно і послідовно на різних пристроях, веб-браузерах і роздільних здатностях. Візуальне тестування використовує автоматизовані інструменти для збереження відображень різних станів додатку, а потім порівнює ці зображення з набором базових зображень, що представляють очікуваний вигляд. Цей процес допомагає виявляти розходження, візуальні регресії чи проблеми з розташуванням, забезпечуючи візуально привабливий і послідовний досвід користувача.
+
+//TODO: HERE
+//=== Testing approaches description
+=== Опис методологій тестування
+
+//==== Acceptance Testing
+==== Приймальне тестування
+
+//===== UAT Testing
+===== Тестування UAT (Тестування на прийняття користувачем)
+
+//This testing method involves verifying a build that is a potential candidate for further deployment to the production environment.
+//Act once per year with a customer representative. *It includes the following procedures*:
+Цей метод тестування передбачає перевірку збірки, яка є потенційним кандидатом для подальшого впровадження в середовище продукції. Виконується один раз на рік за участю представника клієнта. Він включає в себе наступні процедури:
+
+//* Coordination and creation of acceptance scenarios with client representatives.
+//* Establishment of the necessary testing infrastructure.
+//* Search or creation of required test data.
+//* Direct execution of acceptance scenarios and agreement of their results with client representatives.
+* Координація та створення сценаріїв прийняття разом з представниками клієнта.
+* Створення необхідної інфраструктури для тестування.
+* Пошук або створення необхідних тестових даних.
+* Пряме виконання сценаріїв прийняття та узгодження їх результатів з представниками клієнта.
+
+//The tests performed during this phase require confirmation of successful completion -- the presence of snapshots, logs, and detailed reproduction steps.
+Тести, які виконуються на цьому етапі, вимагають підтвердження успішного завершення - наявності знімків, журналів та докладних кроків для відтворення.
+
+//===== Alpha/Beta Testing
+===== Альфа/Бета тестування
+
+//Alpha testing involves testing a pre-release software version within the development environment. Internal testers, developers, or quality assurance teams perform this task. The goal is to identify bugs, assess system stability, and ensure basic functionalities work as intended before external testing.
+Альфа-тестування передбачає тестування версії програмного забезпечення перед його релізом в середовищі розробки. Цю роботу виконують внутрішні тестувальники, розробники або команди з контролю якості. Метою є виявлення помилок, оцінка стабільності системи та перевірка того, що основні функції працюють так, як задумано, перед зовнішнім тестуванням.
+
+//Beta testing occurs after alpha testing and involves releasing the software to a select group of external users or customers. The aim is to gather real-world feedback, uncover usability issues, and identify any remaining bugs or performance problems. This testing phase helps refine the software based on user input before its official release, ensuring a more polished and user-friendly product.
+Бета-тестування відбувається після альфа-тестування і передбачає випуск програмного забезпечення в обмежену групу зовнішніх користувачів або клієнтів. Метою є отримання зворотного зв'язку з реального світу, виявлення проблем з використанням та ідентифікація будь-яких залишкових помилок чи проблем з продуктивністю. Цей етап тестування допомагає вдосконалити програмне забезпечення на основі відгуків користувачів перед його офіційним випуском, забезпечуючи більш вдосконалений та більш дружній до користувачів продукт.
+
+//Registry development teams are responsible for alpha/beta testing and act on it during the release process.
+Розробники реєстру відповідають за альфа/бета-тестування і діють на цьому етапі під час процесу релізу.
+
+//==== Integration Testing
+==== Тестування інтеграції
+
+//This testing method follows the following approach:
+Цей метод тестування використовує такий підхід:
+
+//* Designing testing scenarios for the listed integrations and preparing test data.
+//* Developing an automated solution for testing integration data and forming test groups if such a solution is feasible.
+//* Manual tests that form the regression suite should be executed regularly and updated. They should be added to the appropriate test groups in the git repository defined by the Gherkin language.
+* Створення сценаріїв тестування для перерахованих інтеграцій та підготовка тестових даних.
+* Розробка автоматизованого рішення для тестування інтегрованих даних та формування тестових груп, якщо це можливо.
+* Регулярне виконання ручних тестів, що входять до набору для регресії, і їх оновлення. Вони повинні бути додані до відповідних тестових груп у репозиторії Git і визначений мовою Gherkin.
+
+//Such tests involve testing integrations with real instances of external test systems and require confirmation of successful execution -- the presence of snapshots, logs, and detailed reproduction steps.
+Такі тести включають в себе тестування інтеграцій з реальними екземплярами зовнішніх тестових систем і вимагають підтвердження успішного виконання -- наявність знімків (снепшшотів), журналів та докладних кроків для відтворення.
+
+//Artifacts resulting from this type of testing:
+Артефакти, отримані в результаті такого тестування:
+
+//* Automated tests added to relevant test groups (nightly runs, integration, etc.)
+//* Manual tests added to relevant test groups (regression, integration, etc.).
+//* Updated requirement coverage matrices for tests and automated tests.
+//* Results of test runs should be well-structured and accessible to all stakeholders:
+* Автоматизовані тести, додані до відповідних тестових груп (щоденні запуски, інтеграція і т. д.).
+* Ручні тести, додані до відповідних тестових груп (регресія, інтеграція і т. д.).
+* Оновлені матриці покриття вимог тестами та автоматизованими тестами.
+* Результати запусків тестів повинні бути структурованими та доступними всім зацікавленим сторонам:
+//** Reports of automated test runs on Jenkins.
+//** Reports of manual test runs in the git repository described on Gherkin.
+** Звіти про автоматизовані запуски тестів на Jenkins.
+** Звіти про ручні запуски тестів у репозиторії Git, описаному за допомогою мови Gherkin.
+//* Formulated evidence of test execution -- snapshots, attachments, and logs.
+* Сформульовані підтвердження виконання тестів -- знімки екрану (снепшоти), додатки та журнали.
+
+//==== Regression Testing
+==== Регресійне тестування
+
+//This testing method follows the following approach:
+Цей метод тестування використовує такий підхід:
+
+//* Develop an automated solution for test goal management.
+* Розробка автоматизованого рішення для управління цілями тестування.
++
+//* Automated solutions are designed based on their access levels:
+//** *Backend* -- This level involves direct access to contracts and their interactions during testing.
+//**  *UI* -- This level involves building automated solutions for testing platform UI functionality.
+* Автоматизовані рішення розробляються на основі рівнів доступу:
+** Бекенд -- цей рівень включає прямий доступ до договорів та їх взаємодій під час тестування.
+** UI -- цей рівень передбачає створення автоматизованих рішень для перевірки функціональності користувацького інтерфейсу Платформи.
++
+//* Automated testing encompasses the following methods:
+//** *Functional testing*
+//** *Installation testing*
+//** *Integration testing*
+* Автоматизоване тестування включає такі методи:
+** Функціональне тестування
+** Тестування встановлення
+** Інтеграційне тестування
+
+//* Developed automated tests are added to corresponding quality gates.
+//* Developed automated tests reference the requirements they verify.
+//* The number of tests should be evenly distributed across testing levels, forming a balanced testing pyramid.
+//* Several levels of quality gates are integrated into the CI/CD process.
+//* Test data comprises synthetic data resembling industrial data or a sample of real industrial data (if accessible).
+//* To ensure the stability of the automated solution, virtualization tools are utilized.
+* Розроблені автоматизовані тести додаються до відповідних контрольних точок якості (quality gates).
+* Розроблені автоматизовані тести посилаються на вимоги, які вони перевіряють.
+* Кількість тестів повинна рівномірно розподілятися між рівнями тестування, утворюючи збалансовану тестову піраміду.
+* До процесу CI/CD інтегруються кілька рівнів контрольних точок якості.
+* Тестові дані включають синтетичні дані, які схожі на промислові дані або вибірку реальних промислових даних (якщо доступні).
+* Для забезпечення стабільності автоматизованого рішення використовуються інструменти для віртуалізації.
+
+//Artifacts of this testing include:
+Артефакти цього тестування включають в себе:
+
+//* Documented design of the automated solution.
+//* Developed code conventions and guidelines for automated test developers.
+//* Established principles and rules for conducting code reviews.
+//* Description of quality gate levels and test categories.
+* Документований дизайн автоматизованого рішення.
+* Розроблені конвенції і керівні принципи для розробників автоматизованих тестів.
+* Встановлені принципи та правила проведення рецензій коду.
+* Опис рівнів якості та категорій тестів.
+
+//==== Installation/Update Testing
+==== Тестування встановлення/оновлення
+
+//This functionality involves only manual testing; we add it to the regression test suite. Since testing is resource-intensive and requires a separate environment, together with the infrastructure team, we will agree on when to execute it as needed.
+Ця функціональність передбачає лише ручне тестування; ми додаємо її до набору тестів для регресії. Оскільки тестування вимагає багато ресурсів і потребує окремого середовища, ми узгодимо з командою інфраструктури, коли воно буде виконуватися за потреби.
+
+//Artifacts of this testing include:
+Артефакти цього тестування включають в себе:
+
+//* Manual tests added to relevant test groups (Regression, Integration, etc.).
+//* Results of test runs should be well-structured and accessible to all stakeholders.
+* Ручні тести, додані до відповідних тестових груп (регресія, інтеграція і т. д.).
+* Результати запусків тестів повинні бути структурованими та доступними всім зацікавленим сторонам.
+
+//==== Visual Testing
+==== Візуальне тестування
+
+//This testing method follows the following approach:
+Цей метод тестування використовує такий підхід:
+
+//* Develop an automated solution for test goal management.
+//* Automated solution captures screenshots of the application under different scenarios and compares them to baseline images, highlighting any discrepancies.
+//* Visual testing checks how the UI adapts to different screen sizes to ensure a seamless device experience.
+//* It confirms the match between the visual representation and the expected design and layout, introducing no visual regressions or inconsistencies.
+* Розробка автоматизованого рішення для управління цілями тестування.
+* Автоматизоване рішення захоплює знімки екрану програми в різних сценаріях та порівнює їх з базовими зображеннями, визначаючи будь-які розбіжності.
+* Візуальне тестування перевіряє, як користувацький інтерфейс пристосовується до різних розмірів екрану, щоб забезпечити безперервний досвід користувача на різних пристроях.
+* Це підтверджує відповідність між візуальним представленням і очікуваним дизайном та розташуванням, не вносячи візуальних регресій чи непослідовностей.
+
+//Artifacts of this testing include:
+Артефакти цього тестування включають в себе:
+
+//* Reports highlight differences between captured screenshots and baseline images, making identifying visual defects or regressions easy.
+* Звіти, які вказують на відмінності між захопленими знімками екрану та базовими зображеннями, що полегшує виявлення візуальних дефектів чи регресій.
+
+//==== Unit Testing
+==== Модульне тестування
+
+//This testing method follows the following approach:
+Цей метод тестування використовує такий підхід:
+
+//* Unit tests isolate a specific code unit, such as a function or method, from the rest of the application. This isolation ensures that the test results are not affected by external dependencies.
+* Модульні тести ізолюють конкретний кодовий модуль, такий як функцію чи метод, від інших частин додатку. Ця ізоляція гарантує, що результати тестування не будуть впливати на зовнішні залежності.
+//* Each unit test is independent and should not rely on the execution order of other tests. This approach allows for parallel execution and accurate identification of failures.
+* Кожен модульний тест є незалежним і не повинен покладатися на порядок виконання інших тестів. Цей підхід дозволяє паралельне виконання тестів і точне виявлення невдач.
+//* Unit tests detect defects and issues early in the development process, reducing the cost and effort of fixing bugs in later stages.
+* Модульні тести виявляють дефекти і проблеми на ранніх етапах розробки, що зменшує вартість і зусилля для виправлення помилок на пізніших стадіях.
+
+//Artifacts of this testing include:
+Артефакти цього тестування включають в себе:
+
+//* Passed code review pipeline that validates by sonar 80% coverage
+//* Generated code coverage reports.
+* Пройдений конвеєр рецензування коду, який підтверджує покриття коду на рівні 80% за допомогою Sonar
+* Згенеровані звіти з покриття коду.
+
+//=== Quality gates
+=== Ворота якості (Quality gates)
+
+//All types of described testing make up the *_quality gates_*. We structure the CI/CD process into several stages:
+Всі описані типи тестування складають ворота якості. Ми структуруємо процес CI/CD (неперервної інтеграції / неперервної доставки) на кілька етапів:
+
+//Stage cluster::
+Стадійний кластер (Stage cluster)::
+//We deploy the newly developed functionality to the stage cluster and perform initial testing:
+Ми впроваджуємо нову розроблену функціональність на кластер етапу та виконуємо початкове тестування:
+
+//* Unit tests
+//* Sonar unit test coverage check
+//* Integration tests
+//* Visual tests
+* Модульні тести
+* Перевірка покриття модульних тестів за допомогою Sonar
+* Інтеграційні тести
+* Візуальні тести
+
+//Install cluster::
+Кластер встановлення (Install cluster)::
+//We deploy the compiled platform to a separate cluster and carry out installation testing from the subsequent stages:
+Ми розгортаємо зібрану платформу на окремому кластері і виконуємо тестування встановлення з подальших етапів:
+
+//* Regression tests
+//* Integration tests
+//* System tests
+//* Visual tests
+//* Manual installation test cases execution
+* Регресійні тести
+* Інтеграційні тести
+* Системні тести
+* Візуальні тести
+* Виконання ручних тестових випробувань встановлення
+
+//Update cluster::
+Оновлення кластеру::
+//After validating the installation, we deploy a new cluster to check platform updates from the previous version to the new one, and this includes testing the updates through the subsequent stages:
+Після перевірки встановлення ми розгортаємо новий кластер, щоб перевірити оновлення платформи з попередньої версії на нову, і це включає тестування оновлень через наступні етапи:
+
+//* Regression tests
+//* Integration tests
+//* System tests
+//* Visual tests
+//* Manual update test case execution
+* Регресійні тести
+* Інтеграційні тести
+* Системні тести
+* Візуальні тести
+* Виконання ручних тестових випробувань оновлення
+
+//Pre-production cluster::
+Кластер передпродукції (Pre-production cluster)::
+//Once we confirm the platform's ability for updates and installations, we install the update on the pre-production cluster, and the testing includes:
+Після підтвердження можливості платформи для оновлень і встановлення ми встановлюємо оновлення на кластер передпродукції, і тестування включає в себе:
+
+//* Manual User Acceptance Tests (UAT) execution
+//* Alpha/beta tests by registry development teams
+* Виконання ручних тестів на прийняття користувачем (UAT)
+* Альфа/бета-тести з командами розробників реєстру
+
+//Production cluster::
+Кластер продукції (Production cluster)::
+//After a year-long development cycle, we conduct the following testing in the production environment:
+Після року розробки ми проводимо наступне тестування в середовищі продукції:
+
+//* Manual User Acceptance Tests (UAT) execution with customer representatives.
+* Виконання ручного тестування на прийняття користувачем (UAT) разом з представниками клієнта.
+
+[plantuml,enable-mocking-flow, svg]
+----
+include::testing:image$functionalTesting/quality-gates.puml[enable-mocking-flow, align="center"]
+----
+
+//=== Tools and Technologies Used
+===  Використовувані інструменти та технології
+
+//The following types, tools and technologies are used during functional testing:
+Під час функціонального тестування використовуються наступні типи, інструменти та технології:
+
+[options="header"]
+|===
+//| Functional testing type | Toolset | Status
+| Тип функціонального тестування | Інструменти | Статус
+//| Unit testing
+| Модульне тестування
+| JUnit, Mockito
+//| Automated
+| Автоматизоване
+
+//| Integration testing
+| Інтеграційне тестування
+| JUnit, AssertJ, RestAssured
+//| Automated
+| Автоматизоване
+
+//| System testing
+| Системне тестування
+| JUnit, Selenide, RestAssured
+//| Automated
+| Автоматизоване
+
+//| Visual testing
+| Візуальне тестування
+| Selenide, Moon
+//| Automated
+| Автоматизоване
+
+//| Acceptance testing
+| Приймальне тестування
+| JUnit, Selenide
+//| Automated/Manual
+| Автоматизоване /Ручне
+
+//| Regression testing
+| Регресійне тестування
+| JUnit, Selenide, Moon, RestAssured
+//| Automated
+| Автоматизоване
+|===
+
+//== Managing defects
+== Управління дефектами
+
+//=== Registering and processing defects
+===  Реєстрація та обробка дефектів
+
+//We categorize the newly discovered defects into three groups depending on their origins:
+Ми категоризуємо новознайдені дефекти за трьома групами в залежності від їх походження:
+
+//* [*] *Production defects*
+//* [*] *Regression defects*
+//* [*] *Functional defects*
+* *Дефекти виробництва* (Production defects)
+* *Дефекти регресії* (Regression defects)
+* *Функціональні дефекти* (Functional defects)
+
+//==== Production defects
+==== Дефекти виробництва (Production defects)
+
+//These are defects identified in the live or production environment after the software deployment. Production defects can impact end-users, disrupt business processes, and require immediate attention to minimize adverse effects.
+Це дефекти, виявлені в живому або виробничому середовищі після розгортання програмного забезпечення. Дефекти виробництва можуть вплинути на кінцевих користувачів, порушити бізнес-процеси та вимагати негайної уваги для мінімізації негативних наслідків.
+
+//Defects obtained from the production environment should be linked to the defect handling epic related to the production environment.
+//They should have labels like JSM competencies: `DevOps`, `Backend`, `Frontend`, etc., and include a reference to the user-reported defect description.
+//A link to the corresponding Jira defect should be provided for defects reported by users.
+Дефекти, виявлені виробничим середовищем, повинні бути пов'язані з епіком обробки дефектів, пов'язаної з виробничим середовищем. Вони повинні мати мітки, такі як JSM компетенції: `DevOps`, `Backend`, `Frontend` і т. д., і включати посилання на опис дефекту, який був повідомлений користувачем. Для дефектів, повідомлених користувачами, слід надати посилання на відповідний дефект Jira.
+
+//==== Regression defects
+==== Дефекти регресії (Regression defects)
+
+//Regression defects occur when a new code change or feature introduction inadvertently causes a previously working functionality to fail. They can happen due to code changes affecting interconnected parts of the software.
+Дефекти регресії виникають, коли нова зміна в коді або введення нової функції навмисно призводять до відмови раніше працюючої функціональності. Вони можуть виникати через зміни в коді, які впливають на взаємопов'язані частини програмного забезпечення.
+
+//We log defects found during regression testing or while testing other tasks within the scope of a regression epic.
+Ми реєструємо дефекти, знайдені під час тестування регресії або під час тестування інших завдань, які входять до складу епіку регресії.
+
+//==== Functional defects
+==== Функціональні дефекти (Functional defects)
+
+//Functional defects arise when a software component does not perform its intended function correctly during development.
+//They can include incorrect calculations, inaccurate data processing, or failure to execute specific actions as expected.
+Функціональні дефекти виникають, коли компонент програмного забезпечення під час розробки не виконує свою призначену функцію належним чином. Це може включати в себе невірні розрахунки, неточну обробку даних або невиконання певних дій так, як очікувалося.
+
+//We link any defects detected during new functionality testing to the corresponding user story where we found them.
+Ми посилаємо будь-які виявлені дефекти під час тестування нової функціональності на відповідну користувацьку історію, де ми їх виявили.
+
+//=== Processing defects
+=== Обробка дефектів
+
+//The defect processing is as follows:
+Обробка дефектів виглядає так:
+
+//* We prioritize all defects according to the conditions outlined in the xref:#prioritizing-defects[Prioritizing defects] section and review in the following xref:#determining-defect-importance[Determining defect importance] section.
+* Ми визначаємо пріоритети всіх дефектів відповідно до умов, викладених у розділі xref:#prioritizing-defects[Пріоритезація дефектів] та переглядаємо їх у розділі xref:#determining-defect-importance[Визначення важливості дефектів].
+//* A resolved defect is marked as *`Ready for QA`* and forwarded to the defect registrar. If the defect registrar represents the client, we forward it to the testing team leader.
+* Дефект, який було усунено, позначається як *`Готовий для тестування`* і пересилається до реєстратора дефектів. Якщо реєстратор дефектів представляє клієнта, ми пересилаємо його до керівника команди тестування.
+//* The defect registrar reviews the defect and, if resolved, marks it as closed on a valid quality gate. If the defect reproduces again, it is returned to development with a *`Rework`* status.
+* Реєстратор дефектів переглядає дефект і, якщо його було усунено, позначає його як закритий на валідному рівні якості. Якщо дефект відтворюється знову, він повертається до розробки зі статусом *`Переробка`*.
+
+[#prioritizing-defects]
+//=== Prioritizing defects
+=== Визначення пріоритетів дефектів
+
+//Consider the following criteria (not listed in the table) to determine the severity of defects and their impact on further development:
+Враховуйте наступні критерії (які не включені в таблицю) для визначення серйозності дефектів та їх впливу на подальший розвиток:
+
+[options="header"]
+|===
+//| Priority Level | Description | Impact on Testing
+| Рівень пріоритету | Опис | Вплив на тестування
+//| 0: *`Blocker`*
+| 0: *`Blocker (Блокер)`*
+//| The Platform stops functioning, and there is no workaround.
+| Платформа припиняє свою роботу, і немає обхідного шляху.
+//| The testing team sends the build back to development.
+| Команда тестування повертає збірку розробникам.
+
+//| 1: *`Critical`*
+| 1: *`Critical (Критичний)`*
+//| Functionality is not working.
+| Функціональність не працює.
+//| The testing team provides a test report for the development and management team. Management team decides about flow (rework, hotfix).
+| Команда тестування надає звіт з тестування розробникам і керівництву. Керівництво вирішує питання про подальші дії (переробку, гарячий виправлення).
+
+//| 2: *`Major`*
+| 2: *`Major (Важливий)`*
+//| Critical business requirements are broken.
+| Порушені критичні бізнес-вимоги.
+//| The presence of priority 2 defects requires additional agreement with the business team and project management.
+| Присутність дефектів із пріоритетом 2 вимагає додаткової узгодженості з бізнес-командою і управлінням проекту.
+
+//| 3: *`Minor`*
+| 3: *`Minor (Мінорний)`*
+//| Functionality is not working according to design, but an acceptable workaround exists.
+| Функціональність не працює відповідно до дизайну, але існує прийнятний обхідний шлях.
+//| Business and development teams agree on the necessity of defect resolution within the current release.
+| Бізнес і розробницькі команди узгоджують необхідність вирішення дефекту в поточному релізі.
+
+//| 4: *`Trivial`*
+| 4: *`Trivial (Дрібний)`*
+//| Minor changes needed in functionality -- aesthetic or cosmetic changes.
+| Потрібні незначні зміни в функціональності — естетичні або косметичні зміни.
+//| Business and development teams agree on the necessity of defect resolution within the current release.
+| Бізнес і розробницькі команди узгоджують необхідність вирішення дефекту в поточному релізі.
+|===
+
+[#determining-defect-importance]
+//=== Determining defect importance
+=== Визначення важливості дефекту
+
+// the stages of development, regression/stabilization, the development team conducts internal and external sessions to review the list of defects to determine their current priorities and statuses. To refine a defect, please use the clarifying statuses in the table and include a detailed comment.
+Під час етапів розробки, регресії/стабілізації розробницька команда проводить внутрішні та зовнішні сесії для перегляду списку дефектів та визначення їх поточних пріоритетів та статусів. Для уточнення дефекту, будь ласка, використовуйте статуси, які з'являються в таблиці, і додайте докладний коментар.
+
+//The testing team leader and the defect registrar are responsible for closing defects.
+Лідер команди тестування та реєстратор дефектів відповідають за закриття дефектів.
+
+[options="header"]
+|===
+//| Status | Explanation | Will it be resolved?
+| Статус | Пояснення | Чи буде вирішено?
+
+//| *`Not a bug: Cannot reproduce`*
+| *`Не дефект: Дефект, який на даний момент не може бути відтворений`*
+//| The defect that cannot be reproduced at the moment
+| Дефект на даний момент не може бути відтворений
+//| No
+| Ні
+
+//| *`Not a bug: Duplicate`*
+| *`Не дефект: Дублікат`*
+//| The defect is already registered
+| Дефект вже залоговано
+//| No
+| Ні
+
+//| *`Done`*
+| *`Виконано`*
+//| The testing is completed thoroughly, and functionality is working
+| Тестування проведено ретельно, і функціональність працює
+//| Yes
+| Так
+
+//| *`Rework`*
+| *`Переробка`*
+//| The testing was completed thoroughly, and functionality isn't working after the fix
+| Тестування було проведено ретельно, і функціональність не працює після виправлення
+//| No
+| Ні
+
+//| *`Won't Do`*
+| *`Не буде виправлено`*
+//| The defect has minimal impact on business and won't be resolved
+| Дефект має мінімальний вплив на бізнес і не буде виправлено
+//| No
+| Ні
+
+//| *`Fixed`*
+| *`Виправлено`*
+//| After making changes, a thorough testing process was conducted.
+| Після внесення змін було проведено ретельний процес тестування.
+//| Yes
+| Так
+
+//| *`Obsolete`*
+| *`Застарілий`*
+//| The defect is outdated
+| Дефект застарів
+//| No
+| Ні
+
+//| *`Cancelled`*
+| *`Скасовано`*
+//| Cancelled functionality
+| Скасована функціональність
+//| No
+| Ні
+
+//| *`Implemented`*
+| *`Реалізовано`*
+//| Technical error that doesn't require testing
+| Технічна помилка, яка не потребує тестування
+//| Yes
+| Так
+
+//| *`Deferred`*
+| *`Відкладено`*
+//| Awaiting resolution in upcoming releases and planned functionality
+| Чекає вирішення в майбутніх випусках і запланованій функціональності
+//| Yes
+| Так
+
+//| *`Not a Bug`*
+| *`Не дефект`*
+//| Is not a defect
+| Не є дефектом
+//| No
+| Ні
+|===
+
+//== Reporting
+== Звітність
+
+//Testing reports comprise two types:
+Звіти з тестування включають два типи:
 
-CAUTION: Документ у процесі розробки. Перейдіть до англійської версії сторінки.
\ No newline at end of file
+//* ReportPortal automation report that can be provided to stakeholders.
+//* Manual report after manual suite execution that can be provided to stakeholders.
+* Звіт з автоматизації ReportPortal, який може бути наданий зацікавленим сторонам.
+* Звіт після виконання ручного набору тестів, який може бути наданий зацікавленим сторонам.
\ No newline at end of file