A few weeks ago during the MVP summit, I had the wonderful experience of hanging out with Martin Woodward of Teamprise and RadioTFS fame.  We chatted for an hour on strategies for adopting TFS successfully, recorded the conversation, and it has just been released as this months episode of Radio TFS.

Have a listen: Adopting Team System with Steven Borg

Between October 1, 2008 and December 31, 2008, active Gold and Certified CDS or ISV competency partners may purchase Visual Studio Team System 2008 Team Suite with MSDN Premium subscription at a 66% discount off retail price.

The offer is limited to one coupon redemption per company and no more than 35 copies of Team Suite per redemption.

Check out the details on the Microsoft Partner site and follow the contact information to get your exact pricing information from Microsoft.

Give Team Suite a whirl and unleash the full power of Visual Studio Team System.

Windows shell extension for source control, powershell integration, team collaboration tools (messaging, workspace templates, check in history, view shelvesets and pending changes, distribution of custom components).

This power tools release is huge and for some features it has been a long wait but I am so glad it is here.  Check out Brian Harry’s blog for some screen shots and a more detailed breakdown of all the new features.

Steven Borg of Northwest Cadence (Microsoft Team System MVP) took a road trip to Portland to speak to a very interested audience about the new features of Team Build 2008, an inherent and powerful part of Visual Studio Team System 2008. 

There were a total of 68 students from 35 different companies in the Portland area.  Feedback from the attendees on what they believe was most valuable:

• “How build automation with Team Build can replace or enhance our current in-house development   system”
• “Step by step demo of MS Build and overview of ways VSTS can help my organization”
• “Using Team Build for automated deployment”
• “Learning what Build can do for us”
• “Tasks that check in to TFS can be traced in the build.  This really simplifies debugging”
• “High level oversight so as to better see the big picture”
• “References to best practices when using TFS”
• “The integration of work items and code check ins.  Setting up continuous integration”
• “Customizing the Team Build project file”
• “Implementing database scripts in build reporting”

At the end of the presentation, there were several prizes up for grabs; however, two attendees were especially lucky as the recipients of Vista Ultimate and a Microsoft Zune Digital Player.  But I think it is safe to say, all attendees were winners as they were energized by the dynamic speakers and enlightened as to the abundance of Team Build’s bells and whistles.

Let’s look at each of the states so we understand what the state represents. And if this looks like the start of a new methodology, well, it is and it isn’t. It is because I’m going to detail out of this series of posts how to handle numerous items and there is a lot of methodology and process displayed here. But it isn’t because much of this is just common sense. Also, note that you do not need to implement every step. This process that I’m describing here can be scaled based on your needs.

The states and their descriptions are these:

Proposed

This state indicates that a reported bug has been received. It does not indicate that any action has been taken with regard to working on the reported bug.

The key item to note is the reason which in this case tells us what group filed the bug. This is important because as has already been noted, it costs more to fix a bug the later it is found in the process. This allows you to note where the bugs are found and determine where certain weaknesses lie.

Under Investigation

This state provides status to the end user to indicate that the bug report is currently being triaged.

The state transition provides us one very useful piece of information – the time it takes from the bug being received until someone starts working on it. This is the first of the areas where we find waste.

This state requires some work though – no free rides here. Several things need to happen:

1. A duplicate bug must be checked for. If a duplicate is found, then this bug needs to be closed and linked to the original bug report.

2. Find the test case that relates to the functionality at issue.

3. The analyst needs to determine what the correct functionality is supposed to be. If it works correctly (as designed) then what the user is actually reporting is a change request and a change request needs to be created. This bug can be closed and linked to the change request.

4. The bug needs to be reproduced. If it can’t be then it is closed.

5. If the bug can be reproduced, then the test case needs to be modified (or created).

What does this information provide us?

If the bug is a duplicate it means at least one thing and maybe two. First it means that this bug occurs in a commonly used piece of code and is therefore a cause for concern. Secondly, depending on the lag time between the original bug report being filed and the duplicate bug being filed may indicate that the bugs aren’t being fixed in a reasonable period of time.

If you cannot find the associated test case(s) then there is another issue. First, why was no test case created? Was it because this is in a less frequently used part of the system? If so, that may be acceptable (maybe it isn’t part of the normal path and so minimal testing was done on it), but it means that this part of the system is being used and additional test cases may need to be created to proactively identify any additional, related bugs. If you do find the test case, what about the test case missed the bug? Is there a gap in the test case? Are all paths not tested? Can you go back and review the code coverage report to see if there is a path through the code that was missed? These questions and their answers will help you proactively identify other areas in this particular area of code so you can take mitigating steps.

What if the functionality is as designed? The user is then requesting a change to the functionality – maybe. They may not understand how the functionality is supposed to work. But what does this tell you? Were the users trained in the correct use of the application? Is there online help for the application and is it effective? If the users haven’t been trained and you receive a high number of these items then maybe it’s time for a training class. If they have been trained and there is online help, then maybe the help isn’t effective or effectively integrated into the application. This may indicate that changes in those areas are needed – but only if you know what to look for.

