Область охватываемых вопросов

Оглавление

Введение. 6

Назначение документа. 6

Объект тестирования. 6

Область охватываемых вопросов. 6

Дополнительные условия. 6

Требования к тестированию.. 7

Перечень активностей по проекту. 7

Допущения и ограничения. 7

Стратегия тестирования. 8

Функциональное тестирование. 8

Тестирование исправленных дефектов. 8

Регрессионное тестирование. 9

Инструментарий. 9

Структурирование разрабатываемой в рамках проекта информации. 11

Модель тестирования. 11

Классификация дефектов. 11

Схема взаимодействия при обработке дефекта. 12

Создаваемые документы.. 15

Еженедельный отчет. 15

Отчет о найденных дефектах. 15

Итоговый отчет по итерациям тестирования. 15

Календарный план проекта. 15

Ресурсы.. 16

Описание тестового контура. 16

Роли. 16

Приложение 1. 18

Приложение 2. 20

Приложение 3. 22

Приложение 4. 23

 

 

 

Введение

Цель данного документа – определить методологию тестирования, которая позволила бы минимизировать риски при внесении новой функциональноститестировании,уменьшить количество дефектов в уже существующей функциональности, а так же минимизировать риски при установке новой версии в продуктивную среду.

Назначение документа

Данный документ представляетс собой методику функционального тестирования продукта «Система фондирования сделок банка ОАО ВТБ» (программный продукт «FTPS»).

Документ преследует следующие цели:

· Описание объекта тестирования;

· Описание стратегии тестирования, ограничений и рисков;

· Описание видов тестирования, используемых для оценки качества тестируемого ПО;

· Описание подхода, позволяющего реализовать стратегию тестирования;

· Определение списка создаваемых документов;

Определение состава проектной команды.

·

Данный документ представляет собой методику функционального тестирования системы САРБ «Диасофт».

Документ преследует следующие цели:

Описать объект тестирования.

Описать стратегию тестирования, ограничения и риски.

Описать виды тестирования, используемые для оценки качества тестируемого ПО.

Описать подход, позволяющий реализовать стратегию тестирования.

Определить список создаваемых документов.

Определить состав проектной команды.

Объект тестирования

«Система фондирования сделок банка ОАО ВТБ» (ПП FTPS) –

САРБ «Диасофт» – система автоматизации финансовой деятельности,служит для работы с такими операциями и модулями, как:

· Прием данных изАС КС во входные таблицы FTPS;

· Запуск на обработку очередного сеанса приема входных данных;

· Проверка, коррекция и акцепт принятых данных по сделкам (сделок, заявок на фондирование, финансовых событий);

· Расчет финансовых результатов по обработанным сделкам;

· Настройка справочников ПП FTPS;

· Администрирование и аудит.

· Служебные операции.

· Модуль «Расчетно-кассовое обслуживание физических лиц».

· Модуль «Депозиты физических лиц».

· Модуль «Кредиты физических лиц».

· Модуль «Операции по банковским картам физических лиц».

· Взаимодействие с ИСУБД «Новая Афина».

· Взаимодействие с системой дистанционного банковского обслуживания «Интернет-банк».

Область охватываемых вопросов

Настоящий документ отражает все вопросы, связанные с проведением функционального тестирования «Системы фондирования сделок банка ОАО ВТБ» (ПП FTPS)системы САРБ «Диасофт».Стратегия тестирования, изложенная ниже в данном документе, описывает комплекс проектных решений и мер, которые необходимо предпринять для проведения тестирования системы САРБ «Диасофт».ПП FTPS.

Дополнительные условия

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

Требования к тестированию

На основе технического задания на разработку и анализа системы САРБ «Диасофт»ПП FTPSбыли составлены требования к тестированию, которые представлены в этом разделе.

Допущения и ограничения

Таблица 1. Ограничения проекта.

№	Описание ограничений проекта
1	Разработка тестовой модели проводится для 43 бизнес-процессов, список приведен в Приложении 1.
2	Объем тестовой модели не должен превышать 172 тестовых сценария.
3	Проведение не более двух итераций тестирования.

Стратегия тестирования

Для оценки качества системы ПП FTPSСАРБ «Диасофт»будут проведены следующие виды тестирования:

· Функциональное тестирование.

· Тестирование исправленныхиядефектовошибок.

· Регрессионное тестирование.

Функциональное тестирование

Таблица 2. Функциональное тестирование.

