Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

В основе RUP лежат следующие принципы:

· Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

· Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение моделипрецедентов (вариантов использования)).

· Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

· Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

· Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

· Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

 

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

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

Начальная стадия (Inception)

В фазе начальной стадии:

· Формируются видение и границы проекта.

· Создается экономическое обоснование (business case).

· Определяются основные требования, ограничения и ключевая функциональность продукта.

· Создается базовая версия модели прецедентов.

· Оцениваются риски.

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

· Документирование требований (включая детальное описание для большинства прецедентов).

· Спроектированную, реализованную и оттестированную исполняемую архитектуру.

· Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

· Сниженные основные риски.

Успешное выполнение фазы разработки означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone).

Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

 

 

Мониторинг процеса тестирования.

Мониторинг и контроль

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

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

 Какие метрики обычно используются для контроля процесса тестирования

 Как составить матрицу отслеживаемости (Traceability Matrix)

Метрики контроля процесса тестирования

Метрики по обеспечению качества

Согласно международному стандарту ISO 14598:

Метрика - это количественный масштаб и метод, который может использоваться для измерения.

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

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

Создание, использование и анализ метрик

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

1. Метрики по тестовым случаям (Test Cases)

2. Метрики по багам / дефектам

3. Метрики по задачам

Давайте более детально разберем каждую из них:

Метрики по тест кейсам

Название	Описание
Passed/Failed Test Cases	Метрика показывает результаты прохождения тест кейсов, а именно отношение количества удачно пройденных к завершившимся с ошибками. В идеале, к концу проекта, количество провальных тестов стремиться к нулю
Not Run Test Cases	Метрика показывает количество тест кейсов, которые еще необходимо выполнить в данной фазе тестирования. Имея данную информацию, мы можем проанализировать и выявить причины, по которым тест не были проведены

 

Метрики по багам

Название	Описание
Open/Closed Bugs	Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
Reopened/Closed Bugs	Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
Rejected/Opened Bugs	Метрика показывает отношение количества отклоненных багов к открытым
Bugs by Severity	Количество багов по серьезности
Bugs by Priority	Количество багов по приоритету

 

Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов, после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

1. Требования к функции можно трактовать по разному

2. Тестировщик не точно описал проблему

3. Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

1. Требования к функции можно трактовать по разному

2. Тестировщик не точно описал проблему

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

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

Метрики по задачам

Название	Описание
Deployment tasks	Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow). В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks	Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое

 

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

* * *

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

Отчеты о тестировании.