If the bug can’t be reproduced, it must be closed. However, it must not drop off of the radar. When duplicate bugs are found you need to remember to check the closed bugs as well. If you find a number of non-reproducible bugs being duplicated, it may be time to activate the bug and try to have the developers spend some time investigating the situation.

Finally, if the bug is validated, that isn’t good enough. There needs to be a test case which shows what the correct behavior of the system is supposed to be so that the developers know when they are done fixing the bug and they have a way to verify that fix. If there is an existing test case and it is incorrect, then you need to look back at the requirements to determine if the test case was incorrect or whether the requirements were incorrect and make the appropriate changes (each of these points to a different area that needs to be looked at for improvement).

Investigation Complete

This state indicates that the bug report has been verified and is now an actual bug. And again, it provides a solid indication to the end user of the status of their bug report.

The transition from Under Investigation to Investigation Complete provides the first piece of information on work performed in order to fix the bug (after all, you can’t fix the bug until you have verified it).

At this point the assignment of work can commence. However, there may be a high number of work items to assign so it may be up to a Change Control Board (CCB) to accept and validate work for a release. If that is the case then the list of Investigation Complete items will make up part of the agenda. This however can present problems. See the section entitled “Waste” later in this chapter for the problems related to this and some ideas on how to fix them.

Assigned

This state is an indicator that the bug has been assigned to a developer for work.

This is called a buffer state. The transition between Investigation Complete and Assigned is basically unimportant. What is important is that this transition says is that you are planning to fix the bug. Now, what it doesn’t tell you is what release you are planning on fixing it in. Using TFS you can simply re-assign the bug to an appropriate future iteration. The assigned state also tells users that no one has started working on the bug yet. Additionally this state provides feedback to the CCB about what work is scheduled to be done but hasn’t started yet so the CCB doesn’t accept more bugs than can be reasonably fixed.

Active

This state indicates that the bug is actually being fixed. No bug must ever move to this state without having an accompanying test case.

This state isn’t as important as the transition to this state. The time between the bug being assigned and the bug being active is lag time and is therefore waste.

One of the activities that should be performed during this phase is the creation of a unit test to verify the existence of the bug in code. This will help create a large library of unit tests which target previous bugs which makes regression tests easier to run.

In this part I’ve started to describe what happens in each state and what information you can gather from each state. In the next post I will round out the steps in this particular process and then I’ll move on to discussing the benefits of the metrics. Note that this process covers virtually every type of metric you may need (there are a few it doesn’t cover but I’ll talk about that in the next post). Note also that you can pick and choose which states you want. For example, if you’re reasonably confident that you don’t have bugs sitting around for a long period of time, then maybe the early buffer states aren’t needed. Or if you aren’t sure where the problem is occurring, use broad categories and introduce additional steps to pinpoint a problem as needed.

Stay tuned for the next post!

Upcoming Team System Events

October 24: MVP TV: Gaze into the Crystal Ball: Reporting in Team System made Easy! (Webcast)

You’ve paid your nickel and it’s time to ask the Zoltar Fortune Teller for your future: “Is my software development project going down the toilet? Will I be able to ship on time, with high quality? Can I hit my budget?” (Wait, three questions = three nickels.) Zoltar says… Let’s face it, traditional status reporting is about as accurate as I am, and worse, it takes a whole lot longer!!! Team System can help! Its built in reporting capabilities provide a strong foundation for understanding the current status of your project. Not only does it provide a series of built in reports, it gathers the metrics to allow for excellent ad-hoc reports! Using both the built in and ad hoc report capabilities, finding the current status of your project, and predicting your project’s probability of success or failure along several axis. Come learn how to predict your future! You’ll learn how to interpret the build in reports, learn what’s required to create the reports, and how to use Excel pivot tables to connect to the TFS cube for ad hoc reporting.

To register, go to: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032391376&EventCategory=4&culture=en-US&CountryCode=US

November 5: Enterprise Build Automation w/VSTS 2008 Team System & Team Build (Portland)

Steven Borg of Northwest Cadence (Microsoft Team System MVP) will be covering some of the great new features of Team Build 2008, an inherent and powerful part of Visual Studio Team System 2008. You’ll learn to use Team Build 2008 to radically improve your code!

Come see real unit and functional tests being built, real code metrics being generated, and real work being done in an automated build. You’ll learn how to build legacy code, run tests and code metrics, rebuild your database, update your documentation, and even deploy your application into various test environments; all coordinated by a single command.

To register, go to: http://www.clicktoattend.com/?id=132684

November 15-16, 2008: Code Camp

Join Northwest Cadence and others at Code Camp where developers talk with – and learn from – fellow developers.  It is a community event and all are welcome to attend and speak.  Code Camps have been wildly successful, and we are excited to participate in this success in Seattle.  Check out https://seattle.codecamp.us for more details.

November 18: Coffee Talk – Welcome. Help Us Set the Stage! (Webcast)

We’ll briefly cover VSTS, ALM, and introduce you to the coffee talks.  Bring your questions, desires and needs.  We’ll have some fun, answer questions, and plan topics for future coffee talks.

