В последнее время различные методологи все чаще обращаются к вопросу качества разрабатываемых продуктов, при этом не прибегая к использованию сложных и долгих формальных методов верификации, поскольку современные практики разработки ПО позволяют дать дешевый и достойный ответ. Основная идея: внедрение постоянного и всеохватывающего контроля качества разрабатываемого продукта, что иначе можно назвать ранним тестированием, в противовес глубоко укоренившейся практике: сначала разработаем, а потом будем проверять.
Вот небольшой обзор практик раннего тестирования, в подтверждение предыдущего тезиса:
- в гибких методологиях, например, Scrum - это использование коротких итераций, по результатам которых выпускается работающий продукт с требуемым качеством, то есть в котором нет значимых дефектов.
- в экстремальном программировании - это практика TDD, суть которой заключается в создании тестов перед тем, как будет осуществляться проектирование и реализация.
- в бережливом программировании (lean software development) - это повсеместное внедрение контролирующих механизмов на всех стадиях разработки, призванных выявить дефекты в понимании, артефактах и реализации и сразу же приступить к их устранению, не откладывая, например, редизайн архитектуры на фазу стабилизации или вообще сопровождения выпущенного продукта.
- в более формализованных практиках (MSF Agile, Agile RUP) - это верификация требований, дизайна, исходного кода и других артефактов путем применения более-менее формального метода, например, ревью или восстановления предыдущего артефакта на основе последующих.
У данного тренда безусловно есть важный практический смысл, который выражается в следующем:
- повышается уверенность в качестве и сроках реализации продукта, а также снижении скрытого пласта дефектов, до которого команда доберется за неделю до даты выпуска продукта.
- постоянное обдумывание всех элементов из которых состоит ПО приводит к лучшему пониманию того, что нужно сделать и как лучше это сделать. Ранее тестирование вовлекает в процесс разработки продукта всех участников проекта, обеспечивая тем самым коммуникацию необходимую для построения хорошего продукта и принятия правильных решений.
- из множества альтернатив архитектурных решений или вариантов реализации ваша команда будет выбирать тот, который обладает наилучшей тестируемостью. Тем самым, такой артрибут качества как Testability будет всегда обладать высоким значением в вашем продукте, что в свою очередь будет означать наличие отличного потенциала для проверки всех слоев, модулей и, в итоге, обеспечение высокой степени покрытия функциональности тестами. И напротив, не имея возможности что-то проверить, вы сознательно загоняете себя в область низкого качества продукта, увеличения стоимости и времени разработки.
|
