Daily Archives: October 14, 2005

Improving Quality with Work Items

I’ve been doing quite a bit of work with Visual Studio Team System over the last two weeks from deploying it into a dual server environment, to creating intial Team Projects and migrating source code from SourceSafe. At the same time I’ve had the opportunity to see a development team get their head around using the tool.

It is still early days yet so I won’t ask them about their opinion of it yet, however, as they drive towards release of their first milestone they are hitting a few code quality speed bumps, although nothing out of the ordinary I suspect.

Given that they are using VSTS to manage their delivery I started thinking about how work items could be used to actively drive an increase in the quality of the code being written. One thing I came up with (and will present to the team on Monday) is being more explicit about testing expectations.

The idea is that when the development manager or technical lead schedules feature development work, they also sit down with the developer to spec out a series of unit tests that must be written.

At the end of this very quick chat two work items (tasks) are created. One which spells out what the feature is, and another that spells out in detail what each test scenario is. My hope is that this approach will reduce the number of surprises that arrive at the end of an iteration and potentially improve design.

This post by the The Braidy Tester illustrates just how this side-by-side scheduling of development and testing work can actually improve the design of the software.

By doing this with work items you essentially pin the developer down to achieving a pre-determined benchmark with code quality, and when they close the work item the development manager or technical lead can verify that the testing work has been done and wasn’t consumed by the general slippy nature of actuals against estimates.


ASP.NET and Team Build

For the last couple of days I have been having trouble getting ASP.NET 2.0 sites building under the new Team Build feature of Team Foundation Server in VSTS. Basically I would create a team project, create a solution, add a web-site to the solution, then check it all into the TFS source code control.

From there I would define a build and kick it off. The build itself would complete successfully but upon inspecting the drop location, it would be completely empty. Even more mystifying is that if I added a class library, or indeed any other project type (other than ASP.NET or setup projects) it would work perfectly.

The problem has to do with the default build configurations that ASP.NET dumps into the solution file (remember, ASP.NET doesn’t have project files anymore). It says that it is a Debug (or Release) build for the .NET platform. The problem? Well, the big build file (TFSBuild.proj) contains this little gem:

  1 <ConfigurationToBuild Include="Release|Any CPU">
  2 	<FlavorToBuild>Release</FlavorToBuild>
  3 	<PlatformToBuild>Any CPU</PlatformToBuild>
  4 </ConfigurationToBuild>

In this instance the build file needs to be changed slightly to allow ASP.NET projects to build correctly:

  1 <ConfigurationToBuild Include="Release|.NET">
  2 	<FlavorToBuild>Release</FlavorToBuild>
  3 	<PlatformToBuild>.NET</PlatformToBuild>
  4 </ConfigurationToBuild>

I am posting this information up to my blog because I found very little information on the web about this exact problem. Personally I consider it a bug in the (seriously flawed) ASP.NET 2.0 project system, but I’ll save that discussion for another post (in the meantime go and read this post by Scott Guthrie to understand their reasons for the change).