To register, go to: http://www.clicktoattend.com/?id=132790

December 2: Coffee Talk – Visual Studio 2010 (Webcast)

You may have seen some of the fantastic new features of Visual Studio Team System 2010 (aka Rosario).  Drastically improved automated testing, architect tools that actually work, and tons of improvements to make your lives easier and time spent more productive.  We’ll cover several of the new features, and answer questions about the things you’re looking forward to.  Bring your own questions, too!

To register, go to: http://www.clicktoattend.com/?id=132791

December 4: Eagerly Awaiting VSTS 2010? (Kirkland)

Join Northwest Cadence and explore the new features of Visual Studio Team System 2010 and what it means for your business, productivity, application management, and quality. During this event, we will cover Team Foundation Server and the much-hyped hierarchical work items, new improvements to History, Merge, Work Item Queries, and the focus on Agile development.

Numerous improvements from the Architecture edition (including full support for UML 2.x) will be demonstrated, including the new Architecture Explorer which allows you to quickly and easily visualize an application from the high level down to the object dependencies. We will also highlight many Developer edition functionalities such as updated tools for performance profiling, the Historical Debugger (formerly called “Proteus”), and the ability to view affected tests based on changes to the code. Finally, we will cover the Test Edition with a focus on the “Camano” user interface, Manual Test Runner, Test Case Management, and how Team System 2010 is a strong and reliable testing platform.

To register, go to: http://www.clicktoattend.com/?id=132801

December 16: Coffee Talk – Reporting (webcast)

You may have seen some of the fantastic reports TFS provides out of the box at conferences and presentations.  We will answer lots of questions in this session: Have you wondered why the reports at your company don’t look quite as nice?  Are they missing enough data to make decisions?    What reports should you pay special attention to (Project Managers), and why should you even care about the reports (developers)?   We will also cover a few of things you need to do to really get the data into the reports and talk about how to interpret some of our favorite reports.  And, if you ask, we’ll cover how to interpret your favorites, too!

To register, go to: http://www.clicktoattend.com/?id=132792

December 30: Coffee Talk – Software Development Lifecycle

With the thousands of books and articles published on Software Development Life-Cycle (SDLC), do you ever feel overwhelmed sorting through what is hype vs. what is actually being adopted by .NET corporations?  During this Coffee Talk, we will answer this question plus others that you bring!  We will explore the complexity of software development, the current best practices for improving your Software Development Life Cycle, and industry best practices and the latest IT research.

To register, go to: http://www.clicktoattend.com/?id=132794

January 8: Eagerly Awaiting VSTS 2010? (Portland)

Join Northwest Cadence and explore the new features of Visual Studio Team System 2010 and what it means for your business, productivity, application management, and quality. During this event, we will cover Team Foundation Server and the much-hyped hierarchical work items, new improvements to History, Merge, Work Item Queries, and the focus on Agile development.

Numerous improvements from the Architecture edition (including full support for UML 2.x) will be demonstrated, including the new Architecture Explorer which allows you to quickly and easily visualize an application from the high level down to the object dependencies. We will also highlight many Developer edition functionalities such as updated tools for performance profiling, the Historical Debugger (formerly called “Proteus”), and the ability to view affected tests based on changes to the code. Finally, we will cover the Test Edition with a focus on the “Camano” user interface, Manual Test Runner, Test Case Management, and how Team System 2010 is a strong and reliable testing platform.

To register, go to: http://www.clicktoattend.com/?id=1328012

Here’s a brief blurb.  To learn more, send an email to info@nwcadence.com.

The focus of this training course is on the effective use of Team System to improve an organization’s application management lifecycle. Software teams will learn not only how to use Team System effectively, but how to use Team System to improve their software development process. Developers will learn improve the quality of their code and speed development. Testers will learn to validate code quality and track test cases. Project managers will learn to use Team System to bring their projects under control. Configuration Managers will learn the best practices around branching strategies and will learn to create a tailored software configuration management strategy. As a team, you will learn how to use TFS to increase traceability, improve the quality of your code and ease the process of releasing your applications.

Here’s the invite:

Enterprise Build Automation with VSTS 2008 Team System and Team Build

Steven Borg of Northwest Cadence (Microsoft Team System MVP) will be covering some of the great new features of Team Build 2008, an inherent and powerful part of Visual Studio Team System 2008. You’ll learn to use Team Build 2008 to radically improve your code!

Come see real unit and functional tests being built, real code metrics being generated, and real work being done in an automated build. You’ll learn how to build legacy code, run tests and code metrics, rebuild your database, update your documentation, and even deploy your application into various test environments; all coordinated by a single command.

This seminar is intended to provide demonstrations that will be most relevant to developers, testers, build and release engineers.

Date: November 5, 2008

Time: 9am – noon

Location: Microsoft Corporation, 10260 SW Greenburg Rd, Suite 600, Portland, OR 97223

To register:

http://www.clicktoattend.com/?id=132684

Take advantage of this offer – especially if you own the Development Edition as the Database Edition provides numerous advantages.

Enjoy!