Таблиця змін

Дата

Номер сценарію

Короткий опис змін







Зміст

1. Вступ

1.01Мета
1.02Термінологія
1.03Загальний огляд
1.04Тестова документація
2. Предмет тестування
2.01Основні – компоненти які доступні в усіх процедурах в ЦБД
2.02Додаткові – компоненти які доступні лише в певних процедурах ЦБД
2.03Функціонал, що буде тестуватись
2.04Функціонал, що не буде тестуватись
3.  Тестова стратегія
3.01Тестовий підхід
3.02Типи тестування
3.03Тестове покриття
4. Процес контролю якості
4.01Планінг
4.02Створення тестової документації
4.03Тестові очікувані результати
4.04Тестування
4.05Відвідування мітингів з командою АТ ProZorro.Продажі та представниками Майданчиків
5. Критерії призупинення та відновлення тестування
5.01Критерії призупинення тестування
5.02Критерії відновлення тестування
5.03Критерії проходження / невдачі тестів
6. Потреби для тестування
6.01 Потреби у персоналі та навчанні
6.02Тестове середовище
6.03Клієнтське середовище
6.04Інструменти для тестування

7 Ролі та обов’язки QC спеціаліст

8 Ризики

9 Припущення


1. Вступ

1.01  

Мета

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

1.02  

Термінологія

Термін

Визначення

QC

Контроль якості

QCE

Спеціаліст з забезпечення контролю якості

PM

Проект менеджер

ВА

Бізнес Аналітик

ЦБД

Центральна База Даних

Майданчик

Брокер, з власним веб-інтерфейсом для реалізації процедур аукціонів

Організатор

Користувач який зареєстрованій на майданчику та має доступ для створення та подальшої взаємодії з процедурою

Участник

Користувач який зареєстрованій на майданчику та має доступ для подачі закритої цінової пропозиції/заявки на участь

Спостерігач

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

МА

Модуль Аукціону

Зміст

1.03  

Загальний огляд

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

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

Зміст

1.04

Тестова документація

  • Тестові сценарії
  • Тест-кейси
  • Тестові прогони

