Как я могу предоставить отзыв моей команде об изменениях, включенных в сборку, и их влиянии на риск?

Question

Это что-то, что вы уже делаете или знаете о хорошем инструменте?

ЦЕЛЬ: Команда помощи понимает, как недавние изменения источника влияют на риск, поэтому они знают, где сосредоточить усилия по тестированию. Предоставляйте данные с течением времени и отправляйте их обратно в фазы планирования и определения области цикла dev.

ПЛАН: Объединить данные изменения СВН с данными сложности клевера в отчет, показывающий влияние изменений на сложности или риск изменения (# линий х сложности = риск?). Это не идеально, но это может помочь командам лучше понять изменения.

Кто-нибудь попробовать? Если да, то какие инструменты вы использовали и как это помогло команде?

Answer 1

Мой опыт показывает, что тесты и риск (ы) идентифицируются при вводе новых функций или при устранении дефектов. Все это было сделано «вручную» на всех моих работах.

Ваша интересная идея - в основном тип плагина/компонента CI-сервера для фокусировки тестирования на основе статистики предыдущих дефектов и анализа сложности измененных файлов.

Вам, очевидно, потребуется карта кода/файлов для проверки случаев, и если у вас были обратные (неудавшиеся тестовые примеры и файлы, которые были изменены для исправления), у вас был бы некоторый автомат, способный генерировать некоторые из этих Информация.

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