Do not give [free] honest advice/assesment in job interviews

Ok, this is a rant, so feel free to skip it!

About a year ago I had a job interview for a contract position. The project was complex, ill organized and with high probability of failure. A brief description of the project is:

Company A starts a job for a customer. They were going to adapt their exisiting product, based on US business processes, to the Canadian business processes. After a year, and no progress, company B purchases company A. Another year pass with nothing to show. It is now two years after the project has begun and the customer still has nothing. When company B realizes the mess, decides to cut their loses and hires company C to finish the project. Customer sets up a team to speed the project that will coordinate internal resouces with company C, who incidentlly are located in a different time zone.

At this stage I interviewed for the QA position in the coordinating team. Among other responsibilities, it includes testing the code that Company C is producing. There were no procedures, vague specs and the group of developers used the word Agile methodoly to describe what is a cowboy approach. The PM, working for the customer, has no carrot no stick over company B or company C. My assesment of the situation was somehow bleak, and I proposed measures like change control, regular risk meetings, clearly defined [and achievable] goals for each iteration... I know I sounded a bit negative, but definitely I didn't wanted to sound like all was fine: it wasn't.

A year later, and because Vancouver is an small IT town, I have learnt they hired another person that had 'Don't worry, be happy' as mantra. Six month after the hiring the PM realized it was not working. So, they started to do risk meetings, put in place a change control and each iteration has a small number of features that had to be implemented. It has took over three year for the customer to have something that is operational and can be put into production.

Conclusion: next time I want the job I need to smile, assuage all fears with 'It's going to be fine' and send a bill for any advice I may give during the interview.

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.