Мы используем Vs2008 / 2010 с TFS 2010 для управления исходным кодом, поскольку он также позволяет нам создавать пользовательские типы рабочих элементов, которые мы можем использовать для управления проектами, такие как элементы журнала незавершенного производства и элементы журнала заданий спринта.
Один элемент, который не отслеживается (на машине), - это задачи регрессионного тестирования сборки для кандидатов на выпуск. Наше регрессионное тестирование частично автоматизировано, частично вручную, а ручное тестирование может занять несколько дней. В настоящее время мы используем таблицу Excel со списком всех тестовых случаев, а затем тестеры просто заполняют результаты и примечания.
Я предлагал создать шаблон регрессионного теста сборки, который содержит каждый тестовый случай, владельца по умолчанию, а затем, когда мы хотим провести регрессионное тестирование сборки, мы можем автоматически создавать рабочие элементы для каждого теста в шаблоне.
Мой аргумент заключается в том, что если работа по регрессионному тестированию является обязательной для проекта и результаты должны отслеживаться, тогда написание дополнительных рабочих элементов TFS имеет смысл, особенно потому, что рабочие элементы могут содержать оценки, давая руководителям представление о том, сколько время повторного тестирования остается.
Аргумент против этого заключается в том, что у нас уже есть рабочие элементы высокого уровня для сбора общих требований к тестированию проекта, и регрессионное тестирование - это в основном «повторное тестирование», поэтому новые рабочие элементы будут дублироваться.
Мой вопрос: кто-нибудь еще делает что-то подобное? Разумно ли использовать TFS для отслеживания нерешенных задач повторного тестирования?
Примечание: у нас нет Visual Studio Test Professional