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

Раннее тестирование (early testing)

22.06.2010 10:52

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

 

Вот небольшой обзор практик раннего тестирования, в подтверждение предыдущего тезиса:

  • в гибких методологиях, например, Scrum - это использование коротких итераций, по результатам которых выпускается работающий продукт с требуемым качеством, то есть в котором нет значимых дефектов.
  • в экстремальном программировании - это практика TDD, суть которой заключается в создании тестов перед тем, как будет осуществляться проектирование и реализация.
  • в бережливом программировании (lean software development) - это повсеместное внедрение контролирующих механизмов на всех стадиях разработки, призванных выявить дефекты в понимании, артефактах и реализации и сразу же приступить к их устранению, не откладывая, например, редизайн архитектуры на фазу стабилизации или вообще сопровождения выпущенного продукта.
  • в более формализованных практиках (MSF Agile, Agile RUP) - это верификация требований, дизайна, исходного кода и других артефактов путем применения более-менее формального метода, например, ревью или восстановления предыдущего артефакта на основе последующих.

 

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

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

 

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

  • Каким образом выполнять раннее тестирование? Например, как можно проверить что-то, если еще нет продукта, который можно пощупать? Ответов может быть много: делайте прототипы, используйте методы верификации артефактов, например, дизайна. Однако, на мой взгляд, правильный ответ: это зависит и никто толком не знает как, исследуйте и придумывайте. Это тот самый случай, где нужно применить всю вашу фантазию и творчество.
  • Как встроить эту практику в процесс создания программных продуктов? Конечно, нужна определенная дисциплина и соблюдение правил игры. И в этом вам может помочь DEVPROM, в котором фокус смещен с простого учета артефактов (дефектов) на вовлечение всей команды в полноценную работу над продуктом. При планировании пожеланий в итерации система автоматически предлагает создавать задачи по всем используемым фазам разработки. Таким образом, планируя пожелание по сбору требований или проектированию архитектуры приложения, вы не забудете о необходимости тестирования подготовленных артефактов. То есть, DEVPROM дисциплинирует команду с тем, чтобы тестирование разрабатываемого продукта выполнялось на всех этапах его развития.
img1

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