• Нет

• Определение мотивационных факторов тестирования
• Согласование цели

• Нет

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

 Запросы на изменения также известны как CR, дефекты, ошибки, инциденты, запросы на расширения. Соответственно фиксация этих запросов и управление ними гарантирует, что изменения вносятся в систему под контролем, так что их влияние на систему предсказуемо. Ниже перечислены некоторые важнейшие типы Запросов на изменения:

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

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

Цель дефекта - сообщить сведения о неполадке, вызвав корректирующее действие, разрешение вопроса, и проследив происхождение неполадки. CR используется следующими сотрудниками:

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

Пример формы запроса на изменение

1. Идентификация

2. Текущая неполадка

3. Предлагаемое изменение (отправитель)

4. Предлагаемое изменение (группа просмотра изменений)

• Действие:
• Утверждено:
• Не утверждено:
• Отложено:
• Описание предлагаемого изменения:
• Затронутые элементы конфигурации:
• Категория:
• Исправление ошибки:
• Расширение:
• Новая функциональная возможность:

• Прочее:

5. Решение

6. Оценка

7. Размещение группы просмотра изменений

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

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

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

• Управление запросами изменений