Загальні правила тестування

Тестування електронного майданчика на відповідність вимогам ЕТС Prozorro.Продажі ЦБД2 відбувається згідно зі створеною Заявкою на тестування за встановленою формою. Ініціювання тестування може відбуватися як Оператором (шляхом подання заявки через відповідний Workflow у Slack) , так і Адміністратором (співробітником АТ) у випадку планових або позапланових перевірок.

На початку тестування фіксується версія ПЗ електронного майданчика, яка підлягає перевірці.

За результатами процесу уповноваженим підрозділом Адміністратора, формується Висновок щодо результатів тестування (Додаток № 4 до Положення про порядок проходження тестування електронних майданчиків на відповідність вимогам Електронної торгової системи “Prozorro.Продажі” ЦБД2).

Тестування здійснюється відповідно до Технічних вимог та сценаріїв (посилання на які розміщуються у відповідних каналах у Slack:)  

• Технічна документація

• Тестування ЦБД v.3

• https://gitlab.prozorro.sale/explore

Основні типи тестування:

• Повна акредитація: тестування при первинному підключенні майданчика до ЕТС.
• Тестування окремого/розширеного функціоналу: перевірка нових напрямків (процедур) або обов'язкових технічних оновлень системи.
• Планове тестування: регулярна перевірка авторизованих майданчиків, про яку повідомляється за 10 робочих днів.
• Позапланове тестування: оперативна перевірка технічної функціональності без попереднього інформування Оператора.

Процес тестування на НЕПРОД оточення

Початок тестування:

1. Реєстрація запиту на тестування через Workflow  у Slack «Тестування процедур» або «Тестування окремого функціоналу».
2. Менеджер по роботі з майданчиками перевіряє пакет документів та переводить статус задачі в Jira на «Перевірено», що автоматично призначає виконавцем QA команду.
3. Комунікація: публікація повідомлення у приватному каналі Оператора у Slack про початок тестування конкретної версії ПЗ.

Проведення тестування:

1. Доступне тестове оточення, на якому розгорнута певна версія ПЗ
2. Проведення перевірки технічної відповідності згідно із сценаріями тестування.

Результат тестування:

1. Баги відсутні (успішне проходження):
   1. QA команда формує draft «Висновку про проходження тестування», додає його в запит на тестування та змінює в статус Тестування завершене, задача автоматично переходить на  на менеджера по роботі з майданчиками.
   2. Начальник відділу ІТ підписує «Висновок про проходження тестування».
   3. Видається Наказ «Про завершення тестування»
   4. Закривається запит на тестування менеджером по роботі з майданчиками
   5. Комунікація: публікація повідомлення у приватному каналі Оператора в Slack про завершення тестування.
   6. Майданчик отримує право на видачу/розширення дозволів продуктивного ключа.
2. Баги наявні:
   1. Виявлені невідповідності (баги) зафіксовані в GitLab/Jira.
   2. Згідно з Положенням про порядок проходження тестування, Оператор повинен усунути недоліки протягом 1 (одного) робочого дня з моменту отримання зауважень.
   3. Оператор розгортає на тестовому оточенні оновлену версію ПЗ
   4. Відбувається проведення повторної перевірки виправлених багів QA командою
      1. Баги виправлені (позитивний результат):
         1. Відбуваються дії описані в п.1 Баги відсутні (успішне проходження)
      2. Баги не виправлені (негативний результат): 
         1. Команда QA надає draft «Висновок про не проходження тестування» додає його в запит на тестування та змінює в статус Тестування завершене, задача автоматично переходить на  на менеджера по роботі з майданчиками..
         2. Начальник відділу ІТ підписує «Висновок про не проходження тестування».
         3. Адміністратор має право оголосити Попередження, відділ по роботі з майданчиками разом з юридичним відділом готують проєкт попередження або відповідний наказ.
         4. Закривається запит на тестування
         5. Комунікація: Попередження надсилається Оператору офіційним листом. Одночасно інформація дублюється в Slack-канал майданчика для оперативного реагування технічної команди.
         6. Оператор повинен усунути недоліки протягом терміну визначеному в Попередженні та подати новий запит на тестування через Workflow «Тестування процедур» або «Тестування окремого функціоналу».

Крайній захід: у разі подальшого виявлення недоліків та отримання наступних  попереджень Адміністратор може прийняти рішення про припинення доступу (блокування продуктивних ключів) Оператора до ЕТС

Процес тестування на ПРОД оточення

Адміністратор має право проводити планове або позапланове тестування без попереднього інформування операторів.

Ініціювання тестування відбувається Адміністратором (співробітником АТ), шляхом створення заявки через відповідний Workflow у Slack «Тестування продуктивного оточення»

Версія на ПРОД оточенні  має бути аналогічною або вище версії що пройшла успішне тестування на тестовому оточенні.

Передумови тестування:

• успішне проходження перевірки версії ПЗ майданчика на тестовому оточенні
• Для регулярних релізів: майданчик розгортає версію на ПРОД лише після отримання офіційного повідомлення про успішне завершення тестування в Slack-каналі.
• Для синхронних релізів: дата релізу узгоджена окремо в межах релізного процесу ЦБД.

Початок тестування:

• Реєстрація запиту на тестування через Workflow  у Slack «Тестування продуктивного оточення»
• Комунікація: публікація повідомлення у приватному каналі Оператора в Slack про початок тестування.
• Визначити останню протестовану версію

Проведення тестування:

• Перевірити поточну версію ПЗ майданчика у форматі {"version": "X.X.X"}

Результат тестування:

1. Успішне проходження
   1. QA команда формує draft «Висновку про проходження тестування», додає його в задачу на тестування
   2. QA команда  закриває запит на тестування продуктивного оточення
   3. Комунікація: публікація повідомлення у приватному каналі Оператора в Slack про завершення тестування.
2. Неуспішне проходження (недоступність майданчика, неможливість отримати версію ПЗ на проді, версія ПЗ нижче протестованої, тощо)
   1. Виявлена невідповідність зафіксована в GitLab/Jira
   2. Згідно з Положенням про порядок проходження тестування, Оператор повинен усунути недоліки протягом 1 (одного) робочого дня з моменту отримання зауважень.
   3. Оператор розгортає на продуктивному оточенні оновлену версію ПЗ
   4. Відбувається проведення повторної перевірки
      1. Невідповідності виправлені (позитивний результат):
         1. Відбуваються дії описані в п.1 (Успішне проходження)
      2. Невідповідності не виправлені (негативний результат):
         1. Команда QA надає draft «Висновок про не проходження тестування» додає його в запит на тестування продуктивного оточення та переводить задачу на менеджера по роботі з майданчиками.
         2. Начальник відділу ІТ підписує «Висновок про не проходження тестування».
         3. Адміністратор має право оголосити Попередження, відділ по роботі з майданчиками разом з юридичним відділом готують проєкт попередження або відповідний наказ.
         4. Закривається запит на тестування продуктивного оточення
         5. Комунікація: Попередження надсилається Оператору офіційним листом. Одночасно інформація дублюється в Slack-канал майданчика для оперативного реагування технічної команди.
         6. Оператор повинен усунути недоліки протягом терміну визначеному в Попередженні та подати через Workflow запит на «Тестування продуктивного оточення»

Крайній захід: Адміністратор має право оголосити повторне Попередження або ініціювати обмеження/блокування продуктивних ключів через Workflow «Блокування дозволів».