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

      Робота з листами, які готує  ДП, описана в окремому розділі TODO


    Майданчики (оператори), які мають намір пройти тестування електронних майданчиків щодо можливості проведення ними електронних торгів за процедурами ЦБД-2 (додати поситання на перелік процедур) подають на адресу адміністратора заявку на тестування у письмовому вигляді. Детальна процедура описана у Положенні про тестування електронних майданчиківАктуальна версія положення розміщена у роздалі "Майданчикам"→  "Тестування" робочаого ресурсу Прозорро.Продажі



  1. ДП Прозорро.Продажі (ДП ПП) скликає комісію і розглядає заяву та надані  майданчиком документи  і визначає умови проходження тестування

    1. Юрист, який відповідає за авторизацію, за фактом отримання запиту на тестування, вносить базову інформацію про майданчик у Таблицю авторизації операторів


  2. В разі прийняття комісією позитивного рішення, то юристи встановлюють відмітку в Таблицю авторизації операторів, в колонку 10 “Допущена” та передають заявку на тестування з усіма документами на фінансовий відділ. ІТ 

    1. ДП ПП починає працювати з майданчиком тільки після: 

      1.  оплати (в разі, якщо оплата передбачається), оновлення статусу по сплаті (С.Бут, колонки Отримання плати за тестування і Дата оплати за тестування в Таблиці авторизації операторів) та підписання договору про доступ до тестового середовища (Юрист, який відповідає за авторизацію (станом на 02.10.2018: А. Нагребельний)). Після підписання договору юрист ставить відмітку у колонці Договір тестування № дата та тегає у таблиці відповідального за тестування координатора.

      2. Паралельно, але не раніше прийняття комісією позитивного рішення, в Jira створюється задача, в проекті SBM з типом Акредитація майданчика (задачу створюють співробітники відділів управління проектами та програмами, бюджетування та економічного аналізу),   При цьому задача у Jira створюється тим ПМ, який працює з конкретним майданчиком, потім передається  на юридичний відділ, де задачі проставляється відмітка про наявність підписаного договору і передається до фінансового відділу і тільки після того як буде проставлено відмітку про сплату (або про безоплатність послуг тестування) задача потрапить до ІТ відділу.


  3. Підготовчі роботи (можуть відбуватись паралельно):

    1. Видача ключа доступу до пісочниці (тестове оточення)

      1. майданчик отримує, від відповідального ПМ посилання на форма запиту  на отримання ключів до сендбоксу  (дані зберігаються в таблиці). Після заповнення форми автоматичний лист відправляється на трекер Квінтагруп (КГ), який в свою чергу генерує лист-запит на підтвердження надання ключів.

      2. Якщо всі попередні кроки виконано, ІТ ДП ПП відповідає на лист з підтвердженням надання ключів. Перед підтвердженням необхідно перевірити, що інформація у запиті майданчика співпадає з даними, які внесені у Таблицю авторизації операторів.

      3. На основі цього підтвердження КГ видає ключ: майданчик отримує на реєстраційний мейл посилання, а на реєстраційний номер телефону - пін для відкриття посилання. У майданчика є одна спроба на введення піну. У разі помилки ключ потрібно перезамовляти . 

      4. Відповідальний ПМ або співробітник ІТ відділу, після отримання майданчиком ключів проставляє в відповідній задачі Jira  відмітку “Тестові ключі надано”

    2. ДП ПП додає майданчик в наступні вкладки файла про тестування:

      1. “Платне тестування” (включаючи дедлайн, 40 робочих днів від дати початку). Дедлайн автотестів ~ 2 тижні до основного дедлайну, для того, щоб був час на повноцінне ручне тестування. 

      2. В залежності від того, на яку кількість ітерацій було розподілено тесткейси створюються додаткові вкладки роудмепу “Черга майданчиків НАЗВА ПРОЕКТУ {1, 2, 3, 4} ітерація” на на всі вкладки додаються всі майданчики в сталому порядку, нові майданчики завжди додаються в кінець списку а статус майданчиків проставляэться згідно легенди.

    3. IT ДП ПП створює канал в slack (канал) з іменем test-new-{marketplacename}, і додає туди ІТ-координатора тестування, ручних тестувальників (СофтСерв) і авто тестувальників (КГ), менеджмент майданчиків, ІТ спеціалістів майданчиків. Після створення ДП ПП відправляє в канал посилання на опис автотестів (доступні на порталі)


    1. Хід тестування: автоматичне

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

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

        1. Шаблон інформування про нові ПР:

          1. ЦБД: 2 (*приклад!*)

          2. Ітерація: N/A

          3. Стадія: перший PR\зміна конфігурації\багфікс

          4. Посилання: {github_url}

          5. Коментарі: ---

      3. авто тестувальник в каналі приймає пулл реквест і проводить ревью

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

      5. у разі успіху авто тестувальник або ІТ майданчику в канал повідомляє про успішне проходження

      6. представник ДП ПП перевіряє факт проходження (статус в Дженкінсі, КГ) та заносить відмітку про успішне проходження у файл про тестування

      7. після проходження роботестів, автоматичне тестування вважається пройденим. КГ готує лист по узгодженій формі і передає його ДП ПП. До передачі оригіналу КГ надсилає посилання на скани таких лістів.

      8. В разі успішногопроходження автотестів в задачі Jira змінюється статус на “Автоматичне тестування пройдено” та задача автоматично предається на ІТ відділ для проведення ручного тестування. В разі якщо майданчик не вкладається в строки по автотестам (або по будь-яким іншим причинам, які блокують подальшу роботу  та по настанню дедлайну по автотестам) майданчику присвоюється статус “Автоматичне тестування не пройдено” після чого задача автоматично передається на ініціатора, який і закриває задачу. Задача автоматично не закривається.


  4. Хід тестування: ручне

    1. представник майданчика повідомляє в канал про готовність до проходження чергової фази (ітерації) тестування

    2. мануальний тестувальник (СофтСерв/ДП ПП) додає майданчик до черги тестування. Ручне тестування для майданчиків розпочинається після підтвердження проходження автотестування. Виключення можливі у випадку наявності додаткових ресурсів на ручне тестування. Інші ситуації обговорюються окремо

    3. після настання черги та виконання ручного тестування тестувальник підтверджує факт проходження тестів і, відповідно:

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

      2. заносить відмітку в файл про тестування (roadmap)

      3. В разі успішногопроходження мануальних тестів  в задачі Jira змінюється статус на “Мануальне тестування пройдено”.  В разі якщо майданчик не вкладається в строки по мануальному тестуванню (або по будь-яким іншим причинам, які блокують подальшу роботу з тестування,  по настанню дедлайну по мануальному тестуванню) майданчику присвоюється статус “мануальне тестування не пройдено” після чого задача автоматично передається на ініціатора, який і закриває задачу. Задача автоматично не закривається.


  5. Після успішного проходження п.4 та п.5  ІТ ДП ПП

      1. в Таблиці авторизації операторів встановлює галочку в колонці 11 “протестована”

      2. ІТ департамент ДП ПП формує звіт про результати ручного тестування

      3. ІТ департамент ДП ПП формує лист про проходження тестів і направляє його на комісію, а також встановлює галочку 12 “Лист від QA” в Таблиці авторизації операторів. Цей лист в паперовому вигляді передається в юридичний департамент.

      4. В деяких виключних випадках ДП ПП має право виконати п.6 по факту проходження тільки п.6 (без п.5)

      5. Відповідальний юрист готує верифікаційний лист від ТІ (на базі листа про ручне тестування) ставить галочку "Верифікаційний лист" в Таблиці авторизації операторів, підписує його в ТІ та передає на Комісію.

      6. Jira

  6. Збирається комісія у складі представників ДП ПП, ТІ, МЕРТ та розглядає надані листи. Результатом роботи комісії для процесу тестування є:

    1. верифікаційний лист та галочка 13 “Верифікаційний лист” в Таблиці авторизації операторів,

    2. галочку 14 “Авторизовано”

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

    4. Контракт(и), які відправляються на електронну пошту майданчика, потім підписуються майданчиком і ДП ПП у паперовому вигляді

    5. Jira

  7. Після отримання 2-х примірників контракту відповідальний юрист присвоює дату та номер договорів та вносить їх до таблиціІнформація про успішне виконання п.6 надається в ІТ ДП ПП (у будь-який зручний спосіб). На основі і тільки після цього ІТ ДП ПП надсилає майданчику (у каналі майданчика в Slack, що пройшов тестування, електронну форму (дані зберігаються в таблиці) для отримання продуктивного ключа.

      1. Шаблон тексту: "Доброго дня! Прохання заповнити форму для видачі продуктивного ключа доступу до ЦБД-2.

      2. Будь ласка, зверніть увагу на коректність заповнення контактної інформації та номеру договору на використання ЕТС (не договору на тестування).

      3. Посилання на форму: https://docs.google.com/forms/d/e/1FAIpQLSfG6T21zY8nfJCp_IjLVY_y_2bDKZZOU8UvcOnaK-r81eqU_A/viewform"  

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

    1. Трекер КГ генерує лист на підтвердження для ІТ ДП ПП. Після отримання відповіді на цей лист з підтвердженням КГ генерує продуктивний ключ по процесу, описаному в п.5

      1. Jira

  8. Майданчик підтверджує отримання ключа в каналі, після чого ІТ ДП ПП оновлює Таблицю авторизації операторів (колонки про отримання продуктивного ключа) та активує майданчик на публічному порталі.

    1. Інформація, необхідна для активації на Публічному Порталі:

      1. посилання на продуктивний лот у тестовому режимі (mode: test, посилання на публічний api)

      2. посилання на продуктивне середовище типу https://www.XXXXX.com

      3. посилання для переходу на майданчик зі сторінки аукціону формату  https://www.XXXXX.com/auctions/{auctionID}

        1. Шаблон переходів для ЦБД-1 та ЦБД-2 на порталі має співпадати. За потреби, майданчик робить редірект на своєму боці. Відрізнити ЦБД-1 та ЦБД-2 можна за ІД аукціонів у посиланні. UA-EA-... - ЦБД-1. UA-PS-... - ЦБД-2

      4. назва Юридичної особи (буде виводитись у протоколах торгів)

      5. посилання на файл з логотипом майданчика. Вимоги до лого: png, прозорий фон, пропорції 2:1, мінімальний розмір: 200 (ширина) х 100 (висота)

    2. ІТ ДП ПП перевіряє відповідність broker_id у наданих тестових посиланнях актуальному broker_id майданчика, для якого видавали ключі (поле owner у api) та відповідність url адресі, яка вказана у договорі (інформація з Таблиці авторизації операторів)

    3. IT ДП ПП змінює назву канала майданчика з test-new-{broker_name} на testing-{broker_name}

    4. Jira

  9. Майданчик повинен надати ДП ПП інформацію щодо реквізитів:

    1. Форма для заполнения реквизитов в нац. валюте https://drive.google.com/open?id=1L59ekY_wtiBslraotCJOAh2HbzskOS6uBIXWhM7MiBA

    2. Форма для заполнения реквизитов валютных счетов https://drive.google.com/open?id=1NTXNFpPJNJzzyl2p5O5whUmqpXeH-R9k3d5yQCsO394

    3. Jira


  10. Після отримання всіх документів задача стосовно конкретного майданчика передаэться ініціатору і закривається ним вручну. 
  • No labels