Тестовые работы (Test Activities)
Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, что успешное управление тестовыми работами сильно зависит от процессов конфигурационного управления (Software Configuration Management), рассматриваемых позднее как самостоятельная область знаний.
5.2.1 Планирование (Planning)
Также как и другие аспекты управления проектами, работы по тестированию должно планироваться заранее. Как минимум, на уровне организации соответствующего процесса. Ключевые аспекты планирования тестовой деятельности включают:
- координацию персонала
- управление оборудованием и другими средствами, необходимыми для организации тестирования
- планирование обработки нежелательных результатов (т.е. является управлением определенными видами рисков)
В случае одновременной поддержки и сопровождения нескольких версий программной системы или нескольких систем, необходимо уделять особое внимание планированию времени, усилий и ресурсов, связанных с проведением работ по тестированию. Данная позиция перекликается с вопросами управления портфелями проектов с точки зрения общего управления проектами.
5.2.2 Генерация сценариев тестирования (Test-case generation)
Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования. Тесты должны находиться под управлением системы конфигурационного управления и описывать ожидаемые результаты тестирования.
5.2.3 Разработка тестового окружения (Test environment development)
Используемое для тестирования окружение должно быть совместимо с инструментами программной инженерии (будут рассматриваться позднее как тема самостоятельной области знаний). Это окружение должно обеспечивать разработку и контроль тестовых сценариев, ведение журнала тестирования, и возможности восстановления ожидаемых и отслеживаемых результатов тестирования, самих сценариев, а также других активов тестирования.
5.2.4 Выполнение тестов (Execution)
Выполнение тестов должно содержать основные принципы ведения научного эксперимента:
- должны фиксироваться все работы и результаты процесса тестирования
- форма журналирования таких работ и их результатов должна быть такой, чтобы соответствующее содержание было понятно, однозначно интрепретируемой и повторяемо другими лицами (не теми, кто первоначально проводил тестирование)
- тестирование должно проводиться в соответствии с заданными и документированными процедурами
- тестирование должно производиться над однозначно идентифицируемой версией и конфигурацией программной системы
Ряд вопросов выполнения тестов и других работ по тестированию освещен в стандарте IEEE 1008-87.
5.2.5 Анализ результатов тестирования (Test results evaluation)
Для определения успешности тестов их результаты должны оцениваться, анализироваться. В большинстве случаев, “успешность” тестирования подразумевает, что тестируемое программное обеспечение функционирует так, как ожидалось и в процессе работы не приводит к непредусмотренным последствиям. Не все такие последствия обязательно являются сбоями, они могут восприниматься как “помехи”. Однако, любое непредусмотренное поведение может стать источником сбоев при изменении конфигурации или условий функционирования системы, поэтому требуют внимания, как минимум, с точки зрения идентификации причин таких помех. Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те усилия, которые необходимы для анализа проблемы, отладки и устранения. Это позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно, в перспективе, иметь возможность улучшения самого процесса тестирования. В тех случаях, когда результаты тестирования особенно важны, например, в силу критичности обнаруженного сбоя, может быть сформирована специальная группа анализа (review board).
5.2.6 Отчёты о проблемах/журнал тестирования (Problem reporting/Test log)
Во многих случаях, в процессе тестовой деятельности ведётся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой конфигурации программной системы (в терминах параметров и в терминах идентифицируемой версии контекста конфигурационного управления) и т.п. Неожиданные или некорректные результаты тестов могут записываться в специальной подсистеме ведения отчетности по сбоям (problem-reporting system, обеспечивая формирование базы данных, используемой для отладки, устранения проблем и дальнейшего тестирования. Кроме того, аномалии (помехи), которые нельзя идентифицировать как сбои, также могут фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом случае, документирование таких аномалий снижает риски процесса тестирования и помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты по тестам могут являться входом для процесса управления изменениями и генерации запросов на изменения (change request) в рамках процессов конфигурационного управления (см. далее соответствующую область знаний “Software Configuration Management”).
5.2.7 Отслеживание дефектов (Defect tracking)
Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками, присутствующими в тестируемой программной системе (также они могут быть следствием поведения операционного и/или тестового окружения). Такие дефекты могут (и, чаще всего, должны) анализироваться для определения момента и места первого появления данного дефекта в системе, какие типы ошибок стали причиной этих дефектов (например, плохо сформулированные требования, некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены впервые. Вся эта информация используется для определения того, как может быть улучшен сам процесс тестирования и насколько критична необходимость таких улучшений.
5. Сопровождение программного обеспечения
(Software Maintenance по SWEBOK)
Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK.
Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с замечаниями и комментариями.
Сопровождение программного обеспечения (Software Maintenance)
1. Основы сопровождения программного обеспечения (Software Maintenance Fundamentals)
1.1 Определения и терминология (Definitions and Terminology)
1.2 Природа сопровождения (Nature of Maintenance)
1.3 Потребность в сопровождении (Need for Maintenance)
1.4 Приоритет стоимости сопровождения (Majority of Maintenance Costs)
1.5 Эволюция программного обеспечения (Evolution of Software)
1.6 Категории сопровождения (Categories of Maintenance)
2. Ключевые вопросы сопровождения программного обеспечения (Key Issues in Software Maintenance)
2.1 Технические вопросы (Technical Issues)
2.2 Управленческие вопросы (Management Issues)
2.3 Оценка стоимости сопровождения (Maintenance Cost Estimation)
2.4 Измерения в сопровождении программного обеспечения (Software Maintenance Measurement)
3. Процесс сопровождения (Maintenance Process)
3.1 Процессы сопровождения (Maintenance Processes)
3.2 Работы по сопровождению (Maintenance Activities)
4. Техники сопровождения (Techniques for Maintenance)
4.1 Понимание программных систем (Program Comprehension)
4.2 Реинжиниринг* (Reengineering)
4.3 Обратный инжиниринг* (Reverse engineering)
Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. Соответственно, в процессе эксплуатации продукт будет изменяться или эволюционировать. Связано это с обнаружением при реальном использовании скрытых дефектов, изменениями в операционном окружении, необходимостью покрытия новых требований и т.п.
Фаза сопровождения в жизненном цикле, обычно, начинается сразу после приемки/передачи продукта и действует в течение периода гарантии или, чаще, технической поддержки. Однако, сама деятельность, связанная с сопровождением, начинается намного раньше.
Сопровождение программного обеспечения является составной частью жизненного цикла. К сожалению, так сложилось, что вопросам сопровождения уделяется существенно меньше внимания, чем другим фазам жизненного цикла. Исторически, в большинстве организаций, разработка программных систем явно в фаворе, по сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний ITIL* – IT Infrastructure Library, уделяющей особое внимание вопросам поддержки и сопровождения инфраструктуры информационных технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций организаций непосредственно в разработку программных систем, с целью увеличения сроков использования уже существующего и применяемого ПО. Конечно, с точки зрения автора, это не единственная причина. Скорее вопросы постоянно изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения программного обеспечения и естественной интеграции такой деятельности в бизнес-процессы подразделений информационных технологий.
* ITIL, в частности, определяет три аспекта управления жизненным циклом приложений – определение требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте программного обеспечения, относится к деятельности по управлению приложениями – Application Management в ITIL ICT Infrastructure Management (ICT - Information and Communications Technology).
Если проблема 2000 года, в свое время, оказала особое влияние на изменение отношения к сопровождению на Западе, то расширение применения продуктов Open Source во всем мире и связанная с ним волна надежд на получение дешевого решения существующих задач привела к тому, что вопросы сопровождения вышли для многих организаций на первый план. Ситуация во многих ИТ-подразделениях показывает, что такие надежды оправдались только частично. Использование продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело даже к бОльшим проектным затратам именно в силу недостаточно проработанной политики эксплуатации и сопровождения построенных на их основе прикладных решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. Это означает только, что игнорирование оценки стоимости сопровождения привело к превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу инициатив по использованию таких продуктов в корпоративной среде. Неготовность рассматривать жизненный цикл во времени как продолжающийся и после передачи системы в эксплуатацию, непроработанность соответствующих процедур корректировки продукта после его выпуска – основная беда и в бизнесе-среде, для которой программное обеспечение лишь инструмент, и в компаниях-интеграторах, “забывающих” о необходимости развития успеха после внедрения системы у заказчика, и у независимых поставщиков программных продуктов, которые, выпуская новую версию лучшего в своем классе продукта, начинают работать над новой версией, уделяя недостаточное внимание поддержке и обновлению уже существующих версий.
Сопровождение программного обеспечения в SWEBOK определяется как вся совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после этого. Предварительные работы включают планирование деятельности по сопровождению системы, а также организацию перехода к ее полнофункциональному использованию. Если новая система должна заменить старую систему, предназначенную для решения тех же задач, просто на новом уровне эффективности, стоимости использования, новых функциональных возможностей, в этом случае важно обеспечить плавный переход со старой системы на новую, максимально естественный для пользователей. С этим связано не только планирование, например, переноса информации, хранимой в соответствующих базах данных, но и обучение пользователей, подготовка, настройка и проверка “боевой” конфигурации, определение последовательности операций, организация и обучение службы поддержки (help-desk) и т.п.
Область знаний “Сопровождение программного обеспечения” связана с другими аспектами программной инженерии. По-сути, описание этой области знаний непосредственно пересекается со всеми другими дисциплинами.
Рисунок 6. Область знаний “Сопровождение программного обеспечения” [SWEBOK, 2004, с.6-2, рис. 1]