Тестирование в Microsoft Solutions Framework

27.3.3. Тестировщик в MSF for Agile Software Development

27.3.3.1. MSF for Agile Software Development

Microsoft Solutions Framework (MSF) for Agile Software Development — управляемый сценариями, основанный на окружении, быстрый процесс разработки программного обеспечения для создания .NET и других объектно-ориентированных приложений. MSF for Agile Software Development включает в себя подходы по управлению требованиями к качеству, такими, как требования к оборудованию или требования к безопасности. На основании окружения MSF помогает решить, как управлять проектом. Этот подход помогает создавать адаптивный процесс, который, преодолевая трудности большинства быстрых процессов разработки программного обеспечения, достигает целей, поставленных при создании проекта перед командой разработчиков.

27.3.3.2. О ролях

В MSF for Agile Software Development собрана вместе команда равных разработчиков (рис. 27.4), которая обеспечивает полный набор необходимых составляющих, связанных с созданием, использованием и обслуживанием создаваемого продукта. Каждый член команды, или роль, отвечает за удовлетворения нужд своей клиентуры, причем ни один клиент не является важнее другого. MSF for Agile Software Development содержит все необходимые методики и подходы для уверенности в том, что команда разработчиков принимает правильные решения.

Рис. 27.4. Команда разработчиков MSF for Agile Software Development

Подробную информацию об MSF for Agile Software Development и ролях в этом подходе можно найти на сайте Microsoft в соответствующем разделе.

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

27.3.3.4. О роли тестировщика

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

Далее будет описана последовательность работы тестировщика по подходу MSF for Agile Software Development.

27.3.3.4.1. Проверка сценария

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

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

Для проверки сценария, в первую очередь, нужно определить подход к тестированию.

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

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

Если это сделано, то выполняются следующие действия.

1. Определение окружения проекта, т.е. выявление уникальных проектных рисков и пользователей, на которых это может повлиять; выявление специальных ситуаций, которые могут повлиять на тестирование; учет влияния рисков; определение того, что произойдет, если возникнет ошибка.
2. Определение тестовой миссии, т.е. определение проектных целей, которые необходимо удовлетворить в течение тестирования; консультация с проектировщиком и бизнес-аналитиком по техническим неясностям и пользовательским рискам; cотрудничество с бизнес-аналитиком и проектировщиком для создания списка приоритетных технических неясностей и пользовательских рисков.
3. Оценивание возможных технологий, т.е. оценивание доступных инструментальных средств для тестирования; оценивание навыков команды тестировщиков; определение тестовых технологий, возможных и соответствующих проекту, основанных на доступных инструментах и навыках.
4. Определение показателей тестирования, т.е. работа с разработчиками для определения реалистичных порогов показателей покрытия кода для тестируемых модулей; использование тестового окружения, цели тестирования и технологии тестирования для определения тестовых показателей; определение того, что тестовые показатели будут часто включать в себя пороги для различных типов текстов (Web, нагрузочные, стрессовые) или процент автоматизированных тестов; работа с бизнес-аналитиком для определения реалистичных показателей порогов нагрузки продукта; добавление тестовых показателей к соответствующим отчётам и в документ, описывающий подход к тестированию; опубликование подхода к тестированию.

В результате выработки подхода к тестированию показатели тестов определены и будут являться обязательными при модульном тестировании.

Далее необходимо написать валидационные тесты.

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

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

Если это сделано, то выполняются следующие действия.

1. Определение тестируемой области и среды, т.е. изолирование тестируемой области (тесты могут быть запущены как часть итерационных тестов, если они автоматизированы).
2. Определение деталей выполнения тестовых примеров, т.е. определение тестовых данные, необходимых для тестового примера; проверка документа "Подход к тестированию"; добавление тестовых данных к соответствующей итерационной части документа; определение всех ограничений для тестовых примеров, вызываемых в тестовых заданиях; определение всех граничных условий для тестовых примеров, вызываемых в тестовых заданиях; определение всех граничных условий для тестового примера; определение, могут ли тестовые примеры быть автоматическими; определение шагов для выполнения сценария.
3. Реализация тестовых примеров, т.е. создание папки для тестирования сценария, если она ещё не создана; написание документации для ручных тестовых примеров; написание автоматизированных тестовых примеров для итерационных тестов; размещение тестовых примеров в папку тестирования сценария; добавление всех тестов, определенных как итерационные, в папку итерационных тестов; cохранение тестов в версионном контроле и в документе, описывающим подход к тестированию.

В результате написания валидационных тестов все граничные условия и вся функциональность тестового задания будут покрыты.

Далее необходимо произвести выбор и запуск тестового примера.

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

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

Если это сделано, то выполняются следующие действия.

1. Определение проводимых тестов, т.е., определение и уделение первостепенного внимания запускаемым тестам в соответствии с кратким обзором тестового плана в документе подхода к тестированию; проверка заметок сборки, чтобы убедиться, что тестируемая функциональность доступна.
2. Определение тестовых конфигураций, т.е. обнаружение и установление тестовых конфигураций, необходимых при тестировании (включает в себя аппаратные средства, программное обеспечение и тестовые данные).
3. Получение сборки, т.е. извлечение сборки с сервера, обеспечивающего версионный контроль.
4. Запуск тестирования, т.е. выбор тестовой папки для сценария или требования к качеству; выбор тестов для запуска; выполнение каждого шага теста, если это ручной тест; запуск теста, если он автоматизированный; использование тестовых данных из документа о подходе к тестированию текущей итерации.
5. Анализ тестовых результатов, т.е. присоединение сценария или требования к качеству к результатам тестирования; сравнение результатов теста с ожидаемыми результатами; выявление ошибок, если результаты не отвечают ожиданиям: если все тесты сценария или требования к качеству пройдены, закрытие рабочего элемента.
6. Закрытие рабочих элементов, т.е., если все тесты из тестового задания выполнены, закрытие рабочего элемента; уведомление владельца сценария, что нет заблокированных элементов.

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

Далее необходимо произвести выявление ошибки.

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

Этот этап производится, если тестирование выявило неожиданное поведение системы.