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