Как тестировать только то что нужно

Ручное тестирование — это кропотливый и порой рутинный процесс. Одной из проблем является то что при внесении изменений программистами в код достаточно сложно предсказать то, какие тесты следует проделать заново, чтобы убедиться, что все работает так как следует. Обычно для этого прибегают к регрессионному тестированию и повторному прогону всех тестов которые уже были проделаны. Такие операции требуют много времени. Но если вы разрабатываете свои решения на платформе .NET то у вас есть шанс значительно снизить трудозатраты тестировщиков на эти операции, потому что вы будете точно знать, какие тесты следует провести а какие нет, так как изменения в коде не затронули их поведение. Звучит заманчиво?

Инструментальная обработка кода и Test Impact.

Изменения, которые программисты вносят в код приложения, при наличии системы контроля версий и процесса непрерывной интеграции, могут быть четко идентифицированы. При этом если проводить тесты от билда к билду, то благодаря анализу информации Code Coverage ручных тестов и ее сохранению для каждого пройденного тестового плана, мы можем четко предсказать то какой тест сломался, а какие тесты вообще не затронуты изменениями, которые внесли программисты. Это на первый взгляд весьма фантастично, но тем не менее уже работает в связке с Team Foundation Server 2013 и Microsoft Test Manager 2013.

Подробный сценарий, чтобы все стало понятно.

Рассмотрим на примере калькулятора подробный сценарий. В Microsoft Test Manager у нас определен основной тестовый план, и для каждого PBI соответствующие тесты функций:

В настройках тестов обязательно указано что при прогоне тестов у нас будет проводится анализ Test Impact:

Дополнительно обязательно укажем эту же опцию в правилах сборки билда:

Собираем билд и начинаем тестировать наше приложение согласно плана:

Это первая сборка нашего продукта, очевидно, что мы должны проделать все тесты чтобы убедится, что все работает так как надо. При прохождении тестов Microsoft Test Manager анализирует пути исполнения кода соответствующие каждому тесту и записывает эту информацию в базу данных.
Проходим все тесты фич нашего продукта:

У нас в плане 4 теста, умножение, деление, вычитание и сложение. В окне результатов видим что мы проверили все фичи нашего калькулятора и прошли все тесты плана:

Вносим изменения в код

Представим теперь что в каком-то участке кода нашего решения программисты внесли изменения. Пусть это будут функции умножения и деления:

Делаем чекин и собираем новый билд. Его будут проверять тестеры. После сборки билда в отчете помимо стандартной информации о том сколько пройдено модульных тестов, каков процент Code Coverage так же мы получаем информацию о том какие тесты были затронуты. Настоящая магия!

Помимо информации в отчете, тестировщик так же может получить список затронутых тестов прямо в Microsoft Test Manager. Прежде чем получить список рекомендованных тестов, назначим тестовому плану новый билд. При этом нам будет дана рекомендация по анализу перечня рекомендованных тестов:

При этом у тестировщика есть возможность делать анализ рекомендованных тестов от билда к билду:

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