Adding/modifying work items in Team Foundation Server -Part 2

In the previous blog I explained how to create a 'Steps to reproduce' control. Lets now add this control to default Bug Work Item (WI). In this case, I want to add 'Steps to reproduce' as a new tab.

If you go to the Layout tab, you will get something like the following image

It is easy to read. The TabGroup refers to tab structure that previously I have qualified as not meeting the tester’s needs. Now that we have created the 'Steps to Reproduce' control, we can add it to the layout.

To add a new tab element, right Click the ‘TabGroup’ folder and choose ‘New Tab Page’. A new ‘Tab Page-New Tab Page’ element will appear at the bottom of the ‘TabGroup’ list. On the right pane, change the label to something more meaningful, for example ‘Steps to Reproduce’. Note: this simply adds a new container, in this case a tab, where we can place control.

Now, we are going to add the previously created 'Steps to reproduce' control we created in the first part of this tutorial to this new tab. To add this control to the tab, right click the ‘TabPage- Steps to Reproduce’ and choose ‘New Control’. The property pane appears, change the label to ‘Steps to Reproduce’, and choose the Visiphor.Steps we created for the field Name field.

Accept everything, and if you click the ‘Preview Form’ button, you will get the ‘Steps to reproduce’ tab added to the tabs section

If you want to move this tab to be the first, right click the ‘TabPage – Steps to Reproduce’ folder and ‘Move Up’ as many times you want.

At the end, you can build a bug work item like

That fits much better my needs as a tester!

Notice the new tab 'Steps to reproduce' contains the control 'Steps to reproduce'

Hope it will work well for you too.

Adding/modifying work items in Team Foundation Server -Part 1

As most of you in the trade will know, Microsoft released in 2006 Team Foundation Server (TFS), a new product/tool that allows testers, developers and architects to work together using Visual Studio as its GUI. In this way, a seamless environment will be created where all these roles can work together, or at least this is what the Sales&Marketing department would like us to believe. In the practice, this level of integration is some iterations away.

TFS out of the box include two approaches: CMMI and Agile. In both of them it has the concept of work items (WI), among them, it has a WI named 'Bugs'. Unfortunately, I find the Bug WI included in these templates not very useful. So, if you want to create a new Bug WI in TFS with the product as it is out of the box, you will get the following

Enlarging the tab section (apologies for the bad quality of some of the images...)

As a tester I am surprised to see how 'developer' oriented is this interface. For example: I couldn't care less about the fix, however, however, I think it is very important to describe the steps to reproduce the bug. This is a single example... there are several more fields/tabs I would like to see that are not there by default!.

So, how you manage to customize TFS to your needs? This blog will guide you to the process of creating/editing work items.

First you need to have Visual Studio 2005 on your machine. Then, you will need to download the following tools from Microsoft:

http://go.microsoft.com/?linkid=6270225
http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx

The tool properly is the second link, but you need the components included in the first.

Once is installed, you will be able to access the documentation, that is pretty clear. You access the documentation from Start>All Programs>Microsoft Team Foundation Server Power Tools>Microsoft Visual Studio Team System Process Editor>PEUserGuide.doc

If you want to modify a WI, from Visual Studio you select the menu item Team>Process Editor>Work Item Types>Open WIT from Server

You will get the following interface

In this case, 'Add' a new control (controls in the .NET sense, like text boxes, drop down...) with type Plain Text. The reference name used in this case is Visiphor.Steps, the first part is the namespace used internally and the second part anything you want. For this example, I have created a new control named 'Steps to reproduce.

The second part of this article will refer of how to add this control to a WI.

Second part of the list, as promised! I feel a bit less strongly about the recommendations in this second list. In some cases, I would advise a 'menu approach' that will allow the team to pick and choose.

As before any omments, suggestions and real life stories will be most certainly welcomed!

Action	Description	Who is responsible?	Phase
Code Coverage	The new Visual Studio suite offers the possibility to explore all the possible paths of a piece of code. If all the lines of code are executed at least once in a test environment, it is less probable that they will contain critical errors. Also, if there are areas of the code that are never accessed, it would point to areas where maintenance can be compromised.	Developers	Development
Tracing requirements to Use Cases/Test Cases	This would add overhead to the QA operation, however, it may help to keep all the requirements in sight and also limit their scope	Tester/PM	Planning, Development, Stabilization
Sign on at each milestone.	My proposal would be that at each milestone the PM MUST send an email to the team announcing it. This means that a change in design (Planning) after the ending of the Planning phase will not affect developing. The change will affect next iteration (Thinking in MSF context). This may seem draconian, but may help architects, PM and Customer to be more conscious when they are breaking the process.	PM	End of each phase inside the iteration
No switching of resources	Every time that resources are brought in/out of the project, there is a learning curve and information that is lost. A project with a big resource turn-over risks to have a larger amount of undetected issues	PM	All phases
Representative Test environment	Sometimes, due to the complexity and expense of the production system, the test environment is significantly different from the Production Environment. If the environment are similar, the test effort twill be much more accurate	PM, System Engineering, Testing	Stabilization
Risk Management	Core to the MSF, it should include the customer/customer representative. The extra overhead is well compensated by the managed approach to problem when, if they, appear.	PM, Everybody	All phases
Real and represenative test Data	If the customer supplies real and representative test data, it is easier and more probable to spot problems/code deficiencies during the test process	PM, Testing	Development, stabilization
Customer agreement on quality	Customer should take an active role defining what they expect of the product.	PM	Envisioning
Formal Security Review (if applicable)	For project that require a high level of security, in addition to the usual test procedures –encryption, use of certificates, users rights…- it also should be submitted to deliberate attacks to try to break into the application	Sys Eng/Testing	Planning, stabilization, deployment
Cross disciplinary Peer review of documents	This could identify issues that are more obvious to another team.	Everybody	All phases