Цель:	Служит для оценки качества выполнения системой заявленных функций.
Способ:	Проверка работы при корректных и некорректных действиях: · Выполняется несколько корректных, с точки зрениядокументации, действий и ожидается их штатная обработка. · Выполняются некорректные действия, и ожидается корректная обработка ошибочной ситуации (например, ввод в поле значений неверных типов, отправка неправильных запросов). · Корректно применяются все бизнес-правила.
Критерий начала:	· Подготовлен тестовый стенд. · Установлена актуальная версия тестируемоговерсия  приложения, которую необходимо протестировать. · Установлены системы, с которыми требуется взаимодействие, и настроена интеграция между ними (при необходимости). · Созданы учетные записи для доступа к приложению участников команды тестирования.
Критерий завершенности:	· Все согласованные тест-кейсы выполнены. · Дефекты найденные в процессе тестирования зарегистрированы в базе дефектов.
Особые замечания:	Заказчика интересуют только положительные тесты.Нет

 

Регрессионное тестирование

Таблица 4. Регрессионное тестирование.

Цель:	Оценка качества проверенного ранее функционала системы с целью убедиться в том, что он не пострадал в результате внесения изменений (исправления дефектов), новой функциональности, нового оборудования, новых версий системного программного обеспечения и пр.
Способ:	Выполнениетест-кейсов, используя корректные и некорректные значения, сцельюпроверить, выполняются ли следующие условия: · При использовании корректных данных функциональность штатно отрабатывает и выдает ожидаемый результат. · При использовании некорректных данных, система выполняет корректную обработку ошибочной ситуации. · Корректно применяются все бизнес-правила.
Критерий начала:	· Подготовлен тестовый стенд. · Установлена актуальная версия тестируемого приложения, которую необходимо протестировать. · Установлены системы, с которыми требуется взаимодействие, и настроена интеграция между ними (при необходимости). · Созданы учетные записи для доступа к приложению участников команды тестирования.
Критерий завершенности:	· Все согласованные тест-кейсы выполнены. · Дефекты найденные в процессе тестирования зарегистрированы в базе дефектов.
Особые замечания:	Нет

Инструментарий

На проекте применяются следующие программные средства:

 

Таблица 5. Инструменты, используемыев проекте.

Назначение	Название	Версия
Методика тестирования	MS Word	2007
Тестовая модель	HP Quality CenterTestLink	1.9.311
Баг-трекинг	HP Quality CenterMantisBT	111.2.11
Отчетность	MS Word, HP Quality Center	112007
План проекта	MS Project	2010
Единое рабочее пространство (сетевая папка для хранения артефактов по проекту)	T:\Filials\Обмен\	Нет

 

 

Модель тестирования

Модель тестирования представляет собой совокупность тестовых требований, описывающих тестируемый функционал системы и связанных с ними тест-кейсов, описывающих действия, которые необходимо выполнить для проверки работоспособности функционала. Тест-кейсы группируются в тест сеты, объединенные по тестируемой функциональности.

 

Тестовые требования формируются на основании документации и общения с заказчиком исходя из тестовых требований:

· Составляются инструкции для проведения тестирования.

· Описываются тестовые объекты, начальные условия и действия, которые необходимо выполнить при прохождении тест-кейса.

· Параметры/условия влияющие на тест-кейс.

 

Организация тестовой модели

Тестоваямодель разделяетсяна следующие направления:

· Общие шаги;

· Импорт данных из КС;

· Сделки;

· Финансовые события.

 

· Служебные операции.

· Модуль «Расчетно-кассовое обслуживание».

· Модуль «Депозиты физических лиц».

· Модуль «Кредиты физических лиц».

· Модуль «Операции по банковским картам».

Классификация дефектов

Ниже представлена классификация дефектов по приоритету в системе баг-трекинга.

Таблица 6. Классификация дефектов.

Уровень критичности	Описание дефекта
5-Срочный1-Urgent	Ошибки при автономной работе прикладного программного обеспечения или при работе с прикладным программным обеспечением персонала. При этом работа производилась в соответствии с правилами, приведенными в эксплуатационной документации. Ошибки вызывают такой отказ прикладного программного обеспечения или такую потерю данных, которые не позволяют восстановить работоспособность программного или информационного обеспечения (данных), при этом затронуто более 50% всех пользователей системы.
4-Очень высокий2-Very High	Невозможность выполнения основных функций прикладного программного обеспечения в соответствии с документацией. Отсутствуют альтернативные варианты выполнения этих основных функций прикладного программного обеспечения, при этом затронуто более 50% всех пользователей системы.
3-Высокий3-High	Невозможность выполнения основных функций прикладного программного обеспечения, однако, существуют альтернативные варианты выполнения этих функций прикладного программного обеспечения, описанные в эксплуатационной документации.
2-Средний4-Medium	Невозможность выполнения вспомогательных функций прикладного программного обеспечения, однако существуют альтернативные варианты выполнения этих функций прикладного программного обеспечения, описанные в эксплуатационной документации.
1-Низкий5-Enchancement	Ошибка прикладного программного обеспечения, не влияющая на выполнение её функций, приведенных в эксплуатационной документации.