Тестова документація формуються на основі документів від ВА:

  • Шаблон
  • Технічне завдання
  • Вимоги для майданчиків
  • Swagger
  • Timeline 
  • Деталізований Timeline
  • Legal_names
  • Причини дискваліфікації - TerminationReason
  • Причини скасування - CancellationReason
  • Модель статусів procedure
  • Модель статусів bid`а
  • Модель статусів award'у
  • Моделі статусів contract'у

Зміст


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

2.01

Основні – компоненти які доступні в усіх процедурах в ЦБД

Наступні компоненти процедури які будуть тестуватися

Основні – компоненти які доступні в усіх процедурах в ЦБД:

  • Реєстрація та внесення змін в аккаунту
  • Робота з чернеткою. Публікація процедури
  • Робота з Document Service
  • Редагування процедури
  • Робота з питаннями/відповідями
  • Пошук процедури на Майданчику 
  • Робота з заявою на участь
  • Робота з bid'ом
  • Отримання та перехід по посиланню в МА
  • Кваліфікація Учасників
  • Дискваліфікація Учасників
  • Перелік допустимих операцій для award'ів
  • Робота з contracts
  • Скасування процедури
  • Завершення процедури
  • Статуси, документи

Зміст

2.02

Додаткові – компоненти які доступні лише в певних процедурах ЦБД

Додаткові – компоненти які доступні лише в певних процедурах ЦБД:

  • Робота Організатора з блоком currentTenants
  • Учасник з Переважним правом
  • Внесення змін в опубліковану процедуру протягом transferPriorityPeriod
  • Втрата Переважного права
  • Функціонал та відображення Учасника дискваліфікований в попередній процедурі
  • Робота з оплатою
  • Робота з забезпечувальним платежем
  • Завантаження "Рішення про викуп" для award'у pending.admission
  • Пролонгація строку роботи із договором. Документи пролонгації
  • Деактивація заяви на участь
  • Відображення bid'а "Учасника з Переважним правом"
  • Повторна активація bid'а з після набуття статуса inactive
  • Активація bid'а після втрати Переважного права
  • Формування приватного посилання при подачі заяви на участь під час DUTCH PART

Зміст

2.03

Функціонал, що буде тестуватись

  • Відображення Майданчика для Користувача
  • Створення аккаунту на Майданчику
  • Реєстрація Організатора аукціону
  • Реєстрація Учасника
  • Внесення змін в акаунт
  • Авторизація на Майданчику
  • Створення та редагування чернетки
  • Видалення чернетки
  • Публікація процедури
  • Створення та публікація копії процедури на основі існуючої
  • Формування періодів процедури
  • Блок банківські реквізити
  • Завантаження документів
  • Оновлення документів
  • Особливості роботи з digitalSignature
  • Внесення змін в опубліковану процедуру протягом rectificationPeriod
  • Робота з документами в процедурі протягом tenderPeriod
  • Подача запитання
  • Надання відповіді на задане запитання
  • Пошук аукціону
  • Створення локальної чернетки заяви на участь
  • Редагування та видалення локальної чернетки заяви на участь 
  • Публікація в ЦБД локальної чернетки заяви на участь
  • Публікація в ЦБД локальної чернетки заяви на участь від учасника дискваліфікованого раніше
  • Публікація в ЦБД локальної чернетки заяви на участь від учасника з Пріоритетним правом
  • Редагування bid'а
  • Видалення bid'а
  • Публічне посилання
  • Приватне посилання
  • Умови формування award'ів та їх статуси
  • Відображення таблиці кваліфікації на Майданчику
  • Робота з оплатою
  • Завантаження  auctionProtocol Учасником
  • Завантаження auctionProtocol Організатором 
  • Завантаження документів договору та підтвердження Договору Організатором протягом active_awarded
  • Дискваліфікація 2-х award'ів в різних статусах
  • Операції для award'у в різних статусах
  • Скасування процедури в різних статусах
  • Документи procedure 
  • Документи bid`a
  • Документи award'у
  • Документи contract'у
  • Статуси procedure 
  • Статуси award'у
  • Статуси contracts
  • Статуси bid`a

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

Зміст

2.04

Функціонал, що не буде тестуватись

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

Зміст

3.  Тестова стратегія

3.01

Тестовий підхід

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

Після завершення написання документації процедури від ВА. Готують документація тестування.

Процес тестування починається з надання/розширення тестових ключів (доступу) Майданчику до процедури. Після подачі відповідної заявки в jira представником Майданчика.

Після розробки процедури та самостійного тестування Майданчик подає заявку на тестування з вказанням дати готовності. Отриману заявку в jira  реєструють в відповідний спринт з додаванням тестового прогону та відповідального QCE.

В запланований день тестування відповідальний на QCE уточнює стан готовності Майданчики. Вразі підтвердження готовності QCE проводить тестування відповідно до доданого тестового прогону.  

Зміст

3.02

Типи тестування

Наступні типи тестування використовуються на проекті:

Acceptance testing -  здійснюється членами QC команди реалізації процедури Майданрчиком відповідно до всіх вимог та стандартів.

Functional testing -  виявлення функціональних помилок, невідповідностей ТЗ з очікуванням користувача шляхом реалізації стандартних, а також нетривіальних тестових сценаріїв.

Component testing - застосовується при тестуванні конкретного компоненту процедури.

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

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

UI testing  - це тестування графічного інтерфейсу майданчика для перевірки відповідності фронт-енд частини вимогам.

Regression testing -  перевірка того, що після  імплементації нових компонентів попередні функціонують в стандартному режимі й нові компоненти не повпливали на існуючу систему.

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

Зміст

3.03

Тестове покриття

Всі нові функціональності та вдосконалення існуючої процедури повинні охоплюватися наступними тестами: Smoke testing, UI testing, Functional testing та Regression testing.
Після успішного виконання даних тестових перевірок - тестові сценарії повинні бути оновлені.

Тестування буде здійснено на тестових середовищах  sandbox та staging Майданчика після релізу процедури.

Зміст

4. Процес контролю якості

4.01

Планінг

QC процес складається з наступних активностей

  • Планінг:
  • Аналіз та визначення обсігу робіт наступного спрінт.
  • Тестове планування.
Зміст

4.02

Створення тестової документації
  • Створення тестових сценаріїв, кейсів, та тестових прогонів.
  • Підтримка та оновлення розроблених тестової документації на основі змін в ЦБД.

Зміст

4.03

Тестові очікувані результати
  • Тест план
  • Тестові сценарії
  • Тест кейси
  • Тестові прогони
  • Дефекти заведені в баг-трекінгових інструментах
  • Метрики результатів тестування або таблиці дефектів ( в разі запиту на них)
  • QC щотижневі звіти в письмовій формі або продемонстровані на мітинг-колах з замовниками

Зміст

4.04

Тестування
  • Підготовка необхідної тестової бази.
  • Мануальне виконання тестів.
  • Реєстрація дефектів та їх відслідковування.
  • Перевірка дефектів.
  • Звітування про виправлення дефектів.

Зміст

4.05

Відвідування мітингів з командою АТ ProZorro.Продажі та представниками Майданчиків
  • Планінг наступного майлстоуну.
  • Статус мітинги та щоденні мітинги з командою.
  • Демо мітінги.
  • Ретроспектива.
  • Щотижневі мітинги з замовниками.
Зміст

Критерії призупинення та відновлення тестування

5.01

Критерії призупинення тестування

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

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

Зміст

5.02

Критерії відновлення тестування

Перед початком тестування слід виконати наступні вимоги:

  • Повідомлення від Майданчика про готовність продовжувати тестування.
  • Всі раніше заведені дефекти були усунені та перевірені Майданчиком.
  • Тестування було проведено в середовищі тестування розробниками і жодних проблем не виявлено.
  • Smoke testing було проведено QA, щоб переконатись в роботі всіх найважливіших функцій перед перевіркою наступної ітерації.

Зміст

5.03

Критерії проходження / невдачі тестів

Тест пройдено (PASS) - аплікація виконується способом,  який описано в тестових кейсах, а також у відповідності до кроків відтворення. Під час виконання не виявлено дефектів.
Невдача (FAIL) - поведінка програми відрізняється від описаної в тестових сценаріях та очікуваних результатах. Або дефект з'явився на деяких етапах під час виконання тесту.

Наступні критерії визначають умови для статусу тесту "Невдача (FAIL)":

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

Критерієм для проходження тесту є протилежними до критеріїв невдачі і якщо жоден з них не виникає.

Зміст

6. Потреби для тестування

6.01

Потреби у персоналі та навчанні

Послуги з тестування командою АТ ProZorro.Продажі. В команді працюватимуть 2 спеціаліста з якості програмного забезпечення. В разі необхідності залучення додаткових спеціалістів або підвищенні кваліфікації будуть залучені зовнішні ресурси компанії з забезпечення якості продукту.

Зміст

6.02 

Тестове середовище

Dev – оточення де Майданчик проводить розробку та самостійну перевірку.

Sandbox – основне оточення де проводиться тестування процедури на Майданчику.

Staging – оточення де Майданчик проводить перевірку перед додаванням процедури на production.

Production – на даному оточенні тестування не проводиться командою АТ ProZorro.Продажі.

Зміст

6.03 

Клієнтське середовище

 Компонент

Версія

Операційна система

Windows 10 Professional

Веб-браузер

Google Chrome 113.0.5672.127 (64-разрядна версія)

Firefox 113.0.2 (64-разрядна версія)

Microsoft EdgeВерсия 113.0.1774.57 (64-разрядна версія)

Java Runtime Environment

Java 10.0.1


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

Зміст

6.04 

Інструменти для тестування

Наступні інструменти будуть використані QC спеціалістами для діяльності з контролю якості:

  • Розробка та обслуговування тестових кейсів - Confluence, Google Docs, Jira;
  • Відстеження дефектів (баг-трекер) – ведення дефектів ведеться в GitLab;
  • Інструменти для JSON відображення–JSON viewer browser addons, того;
  • Інструменти для роботи з API - Postman, Newman.

Зміст

7  Ролі та обов’язки QC спеціаліст

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

8  Ризики

№

Ризик

Пріори тет

Вірогідність

Вплив

Дії у разі настання

1

Кінцеві вимоги МА будуть відомі лише після підписання постанови, яка не підписана та термін підписання невідомий.

високий

високий

високий

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

2

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

високий

середній

високий

Зсув строків реалізації процедури з переважним правом

3

Порушення термінів підготовки документації

високий

середній

високий

Зсув строків реалізації процедури

4

Втрата ключових співробітників

середній

низький

високий

Зсув строків реалізації процедури

5

Недостатня кваліфікація спеціалістів

середній

високий

середній

Організація курсів підвищення кваліфікації, відтермінування строків тестування

6

Перевантаженість ЦБД

низький

низький

низький

Заведення задачі та розширення ресурсів

7

Версія білда не  функціонує коректно

високий

низький

високий

 Заведення дефекту з високим пріоритетом

8

Зміна членів команди автотестування та регрешн тестування

високий

середній

середній

Зсув строків імплементації тестів автоматизації

У випадку настання одного з перелічених ризиків - проінформувати проджект менеджера про неможливість завершення тестування. Та повторний аналіз пріоритетів задач

Зміст

9  Припущення

  • Не визначено користувачів для приймального тестування;
  • Модульні тести буде завершено до передачі на ручне тестування МА;
  • Не буде реалізовано автотестів для конкретного модулю аукціону;
  • Функціонал модулю аукціону не буде покрито на 100% автотестами.
Зміст
  • No labels