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

Тестування електронного майданчика на відповідність вимогам ЕТС 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 Баги відсутні (успішне проходження)
      2. Баги не виправлені (негативний результат): 
         • Команда QA надає draft «Висновок про не проходження тестування» додає його в запит на тестування та переводить задачу на менеджера по роботі з майданчиками.
         • Начальник відділу ІТ підписує «Висновок про не проходження тестування».
         • Адміністратор має право оголосити Попередження, відділ по роботі з майданчиками разом з юридичним відділом готують проєкт попередження або відповідний наказ.
         • Закривається запит на тестування
         • Комунікація: Попередження надсилається Оператору офіційним листом. Одночасно інформація дублюється в Slack-канал майданчика для оперативного реагування технічної команди.
         • Оператор повинен усунути недоліки протягом терміну визначеному в Попередженні та подати новий запит на тестування через Workflow «Тестування процедур» або «Тестування окремого функціоналу».

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

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