Создаваемые документы

Раздел описывает документы, которые будут создаваться в процессе и по результатам активностей на проекте.

Еженедельный отчет

Документ описывает выполненные за неделю задачи по проекту, не выполненные задачи с указанием блокирующих причин, а также планируемые задачи на следующую неделю. На стадии тестирования к нему прилагается отчет о найденных дефектах.

Шаблон отчета приведен в Приложении 2.

Ресурсы

В данном разделе представлены ресурсы, необходимые для проведения тестирования системы ПП FTPSСАРБ «Диасофт».

 

Описание тестовогоконтура

В таблице ниже приведено описание тестового контура, который используется для тестирования системыПП FTPS. САРБ «Диасофт».

Таблица 9. Описание тестового контура.

Тестовый контур Neptune
Задачи стенда	· Функциональное тестирование; · Регрессионное тестирование; · Тестирование исправленныхияошибокдефектов;
Версия ПО на стенде	Версия ПО, установленного на стенде соответствует версии, установленной на продуктивном стенде.
Период обновления данных	Перед началом тестирования новой версии

 

Роли

Роли на проекте распределяются следующим образом:

Таблица 10. Ресурсы проекта.

Роль	Сотрудник	Обязанности
Менеджер проекта	Шульга Николай	Обеспечение общего контроля активностей на проекте: · Техническое управление. · Выделение необходимых ресурсов. · Создание производственной отчетности.
Ведущий инженер по обеспечению качества (Ведущий тестировщик)	Величкин Андрей	Обеспечение контроля активностей по тестированию: · Разработка Плана тестирования и Стратегии тестирования. · РецензированиеТестовой модели и дефектов. · Распределение тестовых ресурсов. · Оценка трудозатрат и эффективности активностей по тестированию. · Создание тестовой отчетности.
Тест-дизайнер (Тестировщик)	Андреев Олег Козлова Юлия Поляков Алексей	Определение, создание и выполнение тестовых случаев: · Написание тест-кейсов. · Структуризация тест-кейсов в наборы. · Выполнение тест-кейсов. · Возвращение системы в исходное состояние (при необходимости). · Регистрация дефектов.

 

 

Приложение 1

Таблица 11. Список бизнес-процессов.

