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.