в облаке
Попробовать

OpenUP: внедряем раннее тестирование

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

 

Например, в бережливом производстве ПО (lean software development) контроль качества является центральным звеном во всем процессе разработки, из чего следует необходимость выполнять проверку качества на всех стадиях жизненного цикла разработки. В семействе Agile методологий активно применяется практика Test-driven development, при применении которой вначале создаются тесты на программный код и только после этого выполняется само кодирование. В методологиях семейства Model-driven development выполняется тестирование моделей, прежде чем создается программный код, их реализующий.

 

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

 

В Open Unified Process (или сокращенно OpenUP) есть набор подготовленных контрольных списков (checklists), используемых для проверки артефактов на полноту, корректность и непротиворечивость. Сейчас я хочу показать, каким образом можно использовать систему управления проектами DEVPROM для реализации идеи раннего тестирования (early testing) не только на этапе разработки, но и на этапе анализа и проектирования будущего решения.

Пример раннего тестирования

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

 

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

Планирование

Согласно OpenUP на начальной стадии процесса разработки приложения (Inception) выявляются потребности заказчика, создается видение приложения (Vision), формируются предварительные требования (Use cases) и архитектура приложения (Architecture notebook).

img1

Важным моментом является то, что мы также планируем задачи по созданию тестовых случаев (test cases) и выполнению тестов по этим описаниям. В комментарии к задаче по созданию тестовых случаев попросим исполнителя создать тест-план, в который будут включены все подготовленные тестовые случаи. Это пригодится нам чуть позже.

Разработка артефактов

  1. Создаем видение будущего приложения или его части, если мы ограничили скоуп первого релиза приложения. Детальное описание бизнес-требований содержится в исходном пожелании. По окончании создания этого артефакта выполняем соответствующую задачу.
  2. Создаем несколько архитектурно значимых вариантов использования нашего приложения, покрывающие функциональные особенности. В качестве шаблона описания варианта использования применим готовый шаблон из процесса OpenUP.
  3. Создаем описание будущей архитектуры, в котором описываем основные принципы на которых будет строиться архитектура приложения и чем будут руководствоваться проектировщики модулей приложения.
  4. Создаем тестовые артефакты, используя в качестве шаблонов контрольные списки, соответствующие тестируемым артефактам, например, Vision checklist для создания тестового случая для тестирования Vision.

 

img2 img3 img4 img5

Тестирование

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

img6

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

img8

Изменения и трассировка артефактов

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

img9

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

img11

Еще интересные статьи на эту тему: