Создание сценария

Операция: Создание заметок о выпуске

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

Операция: Развертывание продукта

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

Устранение дефекта

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

Операция: Воспроизведение дефекта

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

Операция: Определение причины возникновения дефекта

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

Операция: Переназначение дефекта

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

Операция: Выбор стратегии устранения дефекта

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

Операция: Изменение программы

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

Операция: Создание или изменение теста модуля

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

Операция: Выполнение теста модуля

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

Операция: Рефакторинг кода

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

Операция: Обзор кода

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

Операция: Интеграция изменений

Чтобы приложение было устойчивым и согласованным, необходимо организовать интеграцию изменений в код. Когда код состоит из небольших изменений, каждое из которых соответствует задаче по разработке или исправлению дефекта, его проще поддерживать в стабильном состоянии. Легче найти и изолировать потенциальную проблему. После интеграции последней задачи по разработке, ответственный за реализацию соответствующего сценария или требования к качеству, разработчик проверяет всю функциональность от начала до конца. Для состояния сценария или требования к качеству устанавливается значение Resolved (Обработан) и описатель назначается тестировщику.