Development Matters Blog

Recently, the Merit Solutions’ Development Team has been using the Microsoft Visual Studio Scrum 1.0 template for TFS and it has proven to be a great improvement in leading a project based on the scrum methodology.

Artifacts from Microsoft Visual Studio Scrum 1.0 include work items, reports, and team queries, so the team can use them to track information, analyze progress, and make decisions.

This way all team members can easily track and update the project status. They can also be updated about all changes made and about progress of the other team members. Through the big range of work items, the team is allowed to track, monitor, and report the development progress of a product and its features.

All the artifacts can be accessed either from the team project node in Team Explorer or on the team project portal. 

The other benefit is the big range of reports which offers a capability to monitor team progress and velocity during the whole project. This is a great way to track how quickly the team has completed work or how much work remains in a product backlog or in a sprint backlog. It can also predict how much backlog effort your team can exert in future sprints if the team composition and sprint duration stay constant.

Using the Microsoft Visual Studio Scrum 1.0 template make tracking project progress easier and also gives our team a great opportunity to improve leading projects in future and predict the possible problems.

More info about Scrum 1.0 template for TFS can be found on MSDN.

Microsoft continues to provide new features which should help in defect prevention during the software development process. With the new Visual Studio 2010, you can check which builds have bug fixes, new features, new requirements or user stories added. Built-in test reports now cover test case progress, test plans and test results.

But the really cool new feature in the VSTS 2010 is that you can also view recommendations about which tests might have to be rerun, based on the effect of code changes that have been made to your application if you are using Test Impact Analysis when you run your tests. This is an additional feature for the code review implemented for the first time in Visual Studio 2008.

The whole process requires collecting test impact data per test. Test Impact Data is actual information about the methods called during the test execution. What is really important is that Visual Studio will collect Test Impact Data for both automated and manual tests, during the test execution using Test Runner. Therefore, the user doesn’t have to spend time exploring the application code. The links between methods in the application and the test cases are stored to determine which test cases should be recommended to run again based on the changes to the methods.  This actually means that this feature will help in development from unit tests to manual tests and in both cases, the code analysis tool in the Visual Studio 2010 will shift user’s focus to the testing of the updated code.

If you have implemented Continuous Integration rather than running a build with a huge portion of tests you probably have a problem as it takes way too long to run frequently. If that’s the case, many administrators choose to exclude all – or a large number of tests – from the Continuous Integration, breaking a concept of the end-to-end builds process. The only remaining impact is Build Verification. By applying this mechanism in the TFS, the team should get a repeatable and reliable method to create a regularly available public build.

On the other hand, the developer is free to choose between a subset of tests (those that need to be run based on the code changes made) or running the entire suite of tests. This feature will point to both testers and developers what needs to be tested and which tests need to be run, especially since the test team often struggles with the details of what has been changed. Test Impact Analysis has a powerful mechanism to identify all changed points in order to help testers identify which tests need to be run in order to validate the new build.

Although, an investment in this feature increases maintenance time and requires a decent level of discipline within the development team, cost of the Test Impact Analysis implemented like this is significantly lower than benefits that team will gain.