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

Question

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

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

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

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

Answer 1

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

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

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

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