Модель зрелости процессов разработки программного обеспечения
Шрифт:
7. Документы планов, процедур и сценариев тестирования должны быть управляемыми и контролируемыми.
«Управляемый и контролируемый» означает, что в любой момент времени (прошлый или настоящий) известна версия используемого промежуточного продукта, а внесение изменений происходит управляемым образом. Если желательно реализовать еще большую степень формальности, промежуточный продукт может быть помещен в условия полномасштабного управления конфигурацией, как это описано в группе ключевых процессов «Управление конфигурацией
8. При любых изменениях установленных требований, требований к ПО, архитектуры ПО или тестируемого кода соответствующие изменения должны вноситься в планы, процедуры и сценарии тестирования.
Операция 6. Планирование и выполнение интеграционного тестирования ПО проводится в соответствии с производственным процессом проекта.
1. Составляются и документируются планы интеграционного тестирования, основанные на плане разработки ПО.
2. Интеграционные сценарии и процедуры тестирования рассматриваются сотрудниками, ответственными за требования к ПО, архитектуру ПО, системное и приемочное тестирование.
3. Интеграционное тестирование ПО выполняется в соответствии с определенной версией документа требований к ПО и документа архитектуры ПО.
Операция 7. Планирование и выполнение системного и приемочного тестирования ПО в целях демонстрации его соответствия требованиям.
Системное тестирование позволяет убедиться в том, что созданный продукт удовлетворяет требованиям к ПО.
Приемочное тестирование проводится в целях демонстрации заказчику и конечным пользователям того, что ПО удовлетворяет установленным требованиям.
1. Ресурсы для тестирования ПО должны выделяться заранее, чтобы обеспечить соответствующую подготовку тестов.
Примеры работ по подготовке тестирования:
подготовка тестовой документации,
резервирование ресурсов для проведения тестирования,
разработка тестовых драйверов,
разработка симуляторов.
2. Системное и приемочное тестирование документируются в плане тестирования, который рассматривается и утверждается заказчиком и, при необходимости, конечными пользователями.
План тестирования раскрывает следующие вопросы:
общий подход к тестированию и проверке;
сферы ответственности разрабатывающей организации, субподрядчиков, заказчика и, при необходимости, конечных пользователей;
требования к испытательному оборудованию, оснащению и поддержке процесса тестирования;
критерии приемки.
3. Тестовые сценарии и процедуры планируются и готовятся группой тестирования, которая независима от разработчиков ПО.
4. Тестовые сценарии документируются, после чего рассматриваются и утверждаются заказчиком и, при необходимости, конечными пользователями до начала тестирования.
5. Тестирование выполняется для программной системы, находящейся в базовой линии, и на основе также находящихся в базовой линии установленных требований и требований к ПО.
6. Проблемы,
Основные практики, связанные с документированием и отслеживанием проблем, содержатся в описании Операции № 9 группы ключевых процессов «Отслеживание хода проекта и контроль над ним» и Операции № 5 группы ключевых процессов «Управление конфигурацией».
7. Результаты тестов документируются и используются для определения, насколько ПО соответствует выдвинутым к нему требованиям.
8. Документы результатов тестирования должны быть управляемыми и контролируемыми.
Операция 8. Документация, используемая при эксплуатации и поддержке ПО, разрабатывается и ведется в соответствии с производственным процессом проекта.
1. Для разработки документации используются соответствующие методы и инструменты.
Примеры методов и инструментов:
использование текстовых процессоров,
изучение сценариев,
повторное использование документации.
2. Специалисты по созданию документации принимают активное участие в планировании, разработке и ведении документации.
3. Предварительные версии документации разрабатываются на ранних стадиях жизненного цикла ПО и передаются на рассмотрение заказчику, конечным пользователям и, при необходимости, специалистам по поддержке ПО в целях получения отзывов.
Примеры документации: документация по обучению работе с системой, интерактивная документация, руководство пользователя, руководство оператора, руководство по сопровождению.
4. Окончательные версии документации сверяются с базовыми линиями ПО для приемочного тестирования.
5. Документация подвергается экспертной оценке. См. группу ключевых процессов «Экспертные оценки».
6. Документация должна быть управляемой и контролируемой.
7. Окончательная документация рассматривается и утверждается заказчиком, конечными пользователями, и при необходимости, специалистами по поддержке ПО.
Операция 9. Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта.
Примеры собираемых и анализируемых данных:
описание дефекта,
категория дефекта,
серьезность дефекта,
модули, содержащие дефект,
модули, подверженные влиянию дефекта,
операция, в которой проявился дефект,
экспертная оценка или тестовые сценарии, выявившие дефект,
описание сценария, при выполнении которого был выявлен дефект,
ожидаемые и фактические результаты, выявляющие дефект.
Операция 10. Поддержка согласованности всех промежуточных программных продуктов, включая планы разработки ПО, описания процессов, установленные требования, требования к ПО, архитектуру ПО, планы и процедуры тестирования.