Данный план тестирования сформирован на примере программного продукта Oracle Hyperion Planning. После переноса системы на промышленную (опытно-промышленную) среду, необходимо убедиться в ее работоспособности, проверить, что все компоненты системы работают так, как ожидают пользователи, и обнаружить возможные несогласованности между частями системы с целью их устранения.

Тестирование системы должно удостоверить разработчиков и пользователей системы, что:

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

Границы технологического (системного) тестирования

Необходимо провести системное тестирования. Системный тест выполняется Исполнителем без участия Заказчика в процессе разработки компонентов системы. Тестирование программного обеспечения (ПО), выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование выполняется по методам чёрного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.

План тестирования системы содержит:

• на обобщенном уровне: что должно быть покрыто системными тестами, выполняемыми в конце разработки, и при проведении полного (приемочного) системного теста;
• на детальном уровне: какие сценарии должны быть выполнены в рамках тестов по завершении разработки и при проведении полного (приемочного) системного теста;
• два вида тестов системы, которые будут выполнены для автоматизированной системы бюджетирования. 

Виды тестов

Следующие тесты и элементы тестирования должны быть проведены в рамках системных и интеграционного тестов:

• Бизнес-функциональность: Системная последовательность выполнения процессов с использованием тестовых примеров
• Производительность: Использование интерфейса с использованием тестовых примеров
• Безопасность: Права доступа
• Преобразование и качество данных: Загрузка, выверка и ручной ввод данных

Характеристики, которые не тестируются, и ограничения

• Интерфейс пользователя: Инструменты Oracle EPM поставляются «как есть», изменение стандартного интерфейса не предусмотрено
• Возможность переноса приложения с одной платформы на другие с минимальными её переделками: Вне рамок проекта
• Эксплуатационная документация на систему: Рассматривается как отдельный результат по проекту и тестированию не подлежит
• Безопасность хранения данных: Для обеспечения безопасности хранения данных использованы стандартные средства Oracle RDBMS, Oracle EPM
• Конфиденциальность связи: Вне рамок проекта
• Возможность размещения системы в нескольких сегментах сети: Разработанная техническая архитектура системы предполагает размещение системы в одном сегменте сети

Подход

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

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

При разработке сценариев тестирования используются следующие предположения:

• подготовка сценариев тестирования выполняется участниками группы управленческой отчетности со стороны Заказчика исключительно на основании сценариев использования;
• в случае если для выполнения сценариев тестирования необходимо использовать реальные данные, имеющиеся в исходных системах, предоставление данных из исходных систем обеспечивает техническая группа со стороны Заказчика, загрузку предоставленных данных обеспечивает разработчик;
• в случае если для выполнения сценариев тестирования необходимо использовать реальные данные, отсутствующие в исходных системах, ручную подготовку данных выполняют участники группы подготовки управленческой отчетности со стороны Заказчика.

Критерии прохождения теста для элементов

Все замечания по результатам тестирования должны быть отнесены к одному из трех уровней:

1-я степень тяжести

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

Проблемы 1-й степени тяжести имеют одну или несколько следующих характеристик:

• потеря данных;
• наиболее важная функция недоступна;
• система “зависает” на неопределенный срок, что приводит к неприемлемым или непредсказуемым задержкам доступа к ресурсам или реагирования на команды;
• система прекращает работать и не работает после нескольких попыток перезапуска.

2-я степень тяжести

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

3-я степень тяжести

Проблема приводит к незначительной потере работоспособности, при этом существует временный обходной путь, приемлемый для пользователей. Последствием является неудобство, связанное с использованием такого временного обходного пути для восстановления функциональности.

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