Приложение 2     Отчет о статусе проекта “Функциональное тестирование САРБ Диасофт”   Резюме для руководителей     Процентзавершения:             Результаты и майлстоуны   Майлстоуны WBS План Прогноз Факт Статус                                     Результаты WBS Planned Forecasted Actual Status                                       Приложение 3 Таблица 12. Пример отчета по обнаруженным дефектам. № Наименование модуля Подробное описание дефекта Статус Критичность Кем создан                                     Приложение 4 Введение Данный документ представляет собой отчет о результатах тестовых испытаний«Системы фондирования сделок ОАО Банк ВТБпатча7.2.29 системы автоматизации финансовой деятельности «Diasoft FA#»,разработанной компанией – «ЗАО Диасофт» (далее –«Поставщик»).Все тестовые испытания проводились в соответствии с методикой тестирования,которая была создана и согласована в рамках текущего проекта.   Цель проведения испытаний Целью проведения испытаний являлось: 1. Проверка соответствия системы «Diasoft FA#» требованиям, изложенным в предоставленной документации. 2. Подтвердить, что за время, прошедшее с момента выполнения испытаний системы «Diasoft FA#», выявленные дефекты и несоответствия были устранены Поставщиком. 3. Формирование данных для принятия решения о готовности системы «Diasoft FA#» к эксплуатации. Перечень и объем выполняемых действий для установления соответствия системы «Diasoft FA#» требованиям проверок приведен в методике тестирования.   Сведения о ходе испытаний В данном разделе содержится: · список разработанных тест-кейсов; · результат выполнения тест-кейсов в ходе испытаний; · общая статистика в виде диаграммы, с разбиением по результатам прохождения тест-кейсов;     Таблица 1. Тест-кейсы, пройденные в ходе 1-ой итерации тестирования. Номер проверки Содержание проверки Результат Замечания и рекомендации № Описание Положительно/отрицательно Описание, если есть замечания     Таблица 2. Тест-кейсы, пройденные в ходе 2-ой итерации тестирования. Номер проверки Содержание проверки Результат Замечания и рекомендации № Описание Положительно/отрицательно Описание, если есть замечания   В ходе проведения испытаний были обнаружены критичные дефекты, которые устранялись специалистами Поставщика, полный список приведен в Приложении 1. Таким образом, изменения, внесенные специалистами Поставщика с целью устранения критичных дефектов, необходимо учесть при подготовке последующих версий дистрибутива «Diasoft FA#».   Приложение 1 Оглавление Введение. 6 Назначение документа. 6 Объект тестирования. 6 Область охватываемых вопросов. 6 Дополнительные условия. 6 Требования к тестированию.. 7 Перечень активностей по проекту. 7 Допущения и ограничения. 7 Стратегия тестирования. 8 Функциональное тестирование. 8 Тестирование исправленных дефектов. 8 Регрессионное тестирование. 9 Инструментарий. 9 Структурирование разрабатываемой в рамках проекта информации. 11 Модель тестирования. 11 Классификация дефектов. 11 Схема взаимодействия при обработке дефекта. 12 Создаваемые документы.. 15 Еженедельный отчет. 15 Отчет о найденных дефектах. 15 Итоговый отчет по итерациям тестирования. 15 Календарный план проекта. 15 Ресурсы.. 16 Описание тестового контура. 16 Роли. 16 Приложение 1. 18 Приложение 2. 20 Приложение 3. 22 Приложение 4. 23       Введение Цель данного документа – определить методологию тестирования, которая позволила бы минимизировать риски при внесении новой функциональноститестировании,уменьшить количество дефектов в уже существующей функциональности, а так же минимизировать риски при установке новой версии в продуктивную среду. Назначение документа Данный документ представляетс собой методику функционального тестирования продукта «Система фондирования сделок банка ОАО ВТБ» (программный продукт «FTPS»). Документ преследует следующие цели: · Описание объекта тестирования; · Описание стратегии тестирования, ограничений и рисков; · Описание видов тестирования, используемых для оценки качества тестируемого ПО; · Описание подхода, позволяющего реализовать стратегию тестирования; · Определение списка создаваемых документов; Определение состава проектной команды. · Данный документ представляет собой методику функционального тестирования системы САРБ «Диасофт». Документ преследует следующие цели: Описать объект тестирования. Описать стратегию тестирования, ограничения и риски. Описать виды тестирования, используемые для оценки качества тестируемого ПО. Описать подход, позволяющий реализовать стратегию тестирования. Определить список создаваемых документов. Определить состав проектной команды. Объект тестирования «Система фондирования сделок банка ОАО ВТБ» (ПП FTPS) – САРБ «Диасофт» – система автоматизации финансовой деятельности,служит для работы с такими операциями и модулями, как: · Прием данных изАС КС во входные таблицы FTPS; · Запуск на обработку очередного сеанса приема входных данных; · Проверка, коррекция и акцепт принятых данных по сделкам (сделок, заявок на фондирование, финансовых событий); · Расчет финансовых результатов по обработанным сделкам; · Настройка справочников ПП FTPS; · Администрирование и аудит. · Служебные операции. · Модуль «Расчетно-кассовое обслуживание физических лиц». · Модуль «Депозиты физических лиц». · Модуль «Кредиты физических лиц». · Модуль «Операции по банковским картам физических лиц». · Взаимодействие с ИСУБД «Новая Афина». · Взаимодействие с системой дистанционного банковского обслуживания «Интернет-банк». Область охватываемых вопросов Настоящий документ отражает все вопросы, связанные с проведением функционального тестирования «Системы фондирования сделок банка ОАО ВТБ» (ПП FTPS)системы САРБ «Диасофт».Стратегия тестирования, изложенная ниже в данном документе, описывает комплекс проектных решений и мер, которые необходимо предпринять для проведения тестирования системы САРБ «Диасофт».ПП FTPS. Дополнительные условия Несмотря на то, что проект специально не подразумевает каких-либо иных видов тестирования, кроме тех, которые указаны ниже, ошибки, прямо не связанные с целью тестирования, но обнаруженные при прохождении тест-кейсов, должны регистрироваться и передаваться заказчику. Требования к тестированию На основе технического задания на разработку и анализа системы САРБ «Диасофт»ПП FTPSбыли составлены требования к тестированию, которые представлены в этом разделе.