NMI House
разные статейки от NMI

Наконец-то созрел описать своё видение идеального процесса разработки.

Цикл разработки проекта в двух словах:

1. Клиент просит написать нечто.
2. Бизнес аналитик пишет требования к проекту.
3. Пишутся тесты и код.
4. После прогонки тестов требования корректируются, тесты обновляются, реализация обновляется.
5. И так до тех пор, пока все тесты не будут соответствовать требованиям, и пока все тесты не будут проходить успешно. Ах да, про заказчика забыли — он должен подтвердить все требования.
6. После этого проект можно считать как «соответствующий поставленным требованиям».
7. Конец.

Выделяем сущности из этого цикла:

1. Требования
2. Тесты
3. Имплементация

Заказчиков, исполнителей, финансирование и прочее в рассмотрение пока что не берём. Рассматриваем чисто техническую сторону вопроса.

Достаточно ли сущностей, описаных выше, для достижения поставленной цели? Кстати, а цель какая? А цель  (см п.6 выше) — написать проект таким образом, чтобы он соответствовал поставленным требованиям.

Итак, как мы собираемся определять, достигли ли мы цели?

А очень просто — достаточно выполнения 2х условий :

1) успешное прохождение тестов

2) полное покрытие тестами требований

С пунктом номер 1 всё понятно. А вот что с пунктом 2?

Пример : у нас есть какое-то требование и мы написали на него порцию тестов.

Тут приходит запрос на изменение этого требования. Требование меняется. После этого мы должны обновить или перепроверить и тесты.

Но как отследить зависимости между требованиями и тестами? Для этого понадобится еще одна сущность. Назовём её test validation link.

Содержимое test validation link :

1. ID требования
2. версия(hash?) требования
3. ID теста
4. версия(hash?) теста

После добавления test validation link в нашу инфраструктуру легко решаются следующие задачи:

• Обнаружение тестов, подлежащих верификации.
• Обнаружение несвязанных c требованиями тестов.
• Обнаружение не покрытых тестами требований.

Один тест может быть привязан к нескольким требованиям и каждое требование может быть связано с несколькими тестами.

Тут хочется особо подчеркнуть, что все сущности, включая требования и test validation link, должны лежать вместе в системе контроля версий:

Из этого можно будет извлечь пользу, если есть несколько веток проекта и приходится делать merge между ними. При этом можно будет «мёржить» весь проект целиком, включая требования. Естественно, что для этого формат сущностей должен обеспечивать безболезненный автоматический и ручной (в случае конфликтов) merge.

Вы наверное заметили, что test validation link содержит в себе версию теста и версию требования. Возможно, это должны быть хэш функции от контента. Т.к. номер ревизии здесь не совсем подойдёт из-за того, что ревизия может измениться после копирования требования в процессе «мёржа».

Итак, теперь у нас присутствует 4 сущности :

1. Требования
2. Test validation links
3. Тесты
4. Имплементация

Попробуем нарисовать картинку нашего мини-процесса :

Выделяем активности, которые будут присутствовать на проекте:

1. Изменение требования (включая добавление и удаление).
2. Изменение теста (включая добавление и удаление).
3. Изменение имплементации (включая добавление и удаление).
4. Изменение test validation link (включая добавление и удаление).

С моей точки зрения, подобная инфраструктура в разработке проекта — необходимый минимум, который хорошо укладывается в различные процессы (Agile, Waterfall, …). К сожалению, далеко не все его, этот минимум, используют.

На сегодня всё, продолжение следует…

PS: Подскажите, а есть какое-то системы , в которых это всё интегрировано? Может, об этом могут сказать что-нибудь .NET разработчики, использующие TFS ?