Visual Studio 2010 and Testing

February 14, 2010

Last week I delivered for Microsoft Belgium a full day technical seminar on testing with Visual Studio 2010. More than 20 people showed up and the attendees were an interesting mix of dedicated testers with none or little knowledge of the Team Foundation Server platform and some developer oriented profiles with little knowledge in the testing area.

While preparing and delivering this course I became even more convinced that the testing offering with Visual Studio 2010 really rocks. Some specific testing features (manual testing with action recording, IntelliTrace, Test Impact Analysis, Coded UI Test, …) will be hard to miss once you get to use them in practice. Testers and developers will certainly be able to work more closely together to reduce the time it takes to find and fix software defects … and that’s what it’s all about in writing quality software!

All my demos did also work fine on the RC release of Visual Studio 2010, so I was pretty happy that I decided to prepare a RC image to use for the course.

I definitely need to blog about some of the cool collaboration stuff between development and testing teams. Note to self: free up some time!

Slidedeck is available at the download section.

Scrum: How to deal with bugs during a Sprint?

February 1, 2010

Lately I got a question how a development team should deal with bugs which are found by the development team during a Sprint in progress?

In my opinion it’s not good to postpone fixing bugs to a later date or other Sprint. Bugs should always be fixed as soon as possible before other development work may continue. In the long run it will always be cheaper to fix bugs as they come. Putting them off to the (near) future may result in a more complex bug and will also require a larger context switch for the person who will be responsible for fixing the bug. Also make sure that bugs are visible for the entire development team. If you are using work items, be sure to create a work item for the new bug and enforce that the developer associates this work item to his check-in/changeset that will fix the bug. Maximum traceability! A good reflex to a new bug would also hold in to create a new (unit) test for regression testing in next releases.