В сценариях формулируются функциональные задачи системы. Для определения этих задач внимательно изучите все потребности собирательных образов системы. Эти задачи могут быть сначала просто выписаны в виде списка, а позднее описаны в виде сценариев. Старайтесь не допускать сценариев, описывающих неудачные или неоптимальные пути поставленных задач. Сценарии могут создаваться во время "мозгового штурма", при помощи моментальных снимков или пробных тестов. Все они добавляются в список сценариев. Когда сценарии назначаются на следующую итерацию, они документируются и им присваиваются приоритеты. Создание сценариев заканчивается, когда составлен график реализации всех сценариев в итерациях, либо после создания архитектурного прототипа.
| Работа над сценариями методом "мозгового штурма" | Определите задачи системы |
|---|---|
| Создание моментальных снимков деятельности | Выясните типичные способы использования системы |
| Определение приоритетов в списке сценариев | Определите приоритеты для каждого сценария |
| Создание описания сценария | Выберите подходящий обобщенный образ |
| Раскадровка сценария | Подберите инструмент для раскадровки |
Первоначально список сценариев состоит из элементов сценариев. Их используют для определения целей приложения. Элемент сценария состоит из имени и краткого описания, определяющего уникальность элемента. Элементы становятся описателями после синхронизации сценариев. Проведите коллективное обсуждение и добавьте сценарии в список сценариев, проанализируйте задачи приложения и то, как оно будет использоваться каждым собирательным образом. Исходный список сценариев создается в первой итерации, а затем каждый раз, когда меняются требования или выявляются новые, список сценариев следует пересматривать и корректировать.
| Определение задач системы | В папке требований Проводника команды откройте список сценариев. Список сценариев связан с проектом. Импортируйте все сценарии, созданные при помощи Проводника команды |
|---|---|
| Формулировка сценариев | Выберите цель и рассмотрите разные способы, которыми собирательный образ может достичь ее или потерпеть в этом неудачу. Для способа, которым собирательный образ пытается достичь цели, выберите описательное имя. Затем добавьте элемент сценария с этим именем в список сценариев. При определении концепции проекта следует убедиться, что представление о будущем приложения охватывает все сценарии. При изменении представления следует корректировать концепцию |
При определении приоритета сценария в списке в расчет принимаются как его значимость для пользователей, так и для приложения в целом. Приоритеты определяют очередность реализации сценариев. Сам процесс определения приоритетов помогает выявить наиболее важные и ценные сценарии, которые будут реализованы в ближайшей итерации.
| Определение общего приоритета | Каждому сценарию в списке назначьте общий приоритет. В поле приоритета списка сценариев впишите соответствующее числовое значение |
|---|---|
| Описание приоритетных сценариев | Используя шаблон описания сценария, контурно обрисуйте наиболее приоритетные сценарии, снабдив их кратким описанием, но, в то же время, достаточно подробным, чтобы разработчики на его основании смогли сделать оценки |
| Передача запросов для выполнения оценок | Пошлите менеджеру проекта и разработчикам запрос на выполнение общих оценок для самых |
| Разбиение требований или изменение приоритетов | Если цена какого-либо сценария превышает бюджет итерации, попробуйте разбить это требование |
Описание сценария из списка пишется в процессе создания начального плана итерации, т. е. когда она становится кандидатом на реализацию в ближайшем сценарии. Уровень детализации должен быть достаточным для передачи потребностей собирательного образа разработчикам и для создания контрольных примеров. Большие сценарии могут быть разбиты на более мелкие, укладывающиеся в рамки одной итерации. После создания описания оно публикуется на портале проекта, а будущим разработчикам и тестировщикам рассылаются сообщения, чтобы они просмотрели их.
| Выбор подходящего собирательного образа | Из списка сценариев выберите сценарий, вошедший в ближайшую итерацию или важный с точки зрения архитектуры. Откройте шаблон описания сценария в Microsoft Word и сохраните документ, дав ему имя сценария, чтобы отличать его от остальных, уже написанных сценариев |
|---|---|
| Формулировка описания сценария | Пишите сценарий в разделе описания соответствующего документа. С самого начала описывайте каждое действие, выполняемое собирательным образом в процессе достижения поставленной цели. Действия, уже описанные в других сценариях, записывайте схематично, а в тех местах, где сценарий отличается от остальных, будьте наиболее подробны |
| Разбиение сценариев | Если детальная оценка (составленная как сумма задач разработки) превышает длину итерации, то такой сценарий является кандидатом на разбиение. Получившиеся в результате разбиения подсценарии в сумме должны соответствовать исходному сценарию. Для каждого нового сценария следует определить характерные отличия от других. На основе шаблона сценария создайте хотя бы два документа, описывающие сценарии |
Раскадровка улучшает сценарий и снабжает его информацией о пользовательском интерфейсе. Она исключительно полезна, когда пользовательский интерфейс играет важную роль в удовлетворении потребностей внешних пользователей. Раскадровка также помогает подогнать проект под требования разных организаций. Она может включать различные графические элементы, такие как снимки экранов, макеты приложений,
| Выбор сценариев | Отберите сценарии, требующие раскадровки |
|---|---|
| Создание снимков экрана | Для раскадровки хорошо подходят такие инструменты, как Microsoft Visio и Microsoft PowerPoint. Создайте экраны, которые должен видеть собирательный персонаж. Схематично нарисуйте пользовательский интерфейс, требуемый сценарием. Совместно с командой разработчиков убедитесь, что полученный пользовательский интерфейс не противоречит выбранной метафоре |
| Создание | Прямоугольниками изображайте экраны, а стрелками - их последовательность |
Ведение проекта - это постоянный мониторинг и документирование его состояния. Чтобы обеспечить постоянный контроль над проектом, допускается внесение необходимых изменений. Необходимо отслеживать как ход проекта в целом, так и выполнение отдельных итераций. Надо своевременно выявить дефекты, определить риски и присвоить им приоритеты.
| Обзор целей | Установите минимальный приемлемый уровень |
|---|---|
| Оценка хода выполнения | Поддерживайте график проекта в актуальном состоянии |
| Оценка пороговых значений показателей тестов | Проанализируйте отчеты о выполненных тестах |
| Классификация дефектов | Создайте список дефектов, подлежащих классификации |
| Определение риска | Определите требования к качеству, связанные с большими рисками |
Для успешной реализации проекта важно отслеживать и оценивать ход его выполнения. Правильное планирование и управление проектом зависит от возможности оценивать его текущее состояние. Кроме того, надо отслеживать организационные, технические и проектные риски. Проект можно привязать ко времени или к реализуемому функционалу. В привязанных ко времени проектах крайние сроки зачастую определяются событиями на рынке, положением конкурентов, существующими нормами, финансовыми факторами и другими причинами, связанными с бизнесом. Даже проекты с фиксированным функционалом могут иметь желательную дату реализации. В проектах, не фиксированных по времени, правильный прогноз даты завершения благотворно скажется на уровне продаж, маркетинговых показателях, на внедрении, обучении и эксплуатационных факторах.
| Оценка списка обязательных работ | Если есть предполагаемая дата реализации проекта, определите число необходимых итераций на основании длительности начальной итерации. Используйте данные из отчета об общем темпе проекта ( |
|---|---|
| Проверка зависимостей | Проверьте зависимости в графике и убедитесь, что они соблюдаются |
| | При необходимости оцените число итераций, необходимых для реализации планируемых функций, и определите, соответствует ли ход работ целям, определенным в концепции проекта |
В документе с описанием подходов к тестированию указаны пороговые значения для показателей тестов. Необходимо периодически анализировать продвижение проекта в соответствии с этими показателями и при необходимости их корректировать.
| Анализ отчетов о выполненных тестах | Отчеты о выполненных тестах помогут понять текущее положение дел, если сравнить результаты с пороговыми значениями |
|---|---|
| Определение задач и рисков тестирования | Совместно со специалистами по тестированию создайте и распределите задачи тестирования |
Своевременно необнаруженный и неконтролируемый риск может отрицательно сказаться на выполнении проекта. Риски имеют место в различных областях. Например, в одном проекте риск может быть связан с эргономикой, поскольку эта область принципиально важна для заказчика, а в другом проекте риски могут быть связаны с производительностью. Важно четко определить и учесть наиболее опасные риски в первых же итерациях проекта. По мере появления дополнительных сведений о сценариях и требованиях к качеству в каждой последующей итерации уделите время поиску новых возможных рисков.
| Определение требований к качеству, связанных с риском | Проанализируйте требования к эргономике. Определите, является ли интерфейс пользователя ключевым фактором оценки приложения заказчиком |
|---|---|
| Проверка сценариев | Проанализируйте сценарии на предмет потенциальных рисков |
| Вопросы интеграции | Если в рассмотренных областях обнаружены угрозы для успешной реализации проекта, создайте описатель риска. Сформулируйте потенциальные проблемы, связанные с данным риском, и задокументируйте их в описателе |
| Формулирование рисков и расстановка их приоритетов | Какие библиотеки сторонних поставщиков могут использоваться приложением? Проверены ли они? Если нет, выявите неизвестные характеристики библиотек, которые необходимо проверить |
После всех итераций, кроме нулевой, продукт должен быть в стабильном состоянии и готовым к поставке. Установите показатель минимального приемлемого уровня ( minimum acceptance level ), чтобы в дальнейшем сравнивать реализованные сценарии и требования к качеству с этим уровнем. Минимальный приемлемый уровень должен постоянно переоцениваться с учетом изменений потребностей заказчика, состояния рынка и т. д. Минимальный приемлемый уровень обновляется после каждой итерации.
| Установка минимального приемлемого уровня | Оцените ожидания, которые связывают с разрабатываемым продуктом заказчики, и рынок в целом. Примите в расчет конкурентов, существующие аналоги и потребности бизнеса |
|---|---|
| Отчет о текущем состоянии | Сформируйте отчет об оставшихся работах для оценки хода выполнения проекта |
Классификация ( triage ) - процесс анализа вновь обнаруженных или заново обрабатываемых дефектов, назначения им приоритетов и привязки к определенным итерациям. Классификацию проводит менеджер проекта с участием других участников проектной группы.
| Создание отчета о дефектах | Выдайте запрос системе отслеживания дефектов о вновь обнаруженных и заново обрабатываемых дефектах |
|---|---|
| Анализ дефектов | Ознакомьтесь с каждым обнаруженным дефектом, привлекая разработчиков, тестировщиков и менеджера проекта. Определите важность исправления каждого из них до конца проекта и текущей итерации |
| Присвоение приоритета и привязка к итерации | Каждому дефекту присвойте приоритет и определите, в какой итерации его необходимо исправить, чтобы его обработку можно было учесть в графике проекта |
| Воспроизведение непонятных дефектов | Если отчет о дефекте невразумителен или нет уверенности в истинном действии дефекта, группа управления программой должна попробовать воссоздать дефект, чтобы лучше понять его реальное влияние и возможности повторного появления |
В процессе сборки создается единый продукт, включающий существующий код и все новые пакеты изменений. Однако вносимые изменения должны быть корректны. Пакет изменений должен быть скомпилирован и должны быть выполнены компоновочные тесты. Добавляемый пакет изменений не должен провоцировать проблемы - проверка этого факта является частью процесса приемки сборки. К каждой сборке прилагается набор комментариев, поясняющих вносимые изменения.
| Запуск сборки | Минимизируйте зависимости |
|---|---|
| Проверка сборки | Проверьте основные функции |
| Исправление сборки | Выделите ошибки компиляции |
| Приемка сборки | Протестируйте сборку |
Чтобы гарантировать целостность, запускайте сборку продукта всякий раз, когда требуется включить в него изменения. Это помогает синхронизировать изменения и предоставляет всем разработчикам рабочую платформу. Чтобы ускорить слишком медленную сборку, пересмотрите зависимости.
| Минимизируйте зависимости | Чем меньше в приложении зависимостей, тем быстрей происходит его сборка |
|---|---|
| Начало сборки | Запускайте сборку всякий раз, когда можно интегрировать изменения. Создавайте "чистую" сборку только в случае абсолютной необходимости. "Чистые" сборки делаются по ночам. Если процесс сборки не выполняется без предварительной "чистой" сборки, проверьте зависимости |
Необходимо поддерживать качество приложения при внесении любого изменения. Проводите проверочные испытания, демонстрирующие, что базовая функциональность сборки не затронута. Проверочные испытания также проводятся для проверки изменений, сделанных в процессе исправления дефекта и для контроля работоспособности вновь добавленных функций.
| Проверка основных функций | Выполните минимальное подмножество тестов, в частности, проверочный тест сборки, иногда называемый "дымовым", чтобы убедиться в стабильности базовой функциональности системы |
|---|---|
| Проверка измененных функций | Запустите дополнительные тесты и убедитесь, что все запланированные пакеты изменений добавлены и изменения корректны |
| Информирование участников о готовности сборки | Если все тесты прошли, проинформируйте все заинтересованные стороны, что сборка допущена к работе |
В процессе проверочных испытаний может возникнуть ситуация, когда исходный код не компилируется на сборочной машине или внешние компоненты не работают корректно. Чтобы исправить сборку, выявите ошибки периода компиляции и выполнения и проинформируйте разработчиков, ответственных за соответствующие компоненты. Задержки в решении проблем со сборкой тормозят выполнение других работ, например тестирования.
| Выделение ошибок компиляции | Перед компиляцией запустите сценарий, очищающий используемые при сборке каталоги от ненужных файлов. Компиляция исходного кода и построение компонентов на сборочной машине может не проходить, хотя та же процедура нормально проходила на машине разработчика |
|---|---|
| Обработка ошибок периода выполнения | Фиксируйте все ошибки периода выполнения и информируйте о них разработчика - напрямую и посредством описателя дефекта |
| Проверка содержимого | Сравните содержимое сборки с указанным в спецификации: нет ли лишних файлов и не пропущены ли нужные |
| Проверка установочных сценариев и исполняемых файлов | Просмотрите установочные сценарии и проверьте, расположены ли необходимые файлы в каталогах, указанных в спецификации и сценариях |
| Проверка версий связанных модулей | Проверьте версии используемых при компоновке внешних модулей, например библиотек сторонних поставщиков. Использование некорректных версий может привести к непредсказуемому |
| Исправление и перекомпоновка сборки | После решения проблемы нужно сразу заново создать сборку, чтобы не блокировать работу других участников проекта |
Когда сборка допускается к работе, это говорит о том, что реализованы некоторые минимальные требования и сборка готова к дальнейшей эксплуатации. Для приемки сборки убедитесь в том, что компиляция и компоновка проходят без сбоев, а проверочные тесты покрывают всю базовую функциональность. Добавьте к сборочным тестам проверки, сделанные в последней итерации.
| Поддержка сборочных тестов | Добавляйте или удаляйте разделы сборочных тестов, чтобы они обеспечивали адекватную проверку сборок |
|---|---|
| Наблюдение за сборкой | Регулярно просматривайте отчеты о деталях сборки |
В определенный момент набор реализованных функций становится достаточным для выпуска продукта. Существует несколько типов выпусков: альфа-, бета-версия и окончательная версия или доработанный выпуск. Этот выпуск окажет большее воздействие, чем сама команда, которая его создавала, о нем будут судить пользователи. Для программных продуктов, созданных для внешних потребителей, необходимы маркетинговые и торговые мероприятия. Системы, созданные для внутреннего применения, требуют организации обучения и поддержки эксплуатации. Чтобы заранее начать готовить соответствующих людей, составляется план выпуска. Процесс выпуска и связанный с ним план во многом зависит от типа продукта и способа его применения.
| Исполнение плана выпуска | Проверьте правильность материала |
|---|---|
| Проверка выпуска | Создайте свой раздел для выпуска |
| Заметки о выпуске | Задокументируйте выявленные ограничения |
| Развертывание продукта | Создайте установочный комплект |
В плане выпуска упоминаются все заинтересованные в получении нового выпуска. Этот план позволяет подготовиться к выпуску продукта изготовителей носителей, заказчиков и группу эксплуатации. План позволяет также проинформировать лиц, ответственных за последующую работу с продуктом, о том, когда они смогут его получить и на какую техническую поддержку вправе рассчитывать.
| Проверка материалов, связанных с выпуском | Проверьте, что материалы, относящиеся к маркетингу, торговле, обучению и приемке заказчиком, соответствуют составу продукта |
|---|---|
| Координация поставки продукта | Обеспечьте поставку или развертывание продукта |
Когда выполнены изложенные в концепции и в описании подхода к тестированию требования к функциям, качеству и срокам, можно рассматривать возможность выпуска продукта (в том числе альфа- или бета-версий). Чтобы сборка стала официальным выпуском, надо подвергнуть ее окончательному
| Создание своего раздела для выпуска | Выделите в иерархии проекта свой раздел для кандидата на выпуск. Это защитит код и позволит вносить только выбранные изменения |
|---|---|
| Выполнение регрессионных тестов | Выполните для кандидата на выпуск полный регрессионный тест |
| Документирование дефекта | Если тест не проходит, необходимо создать новый отчет о дефекте. Оцените влияние дефекта и научитесь его воспроизводить |
Заметки о выпуске - это краткий набор сведений, сопровождающий каждый выпуск продукта. В этих заметках собраны требования к среде, описания установки и запуска приложения, новых возможностей, исправленных ошибок, известных дефектов и способов обхода проблем. Из заметок о выпуске пользователь узнает подробности о новой версии.
| Документирование выявленных ограничений | Опишите требования среды |
|---|
Завершающий этап в создании продукта - его развертывание. Развертывание служит для сбора всех компонентов, необходимых для окончательной поставки. В некоторых случаях сюда входит запись продукта на мастер-носитель. В других - установка продукта на технологическом сервере или на веб-узле, с которого он будет загружаться пользователями. Какой бы механизм не применялся, цель одна - передача системы пользователям.
| Создание установочного комплекта | Сделайте для продукта установочный комплект, который упростит установку или развертывание приложения |
|---|---|
| Распространение выпуска | Обеспечьте поставку системы потребителям |
Наличие дефекта указывает на потенциальную необходимость изменения уже работающей программы. Устранение дефекта не должно оказывать побочного эффекта. Чтобы исправление дефекта не нарушало работающий код, процесс коррекции должен быть методичным и управляемым. Код, измененный при устранении дефекта, необходимо проверить на соответствие правилам кодирования, автономно протестировать, пересмотреть, интегрировать в приложение и зарегистрировать в системе управления версиями. Все это делает ответственный за обработку дефекта участник проектной группы. Если все перечисленные действия не будут выполнены, "исправление" будет хуже исходной проблемы.
| Воспроизведение дефекта | Руководствуйтесь описанием дефекта |
|---|---|
| Создание или изменение теста модуля | Определите область охвата теста модуля |
| Определение причины возникновения дефекта | Выделите функциональную область |
| Переназначение дефекта | Измените описание дефекта |
| Выбор стратегии устранения дефекта | Проанализируйте обнаруженный дефект |
| Изменение программы | Найдите нужный код |
| Выполнение теста модуля | Выберите тест модуля из коллекции |
| Рефакторинг кода | Определите сложность |
| Обзор кода | Проверьте правильность имен |
| Интеграция изменений | Проверьте зависимости |
Прежде всего, надо попытаться воссоздать дефект. Если сделать это не удается, значит описание дефекта не содержит достаточную и правильную информацию или неисправность является перемежающейся. Необходимо выяснить действительные условия проявления дефекта, выявить его и исправить.
| Использование описания | Если в отчете о дефекте содержится описание последовательности его воссоздания, следуйте этой инструкции |
|---|---|
| Получение дополнительных сведений | Если воспроизвести дефект не удается, соберите больше сведений. Используйте данные тестов и предыдущие отчеты о дефектах, связанные с решением подобных проблем. Просмотрите отчеты об ошибках, с которыми работали другие разработчики или специалисты по тестированию |
| Отказ от обработки дефекта | Если проявление дефекта так и не удалось воссоздать, может быть принято решение прекратить обработку дефекта (перевести его в состояние "Closed") на том основании, что он не воспроизводится ("Unable to |
Причину возникновения обнаруженного дефекта должен определить разработчик. Для поиска корня проблемы разработчик может применять различные тактики и средства. Стратегия устранения дефекта, как правило, оказывается достаточно очевидной после выявления причины. Для поиска хороши такие инструменты, как журналы, отладчики, листинги и пр.
| Выделение функциональной области | Исключите из поиска источников проблемы области кода, не вызывающие подозрения |
|---|---|
| Трассировка подозрительного кода | Используйте визуальные возможности отладчика при поиске дефекта |
| Анализ системы всеми доступными средствами | Кроме трассировки применяйте все доступные средства поиска неисправностей, в том числе от сторонних производителей |
| Локализуйте проблему | Максимально сузьте диапазон поиска дефекта |
| Анализ кода | Если применение отладчика невозможно из соображений производительности или ограниченности ресурсов, проанализируйте исходный текст строка за строкой |
Причиной переназначения дефекта может служить недостаток сведений о нем, малый опыт разработчика по устранению подобных проблем или балансировка загруженности исполнителей. При переназначении дефекта добавьте в описатель сведения о причине выполнения этой операции.
| Изменение дескриптора дефекта | В бланке документирования дефекта укажите причину переназначения в поле диалога |
|---|---|
| Изменение владельца | Измените сведения о лице, ответственном за обработку дефекта |
Разработчик должен выбрать оптимальный метод решения проблемы, исключающий добавление новых дефектов. При выборе способа исправления дефекта учитываются вопросы архитектуры, производительности и ресурсов. Решение должно быть нацелено на устранение проблемы. Однако для соответствия требованиям и обеспечения возможностей пользователей, решение может быть принято в ущерб каким-то функциям системы.
| Анализ обнаруженного дефекта | Определите тип дефекта: проблемы с архитектурой, ресурсами или производительностью |
|---|---|
| Проблема с архитектурой | Определите, на какие архитектурные решения повлияет устранение дефекта |
| Проблема с ресурсами | Определите фрагменты кода, на которые оказано воздействие |
| Проблема с производительностью | Определите, на какие фрагменты кода повлияет устранение дефекта |
После выбора подхода к устранению дефекта разработчик должен внести изменения в код. При этом сборка должна остаться работоспособной, не должно быть внесено новых ошибок, а в описатель дефекта должны быть внесены соответствующие изменения
| Получение нужного кода | Найдите все файлы, которые нужно изменить для исправления дефекта |
|---|---|
| Создание нового кода | Для исправления дефекта, возможно, придется написать код в новых файлах |
| Изменение существующих файлов | Для исправления дефекта может потребоваться изменение существующих файлов: добавление или удаление кода |
С помощью теста модуля проверяется корректность реализации определенного программного компонента. Выполнение тестов модулей при разработке уменьшает число дефектов, обнаруживаемых на этапе тестирования, и позволяет бороться с регрессом - появлением новых дефектов при исправлении уже выявленных или добавлении новых функций. Тесты модулей не являются тестами функций или взаимодействия; их единственное назначение - проверить автономную работу фрагмента кода. Разработчики должны убедиться в том, что существующие тесты модулей проходят после написания нового кода. Тестирование должно проводиться на протяжении всего проекта - от реализации архитектурных основ в начале до внесения дополнений в конце проекта. Есть разные типы
| Определение типа теста модуля | Определите типы разрабатываемых тестов модулей. Тесты правильной работы (positive ) проверяют код в нормальном режиме и контролируют корректность результатов. В тестах неправильной работы ( negative ) умышленно некорректно используется код и проверяется его устойчивость и адекватность обработки ошибок. Тесты с внесением неисправностей позволяют обнаружить аномалии в обработке ошибок |
|---|---|
| Создание или изменение теста модуля | Для каждой задачи по разработке определите необходимые тесты модулей, которыми можно проверить как можно больше функций. Напишите тест модуля, убедитесь, что он не проходит, напишите или выделите фрагмент кода путем рефакторинга и прогоните тест модуля. Повторите процедуру для всех выбранных тестов модулей |
| Проверка теста модуля | Прогоните тест и убедитесь, что он не проходит для незавершенных фрагментов и проходит для тех элементов, которые работают как требуется |
Тест модуля покрывает определенную область кода. Используя комбинацию таких тестов, разработчики и тестировщики определяют качество определенного раздела программы. Выполняйте тесты модулей после изменения исходного кода. Выполнение теста модуля подтверждает работоспособность той части программы, которая покрывается этим тестом.
| Определение подходящих тестов модулей | Найдите тест или тесты, позволяющие наиболее адекватно проверить соответствующий элемент программы |
|---|---|
| Выполнение теста модуля | Прогоните тест для кода, который он покрывает |
| Анализ результатов теста | По завершении каждого этапа отметьте его соответствующим образом: Pass (Прошел), Fail (Не прошел), Skip (Пропущен), Warning (Требует внимания) или Blocked (Заблокирован) |
| Отладка кода | Исправьте ошибки в программе, относящейся к задаче |
В процессе рефакторинга кода
| Определение сложности | При добавлении новых функций, обратите внимание на те части программы, структура которых стала более сложной |
|---|---|
| Применение рефакторинга | При рефакторинге вносите за один раз одно изменение. Измените код и все ссылки на измененную область |
| Выполнение тестов модуля | Выполните тесты модуля, чтобы убедиться в |
Обзор кода применяется для выявления областей, с которыми могут возникнуть проблемы в процессе дальнейшей разработки или тестирования. Он также дает возможность узнать мнения других разработчиков о рассматриваемом коде. Обзоры кода позволяют участникам, работающим в той же области, следовать прецедентам, созданным предыдущими разработчиками. В таких партнерских встречах требуется присутствие второго знающего коллеги, с которым разработчик должен пройти по всем изменениям, прежде чем зарегистрировать код в системе управления версиями. Должны быть выполнены тесты модулей и проведен анализ кода. В обзорах нужно сосредоточиться на областях, которые нельзя проверить с помощью компилятора или посредством анализа кода - на производительности, читабельности, безопасности.
| Проверка правильности имен | Имена классов и методов должны отражать назначение соответствующих фрагментов кода |
|---|---|
| Проверка адекватности кода | Рассматриваемый код должен соответствовать задаче, для которой он написан. Допустимы только такие изменения кода, которые добавляют или изменяют функции системы |
| Проверка расширяемости | Написанный код должен допускать расширяемость (если ставилась такая задача) или возможность повторного использования в других частях системы |
| | Повторяющийся код должен быть собран в общих функциях |
| Проверка сложности алгоритма | Число возможных ветвей кода должно быть минимальным. Право на существование имеют только явно необходимые ветви |
| Проверка | Проверьте защиту объектов, уровни привилегий и использование данных в точках входа |
| Внесение изменений по результатам обзора | При проверке используйте контрольный список Внесите изменения, намеченные в результате обзора кода, скомпилируйте программу, выполните тесты модулей и выполните анализ кода. Если какие-либо тесты не прошли, выявите ошибки и исправьте код |
Чтобы приложение было устойчивым и согласованным, необходимо организовать интеграцию изменений в код. Когда код состоит из небольших изменений, каждое из которых соответствует задаче по разработке или исправлению дефекта, его проще поддерживать в стабильном состоянии. Легче найти и изолировать потенциальную проблему. После интеграции последней задачи по разработке, ответственный за реализацию соответствующего сценария или требования к качеству, разработчик проверяет всю функциональность от начала до конца. Для состояния сценария или требования к качеству устанавливается значение Resolved (Обработан) и описатель назначается тестировщику.
| Проверка зависимостей | Если задача зависит от других задач, которые еще не завершены, дождитесь, когда они будут интегрированы в систему |
|---|---|
| Тестирование и интегрирование других задач по разработке | Проверьте, что вносимые вами изменения, связанные с исправлением дефекта, реализацией части сценария или требования к качеству, нормально работают совместно с уже интегрированными изменениями |
| Регистрация пакета изменений | Увеличьте номер в поле "Resolved in Build" (Решено в сборке) для задачи исправления дефекта или в поле " |
| Завершение задачи | Если описатель, с которым связаны сделанные изменения, представляет сценарий или требование к качеству, а вы не являетесь его владельцем, уведомите владельца о том, что завершили внесение изменений |
Оснований для закрытия дефекта может быть несколько. С закрытым дефектом в текущей итерации больше не выполняются никакие действия. Дефект может быть закрыт потому, что он исправлен, его устранение отложено до следующего выпуска продукта, он перестал быть актуальным, его невозможно воссоздать или он соответствует ранее зарегистрированному дефекту. Закрытие дефекта обычно происходит при классификации или после устранения и проверки этого факта.
| Проверка исправления | Попытайтесь воссоздать дефект |
|---|---|
| Закрытие дефекта | Подтвердите, что дефект повторяет Существующий |
Необходимо убедиться, что дефект исправлен корректно и не нарушены другие функции. После того как разработчик исправил дефект, в дело вступает тестировщик, который отвечает за
| Попытка воссоздать дефект | Попытайтесь воспроизвести дефект, выполнив представленную в описателе дефекта последовательность действий |
|---|---|
| Неожиданное поведение | Выполните смежные функции и попытайтесь найти неожиданные моменты в поведении системы, которые могут быть связаны с дефектом. Особенно важно это в случае проверки задачи по разработке, нереализованной полностью |
| Получение дополнительных сведений о дефекте | Если в описателе дефекта недостаточно данных или они непонятны, обратитесь к нужному разработчику или тому, кто обнаружил и задокументировал дефект |
| Переназначение дефекта | Если |
Оснований для закрытия дефекта есть несколько. Зачастую дефекты исправляются разработчиками, затем помечаются как решенные и в конце закрываются менеджерами проектов. Дефект закрывается, если его исправление переносится на другой выпуск; считается неактуальным, если доказано, что его нельзя воспроизвести или подтверждено, что он дублирует существующий.
| Обновление описателя повторного дефекта | Если дефект аналогичен существующему, в его описателе надо сослаться на аналог |
|---|---|
| Неустраняемые дефекты | Если дефект не будет исправлен, подробно опишите причину. Это может быть ограничение системы или соответствие дизайну |
| Обновление описателя закрытого дефекта | Если больше не удается добиться появления дефекта, добавьте соответствующие сведения в описатель и закройте дефект |
В сценариях формулируются функциональные задачи системы. Для определения этих задач внимательно изучите все потребности собирательных образов системы. Эти задачи могут быть сначала просто выписаны в виде списка, а позднее описаны в виде сценариев. Старайтесь не допускать сценариев, описывающих неудачные или неоптимальные пути поставленных задач. Сценарии могут создаваться во время "мозгового штурма", при помощи моментальных снимков или пробных тестов. Все они добавляются в список сценариев. Когда сценарии назначаются на следующую итерацию, они документируются и им присваиваются приоритеты. Создание сценариев заканчивается, когда составлен график реализации всех сценариев в итерациях, либо после создания архитектурного прототипа.
| Работа над сценариями методом "мозгового штурма" | Определите задачи системы |
|---|---|
| Создание моментальных снимков деятельности | Выясните типичные способы использования системы |
| Определение приоритетов в списке сценариев | Определите приоритеты для каждого сценария |
| Создание описания сценария | Выберите подходящий обобщенный образ |
| Раскадровка сценария | Подберите инструмент для раскадровки |
Первоначально список сценариев состоит из элементов сценариев. Их используют для определения целей приложения. Элемент сценария состоит из имени и краткого описания, определяющего уникальность элемента. Элементы становятся описателями после синхронизации сценариев. Проведите коллективное обсуждение и добавьте сценарии в список сценариев, проанализируйте задачи приложения и то, как оно будет использоваться каждым собирательным образом. Исходный список сценариев создается в первой итерации, а затем каждый раз, когда меняются требования или выявляются новые, список сценариев следует пересматривать и корректировать.
| Определение задач системы | В папке требований Проводника команды откройте список сценариев. Список сценариев связан с проектом. Импортируйте все сценарии, созданные при помощи Проводника команды |
|---|---|
| Формулировка сценариев | Выберите цель и рассмотрите разные способы, которыми собирательный образ может достичь ее или потерпеть в этом неудачу. Для способа, которым собирательный образ пытается достичь цели, выберите описательное имя. Затем добавьте элемент сценария с этим именем в список сценариев. При определении концепции проекта следует убедиться, что представление о будущем приложения охватывает все сценарии. При изменении представления следует корректировать концепцию |
При определении приоритета сценария в списке в расчет принимаются как его значимость для пользователей, так и для приложения в целом. Приоритеты определяют очередность реализации сценариев. Сам процесс определения приоритетов помогает выявить наиболее важные и ценные сценарии, которые будут реализованы в ближайшей итерации.
| Определение общего приоритета | Каждому сценарию в списке назначьте общий приоритет. В поле приоритета списка сценариев впишите соответствующее числовое значение |
|---|---|
| Описание приоритетных сценариев | Используя шаблон описания сценария, контурно обрисуйте наиболее приоритетные сценарии, снабдив их кратким описанием, но, в то же время, достаточно подробным, чтобы разработчики на его основании смогли сделать оценки |
| Передача запросов для выполнения оценок | Пошлите менеджеру проекта и разработчикам запрос на выполнение общих оценок для самых |
| Разбиение требований или изменение приоритетов | Если цена какого-либо сценария превышает бюджет итерации, попробуйте разбить это требование |
Описание сценария из списка пишется в процессе создания начального плана итерации, т. е. когда она становится кандидатом на реализацию в ближайшем сценарии. Уровень детализации должен быть достаточным для передачи потребностей собирательного образа разработчикам и для создания контрольных примеров. Большие сценарии могут быть разбиты на более мелкие, укладывающиеся в рамки одной итерации. После создания описания оно публикуется на портале проекта, а будущим разработчикам и тестировщикам рассылаются сообщения, чтобы они просмотрели их.
| Выбор подходящего собирательного образа | Из списка сценариев выберите сценарий, вошедший в ближайшую итерацию или важный с точки зрения архитектуры. Откройте шаблон описания сценария в Microsoft Word и сохраните документ, дав ему имя сценария, чтобы отличать его от остальных, уже написанных сценариев |
|---|---|
| Формулировка описания сценария | Пишите сценарий в разделе описания соответствующего документа. С самого начала описывайте каждое действие, выполняемое собирательным образом в процессе достижения поставленной цели. Действия, уже описанные в других сценариях, записывайте схематично, а в тех местах, где сценарий отличается от остальных, будьте наиболее подробны |
| Разбиение сценариев | Если детальная оценка (составленная как сумма задач разработки) превышает длину итерации, то такой сценарий является кандидатом на разбиение. Получившиеся в результате разбиения подсценарии в сумме должны соответствовать исходному сценарию. Для каждого нового сценария следует определить характерные отличия от других. На основе шаблона сценария создайте хотя бы два документа, описывающие сценарии |
Раскадровка улучшает сценарий и снабжает его информацией о пользовательском интерфейсе. Она исключительно полезна, когда пользовательский интерфейс играет важную роль в удовлетворении потребностей внешних пользователей. Раскадровка также помогает подогнать проект под требования разных организаций. Она может включать различные графические элементы, такие как снимки экранов, макеты приложений,
| Выбор сценариев | Отберите сценарии, требующие раскадровки |
|---|---|
| Создание снимков экрана | Для раскадровки хорошо подходят такие инструменты, как Microsoft Visio и Microsoft PowerPoint. Создайте экраны, которые должен видеть собирательный персонаж. Схематично нарисуйте пользовательский интерфейс, требуемый сценарием. Совместно с командой разработчиков убедитесь, что полученный пользовательский интерфейс не противоречит выбранной метафоре |
| Создание | Прямоугольниками изображайте экраны, а стрелками - их последовательность |
Ведение проекта - это постоянный мониторинг и документирование его состояния. Чтобы обеспечить постоянный контроль над проектом, допускается внесение необходимых изменений. Необходимо отслеживать как ход проекта в целом, так и выполнение отдельных итераций. Надо своевременно выявить дефекты, определить риски и присвоить им приоритеты.
| Обзор целей | Установите минимальный приемлемый уровень |
|---|---|
| Оценка хода выполнения | Поддерживайте график проекта в актуальном состоянии |
| Оценка пороговых значений показателей тестов | Проанализируйте отчеты о выполненных тестах |
| Классификация дефектов | Создайте список дефектов, подлежащих классификации |
| Определение риска | Определите требования к качеству, связанные с большими рисками |
Для успешной реализации проекта важно отслеживать и оценивать ход его выполнения. Правильное планирование и управление проектом зависит от возможности оценивать его текущее состояние. Кроме того, надо отслеживать организационные, технические и проектные риски. Проект можно привязать ко времени или к реализуемому функционалу. В привязанных ко времени проектах крайние сроки зачастую определяются событиями на рынке, положением конкурентов, существующими нормами, финансовыми факторами и другими причинами, связанными с бизнесом. Даже проекты с фиксированным функционалом могут иметь желательную дату реализации. В проектах, не фиксированных по времени, правильный прогноз даты завершения благотворно скажется на уровне продаж, маркетинговых показателях, на внедрении, обучении и эксплуатационных факторах.
| Оценка списка обязательных работ | Если есть предполагаемая дата реализации проекта, определите число необходимых итераций на основании длительности начальной итерации. Используйте данные из отчета об общем темпе проекта ( |
|---|---|
| Проверка зависимостей | Проверьте зависимости в графике и убедитесь, что они соблюдаются |
| | При необходимости оцените число итераций, необходимых для реализации планируемых функций, и определите, соответствует ли ход работ целям, определенным в концепции проекта |
В документе с описанием подходов к тестированию указаны пороговые значения для показателей тестов. Необходимо периодически анализировать продвижение проекта в соответствии с этими показателями и при необходимости их корректировать.
| Анализ отчетов о выполненных тестах | Отчеты о выполненных тестах помогут понять текущее положение дел, если сравнить результаты с пороговыми значениями |
|---|---|
| Определение задач и рисков тестирования | Совместно со специалистами по тестированию создайте и распределите задачи тестирования |
Своевременно необнаруженный и неконтролируемый риск может отрицательно сказаться на выполнении проекта. Риски имеют место в различных областях. Например, в одном проекте риск может быть связан с эргономикой, поскольку эта область принципиально важна для заказчика, а в другом проекте риски могут быть связаны с производительностью. Важно четко определить и учесть наиболее опасные риски в первых же итерациях проекта. По мере появления дополнительных сведений о сценариях и требованиях к качеству в каждой последующей итерации уделите время поиску новых возможных рисков.
| Определение требований к качеству, связанных с риском | Проанализируйте требования к эргономике. Определите, является ли интерфейс пользователя ключевым фактором оценки приложения заказчиком |
|---|---|
| Проверка сценариев | Проанализируйте сценарии на предмет потенциальных рисков |
| Вопросы интеграции | Если в рассмотренных областях обнаружены угрозы для успешной реализации проекта, создайте описатель риска. Сформулируйте потенциальные проблемы, связанные с данным риском, и задокументируйте их в описателе |
| Формулирование рисков и расстановка их приоритетов | Какие библиотеки сторонних поставщиков могут использоваться приложением? Проверены ли они? Если нет, выявите неизвестные характеристики библиотек, которые необходимо проверить |
После всех итераций, кроме нулевой, продукт должен быть в стабильном состоянии и готовым к поставке. Установите показатель минимального приемлемого уровня ( minimum acceptance level ), чтобы в дальнейшем сравнивать реализованные сценарии и требования к качеству с этим уровнем. Минимальный приемлемый уровень должен постоянно переоцениваться с учетом изменений потребностей заказчика, состояния рынка и т. д. Минимальный приемлемый уровень обновляется после каждой итерации.
| Установка минимального приемлемого уровня | Оцените ожидания, которые связывают с разрабатываемым продуктом заказчики, и рынок в целом. Примите в расчет конкурентов, существующие аналоги и потребности бизнеса |
|---|---|
| Отчет о текущем состоянии | Сформируйте отчет об оставшихся работах для оценки хода выполнения проекта |
Классификация ( triage ) - процесс анализа вновь обнаруженных или заново обрабатываемых дефектов, назначения им приоритетов и привязки к определенным итерациям. Классификацию проводит менеджер проекта с участием других участников проектной группы.
| Создание отчета о дефектах | Выдайте запрос системе отслеживания дефектов о вновь обнаруженных и заново обрабатываемых дефектах |
|---|---|
| Анализ дефектов | Ознакомьтесь с каждым обнаруженным дефектом, привлекая разработчиков, тестировщиков и менеджера проекта. Определите важность исправления каждого из них до конца проекта и текущей итерации |
| Присвоение приоритета и привязка к итерации | Каждому дефекту присвойте приоритет и определите, в какой итерации его необходимо исправить, чтобы его обработку можно было учесть в графике проекта |
| Воспроизведение непонятных дефектов | Если отчет о дефекте невразумителен или нет уверенности в истинном действии дефекта, группа управления программой должна попробовать воссоздать дефект, чтобы лучше понять его реальное влияние и возможности повторного появления |
В процессе сборки создается единый продукт, включающий существующий код и все новые пакеты изменений. Однако вносимые изменения должны быть корректны. Пакет изменений должен быть скомпилирован и должны быть выполнены компоновочные тесты. Добавляемый пакет изменений не должен провоцировать проблемы - проверка этого факта является частью процесса приемки сборки. К каждой сборке прилагается набор комментариев, поясняющих вносимые изменения.
| Запуск сборки | Минимизируйте зависимости |
|---|---|
| Проверка сборки | Проверьте основные функции |
| Исправление сборки | Выделите ошибки компиляции |
| Приемка сборки | Протестируйте сборку |
Чтобы гарантировать целостность, запускайте сборку продукта всякий раз, когда требуется включить в него изменения. Это помогает синхронизировать изменения и предоставляет всем разработчикам рабочую платформу. Чтобы ускорить слишком медленную сборку, пересмотрите зависимости.
| Минимизируйте зависимости | Чем меньше в приложении зависимостей, тем быстрей происходит его сборка |
|---|---|
| Начало сборки | Запускайте сборку всякий раз, когда можно интегрировать изменения. Создавайте "чистую" сборку только в случае абсолютной необходимости. "Чистые" сборки делаются по ночам. Если процесс сборки не выполняется без предварительной "чистой" сборки, проверьте зависимости |
Необходимо поддерживать качество приложения при внесении любого изменения. Проводите проверочные испытания, демонстрирующие, что базовая функциональность сборки не затронута. Проверочные испытания также проводятся для проверки изменений, сделанных в процессе исправления дефекта и для контроля работоспособности вновь добавленных функций.
| Проверка основных функций | Выполните минимальное подмножество тестов, в частности, проверочный тест сборки, иногда называемый "дымовым", чтобы убедиться в стабильности базовой функциональности системы |
|---|---|
| Проверка измененных функций | Запустите дополнительные тесты и убедитесь, что все запланированные пакеты изменений добавлены и изменения корректны |
| Информирование участников о готовности сборки | Если все тесты прошли, проинформируйте все заинтересованные стороны, что сборка допущена к работе |
В процессе проверочных испытаний может возникнуть ситуация, когда исходный код не компилируется на сборочной машине или внешние компоненты не работают корректно. Чтобы исправить сборку, выявите ошибки периода компиляции и выполнения и проинформируйте разработчиков, ответственных за соответствующие компоненты. Задержки в решении проблем со сборкой тормозят выполнение других работ, например тестирования.
| Выделение ошибок компиляции | Перед компиляцией запустите сценарий, очищающий используемые при сборке каталоги от ненужных файлов. Компиляция исходного кода и построение компонентов на сборочной машине может не проходить, хотя та же процедура нормально проходила на машине разработчика |
|---|---|
| Обработка ошибок периода выполнения | Фиксируйте все ошибки периода выполнения и информируйте о них разработчика - напрямую и посредством описателя дефекта |
| Проверка содержимого | Сравните содержимое сборки с указанным в спецификации: нет ли лишних файлов и не пропущены ли нужные |
| Проверка установочных сценариев и исполняемых файлов | Просмотрите установочные сценарии и проверьте, расположены ли необходимые файлы в каталогах, указанных в спецификации и сценариях |
| Проверка версий связанных модулей | Проверьте версии используемых при компоновке внешних модулей, например библиотек сторонних поставщиков. Использование некорректных версий может привести к непредсказуемому |
| Исправление и перекомпоновка сборки | После решения проблемы нужно сразу заново создать сборку, чтобы не блокировать работу других участников проекта |
Когда сборка допускается к работе, это говорит о том, что реализованы некоторые минимальные требования и сборка готова к дальнейшей эксплуатации. Для приемки сборки убедитесь в том, что компиляция и компоновка проходят без сбоев, а проверочные тесты покрывают всю базовую функциональность. Добавьте к сборочным тестам проверки, сделанные в последней итерации.
| Поддержка сборочных тестов | Добавляйте или удаляйте разделы сборочных тестов, чтобы они обеспечивали адекватную проверку сборок |
|---|---|
| Наблюдение за сборкой | Регулярно просматривайте отчеты о деталях сборки |
В определенный момент набор реализованных функций становится достаточным для выпуска продукта. Существует несколько типов выпусков: альфа-, бета-версия и окончательная версия или доработанный выпуск. Этот выпуск окажет большее воздействие, чем сама команда, которая его создавала, о нем будут судить пользователи. Для программных продуктов, созданных для внешних потребителей, необходимы маркетинговые и торговые мероприятия. Системы, созданные для внутреннего применения, требуют организации обучения и поддержки эксплуатации. Чтобы заранее начать готовить соответствующих людей, составляется план выпуска. Процесс выпуска и связанный с ним план во многом зависит от типа продукта и способа его применения.
| Исполнение плана выпуска | Проверьте правильность материала |
|---|---|
| Проверка выпуска | Создайте свой раздел для выпуска |
| Заметки о выпуске | Задокументируйте выявленные ограничения |
| Развертывание продукта | Создайте установочный комплект |
В плане выпуска упоминаются все заинтересованные в получении нового выпуска. Этот план позволяет подготовиться к выпуску продукта изготовителей носителей, заказчиков и группу эксплуатации. План позволяет также проинформировать лиц, ответственных за последующую работу с продуктом, о том, когда они смогут его получить и на какую техническую поддержку вправе рассчитывать.
| Проверка материалов, связанных с выпуском | Проверьте, что материалы, относящиеся к маркетингу, торговле, обучению и приемке заказчиком, соответствуют составу продукта |
|---|---|
| Координация поставки продукта | Обеспечьте поставку или развертывание продукта |
Когда выполнены изложенные в концепции и в описании подхода к тестированию требования к функциям, качеству и срокам, можно рассматривать возможность выпуска продукта (в том числе альфа- или бета-версий). Чтобы сборка стала официальным выпуском, надо подвергнуть ее окончательному
| Создание своего раздела для выпуска | Выделите в иерархии проекта свой раздел для кандидата на выпуск. Это защитит код и позволит вносить только выбранные изменения |
|---|---|
| Выполнение регрессионных тестов | Выполните для кандидата на выпуск полный регрессионный тест |
| Документирование дефекта | Если тест не проходит, необходимо создать новый отчет о дефекте. Оцените влияние дефекта и научитесь его воспроизводить |
Заметки о выпуске - это краткий набор сведений, сопровождающий каждый выпуск продукта. В этих заметках собраны требования к среде, описания установки и запуска приложения, новых возможностей, исправленных ошибок, известных дефектов и способов обхода проблем. Из заметок о выпуске пользователь узнает подробности о новой версии.
| Документирование выявленных ограничений | Опишите требования среды |
|---|
Завершающий этап в создании продукта - его развертывание. Развертывание служит для сбора всех компонентов, необходимых для окончательной поставки. В некоторых случаях сюда входит запись продукта на мастер-носитель. В других - установка продукта на технологическом сервере или на веб-узле, с которого он будет загружаться пользователями. Какой бы механизм не применялся, цель одна - передача системы пользователям.
| Создание установочного комплекта | Сделайте для продукта установочный комплект, который упростит установку или развертывание приложения |
|---|---|
| Распространение выпуска | Обеспечьте поставку системы потребителям |
Наличие дефекта указывает на потенциальную необходимость изменения уже работающей программы. Устранение дефекта не должно оказывать побочного эффекта. Чтобы исправление дефекта не нарушало работающий код, процесс коррекции должен быть методичным и управляемым. Код, измененный при устранении дефекта, необходимо проверить на соответствие правилам кодирования, автономно протестировать, пересмотреть, интегрировать в приложение и зарегистрировать в системе управления версиями. Все это делает ответственный за обработку дефекта участник проектной группы. Если все перечисленные действия не будут выполнены, "исправление" будет хуже исходной проблемы.
| Воспроизведение дефекта | Руководствуйтесь описанием дефекта |
|---|---|
| Создание или изменение теста модуля | Определите область охвата теста модуля |
| Определение причины возникновения дефекта | Выделите функциональную область |
| Переназначение дефекта | Измените описание дефекта |
| Выбор стратегии устранения дефекта | Проанализируйте обнаруженный дефект |
| Изменение программы | Найдите нужный код |
| Выполнение теста модуля | Выберите тест модуля из коллекции |
| Рефакторинг кода | Определите сложность |
| Обзор кода | Проверьте правильность имен |
| Интеграция изменений | Проверьте зависимости |
Прежде всего, надо попытаться воссоздать дефект. Если сделать это не удается, значит описание дефекта не содержит достаточную и правильную информацию или неисправность является перемежающейся. Необходимо выяснить действительные условия проявления дефекта, выявить его и исправить.
| Использование описания | Если в отчете о дефекте содержится описание последовательности его воссоздания, следуйте этой инструкции |
|---|---|
| Получение дополнительных сведений | Если воспроизвести дефект не удается, соберите больше сведений. Используйте данные тестов и предыдущие отчеты о дефектах, связанные с решением подобных проблем. Просмотрите отчеты об ошибках, с которыми работали другие разработчики или специалисты по тестированию |
| Отказ от обработки дефекта | Если проявление дефекта так и не удалось воссоздать, может быть принято решение прекратить обработку дефекта (перевести его в состояние "Closed") на том основании, что он не воспроизводится ("Unable to |
Причину возникновения обнаруженного дефекта должен определить разработчик. Для поиска корня проблемы разработчик может применять различные тактики и средства. Стратегия устранения дефекта, как правило, оказывается достаточно очевидной после выявления причины. Для поиска хороши такие инструменты, как журналы, отладчики, листинги и пр.
| Выделение функциональной области | Исключите из поиска источников проблемы области кода, не вызывающие подозрения |
|---|---|
| Трассировка подозрительного кода | Используйте визуальные возможности отладчика при поиске дефекта |
| Анализ системы всеми доступными средствами | Кроме трассировки применяйте все доступные средства поиска неисправностей, в том числе от сторонних производителей |
| Локализуйте проблему | Максимально сузьте диапазон поиска дефекта |
| Анализ кода | Если применение отладчика невозможно из соображений производительности или ограниченности ресурсов, проанализируйте исходный текст строка за строкой |
Причиной переназначения дефекта может служить недостаток сведений о нем, малый опыт разработчика по устранению подобных проблем или балансировка загруженности исполнителей. При переназначении дефекта добавьте в описатель сведения о причине выполнения этой операции.
| Изменение дескриптора дефекта | В бланке документирования дефекта укажите причину переназначения в поле диалога |
|---|---|
| Изменение владельца | Измените сведения о лице, ответственном за обработку дефекта |
Разработчик должен выбрать оптимальный метод решения проблемы, исключающий добавление новых дефектов. При выборе способа исправления дефекта учитываются вопросы архитектуры, производительности и ресурсов. Решение должно быть нацелено на устранение проблемы. Однако для соответствия требованиям и обеспечения возможностей пользователей, решение может быть принято в ущерб каким-то функциям системы.
| Анализ обнаруженного дефекта | Определите тип дефекта: проблемы с архитектурой, ресурсами или производительностью |
|---|---|
| Проблема с архитектурой | Определите, на какие архитектурные решения повлияет устранение дефекта |
| Проблема с ресурсами | Определите фрагменты кода, на которые оказано воздействие |
| Проблема с производительностью | Определите, на какие фрагменты кода повлияет устранение дефекта |
После выбора подхода к устранению дефекта разработчик должен внести изменения в код. При этом сборка должна остаться работоспособной, не должно быть внесено новых ошибок, а в описатель дефекта должны быть внесены соответствующие изменения
| Получение нужного кода | Найдите все файлы, которые нужно изменить для исправления дефекта |
|---|---|
| Создание нового кода | Для исправления дефекта, возможно, придется написать код в новых файлах |
| Изменение существующих файлов | Для исправления дефекта может потребоваться изменение существующих файлов: добавление или удаление кода |
С помощью теста модуля проверяется корректность реализации определенного программного компонента. Выполнение тестов модулей при разработке уменьшает число дефектов, обнаруживаемых на этапе тестирования, и позволяет бороться с регрессом - появлением новых дефектов при исправлении уже выявленных или добавлении новых функций. Тесты модулей не являются тестами функций или взаимодействия; их единственное назначение - проверить автономную работу фрагмента кода. Разработчики должны убедиться в том, что существующие тесты модулей проходят после написания нового кода. Тестирование должно проводиться на протяжении всего проекта - от реализации архитектурных основ в начале до внесения дополнений в конце проекта. Есть разные типы
| Определение типа теста модуля | Определите типы разрабатываемых тестов модулей. Тесты правильной работы (positive ) проверяют код в нормальном режиме и контролируют корректность результатов. В тестах неправильной работы ( negative ) умышленно некорректно используется код и проверяется его устойчивость и адекватность обработки ошибок. Тесты с внесением неисправностей позволяют обнаружить аномалии в обработке ошибок |
|---|---|
| Создание или изменение теста модуля | Для каждой задачи по разработке определите необходимые тесты модулей, которыми можно проверить как можно больше функций. Напишите тест модуля, убедитесь, что он не проходит, напишите или выделите фрагмент кода путем рефакторинга и прогоните тест модуля. Повторите процедуру для всех выбранных тестов модулей |
| Проверка теста модуля | Прогоните тест и убедитесь, что он не проходит для незавершенных фрагментов и проходит для тех элементов, которые работают как требуется |
Тест модуля покрывает определенную область кода. Используя комбинацию таких тестов, разработчики и тестировщики определяют качество определенного раздела программы. Выполняйте тесты модулей после изменения исходного кода. Выполнение теста модуля подтверждает работоспособность той части программы, которая покрывается этим тестом.
| Определение подходящих тестов модулей | Найдите тест или тесты, позволяющие наиболее адекватно проверить соответствующий элемент программы |
|---|---|
| Выполнение теста модуля | Прогоните тест для кода, который он покрывает |
| Анализ результатов теста | По завершении каждого этапа отметьте его соответствующим образом: Pass (Прошел), Fail (Не прошел), Skip (Пропущен), Warning (Требует внимания) или Blocked (Заблокирован) |
| Отладка кода | Исправьте ошибки в программе, относящейся к задаче |
В процессе рефакторинга кода
| Определение сложности | При добавлении новых функций, обратите внимание на те части программы, структура которых стала более сложной |
|---|---|
| Применение рефакторинга | При рефакторинге вносите за один раз одно изменение. Измените код и все ссылки на измененную область |
| Выполнение тестов модуля | Выполните тесты модуля, чтобы убедиться в |
Обзор кода применяется для выявления областей, с которыми могут возникнуть проблемы в процессе дальнейшей разработки или тестирования. Он также дает возможность узнать мнения других разработчиков о рассматриваемом коде. Обзоры кода позволяют участникам, работающим в той же области, следовать прецедентам, созданным предыдущими разработчиками. В таких партнерских встречах требуется присутствие второго знающего коллеги, с которым разработчик должен пройти по всем изменениям, прежде чем зарегистрировать код в системе управления версиями. Должны быть выполнены тесты модулей и проведен анализ кода. В обзорах нужно сосредоточиться на областях, которые нельзя проверить с помощью компилятора или посредством анализа кода - на производительности, читабельности, безопасности.
| Проверка правильности имен | Имена классов и методов должны отражать назначение соответствующих фрагментов кода |
|---|---|
| Проверка адекватности кода | Рассматриваемый код должен соответствовать задаче, для которой он написан. Допустимы только такие изменения кода, которые добавляют или изменяют функции системы |
| Проверка расширяемости | Написанный код должен допускать расширяемость (если ставилась такая задача) или возможность повторного использования в других частях системы |
| | Повторяющийся код должен быть собран в общих функциях |
| Проверка сложности алгоритма | Число возможных ветвей кода должно быть минимальным. Право на существование имеют только явно необходимые ветви |
| Проверка | Проверьте защиту объектов, уровни привилегий и использование данных в точках входа |
| Внесение изменений по результатам обзора | При проверке используйте контрольный список Внесите изменения, намеченные в результате обзора кода, скомпилируйте программу, выполните тесты модулей и выполните анализ кода. Если какие-либо тесты не прошли, выявите ошибки и исправьте код |
Чтобы приложение было устойчивым и согласованным, необходимо организовать интеграцию изменений в код. Когда код состоит из небольших изменений, каждое из которых соответствует задаче по разработке или исправлению дефекта, его проще поддерживать в стабильном состоянии. Легче найти и изолировать потенциальную проблему. После интеграции последней задачи по разработке, ответственный за реализацию соответствующего сценария или требования к качеству, разработчик проверяет всю функциональность от начала до конца. Для состояния сценария или требования к качеству устанавливается значение Resolved (Обработан) и описатель назначается тестировщику.
| Проверка зависимостей | Если задача зависит от других задач, которые еще не завершены, дождитесь, когда они будут интегрированы в систему |
|---|---|
| Тестирование и интегрирование других задач по разработке | Проверьте, что вносимые вами изменения, связанные с исправлением дефекта, реализацией части сценария или требования к качеству, нормально работают совместно с уже интегрированными изменениями |
| Регистрация пакета изменений | Увеличьте номер в поле "Resolved in Build" (Решено в сборке) для задачи исправления дефекта или в поле " |
| Завершение задачи | Если описатель, с которым связаны сделанные изменения, представляет сценарий или требование к качеству, а вы не являетесь его владельцем, уведомите владельца о том, что завершили внесение изменений |
Оснований для закрытия дефекта может быть несколько. С закрытым дефектом в текущей итерации больше не выполняются никакие действия. Дефект может быть закрыт потому, что он исправлен, его устранение отложено до следующего выпуска продукта, он перестал быть актуальным, его невозможно воссоздать или он соответствует ранее зарегистрированному дефекту. Закрытие дефекта обычно происходит при классификации или после устранения и проверки этого факта.
| Проверка исправления | Попытайтесь воссоздать дефект |
|---|---|
| Закрытие дефекта | Подтвердите, что дефект повторяет Существующий |
Необходимо убедиться, что дефект исправлен корректно и не нарушены другие функции. После того как разработчик исправил дефект, в дело вступает тестировщик, который отвечает за
| Попытка воссоздать дефект | Попытайтесь воспроизвести дефект, выполнив представленную в описателе дефекта последовательность действий |
|---|---|
| Неожиданное поведение | Выполните смежные функции и попытайтесь найти неожиданные моменты в поведении системы, которые могут быть связаны с дефектом. Особенно важно это в случае проверки задачи по разработке, нереализованной полностью |
| Получение дополнительных сведений о дефекте | Если в описателе дефекта недостаточно данных или они непонятны, обратитесь к нужному разработчику или тому, кто обнаружил и задокументировал дефект |
| Переназначение дефекта | Если |
Оснований для закрытия дефекта есть несколько. Зачастую дефекты исправляются разработчиками, затем помечаются как решенные и в конце закрываются менеджерами проектов. Дефект закрывается, если его исправление переносится на другой выпуск; считается неактуальным, если доказано, что его нельзя воспроизвести или подтверждено, что он дублирует существующий.
| Обновление описателя повторного дефекта | Если дефект аналогичен существующему, в его описателе надо сослаться на аналог |
|---|---|
| Неустраняемые дефекты | Если дефект не будет исправлен, подробно опишите причину. Это может быть ограничение системы или соответствие дизайну |
| Обновление описателя закрытого дефекта | Если больше не удается добиться появления дефекта, добавьте соответствующие сведения в описатель и закройте дефект |
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.