How to test only what you need

Manual testing is a painstaking and sometimes routine process. One of the problems is that when making changes to the code, it is difficult to predict which tests should be done again to make sure that everything works as it should. To do this, resort to regression testing and re-run all the tests. Such operations are time consuming. But if you are developing your solutions on the .NET platform, then you have a chance to significantly reduce the labor costs of testers, because you will know exactly which tests should be carried out and which are not , since changes in the code did not affect their behavior. Sounds tempting?

Instrumental code processing and Test Impact.

Changes that programmers make to the application code, with a version control system and a continuous integration process, can be clearly identified. At the same time, if we conduct tests from build to build, thanks to the analysis of Code Coverage information from manual tests and its preservation for each test plan passed, we can clearly predict which test broke and which tests are not affected by the changes that the programmers made. This is quite fantastic at first glance, but nevertheless it already works in conjunction with Team Foundation Server 2013 and Microsoft Test Manager 2013.

A detailed scenario to make everything clear.

Consider a detailed scenario using a calculator as an example. In Microsoft Test Manager, we have defined a basic test plan, and for each PBI the corresponding function tests:


In the test settings, it is indicated that when running the tests we will analyze Test Impact:


Additionally, we must specify the same option in the build rules of the build: Build the


build and we start testing our application according to the plan:

This is the first assembly of our product, it is obvious that we must do all the tests to make sure that everything works as it should. When passing the tests, Microsoft Test Manager analyzes the code execution paths corresponding to each test and writes this information to the database.
We pass all tests of features of our product:


We have 4 tests in the plan, multiplication, division, subtraction and addition. In the results window, we see that we checked all the features of our calculator and passed all the tests of the plan:

Make changes to the code

Imagine now that in some part of the code of our solution, programmers made changes. Let these be the functions of multiplication and division:


We make a check and collect a new build. It will be checked by testers. After assembling the build in the report, in addition to the standard information about how many unit tests passed, what is the percentage of Code Coverage, we also get information about which tests were affected. Real magic!


In addition to the information in the report, the tester can also get a list of affected tests directly in Microsoft Test Manager. Before receiving the list of recommended tests, we will assign a new build to the test plan. At the same time, we will be given a recommendation to analyze the list of recommended tests:


In this case, the tester has the opportunity to analyze the recommended tests from build to build:


Thus, the tester can significantly save time on checking the build, and conduct only those tests that were subject to changes made by programmers in the application code.