How To Work with Team System using MSProject - Introduction

After we have finished with the Excel guide its time to deal with the MSProject.

Team System is integrated with MSProject which gives the user the ability to use all the grate features of the MSProject and still work directly with the TFS (Team Foundation Server), for example lets say that I have a project gantt already built in the MSProject, instead of adding new tasks to the system one by one I can do it with one click of a button, all tasks and there data will be entered to the Team System as new work items.

It is important to mention here that the Team System is not replacing the MSProject, the Team System is adding capabilities to the MSProject and the MSProject is adding capabilities to the Team System.
why is it that important to say that here?
The way we work with the MSProject is different than the way we work with the Excel, when we use the MSProject we work with the same project file, we update both ways all the time: the project and the TFS, this will be clearer later in the guide.

When I look at my customers using the Team System I see users that don't really understand the full potential that is hidden in this grate tool so for them and for all the rest of our readers I decided to dedicate this blog post and 4 of my future blog posts to write a guide that will (hopefully) cover the main features.

These days I am participating in a unique project at one of our customers sites, the project is a beta implementation of the Team System code name "Rosario" (Team System 2010).
Unfortunately I can't talk about any of the things we are doing there but I like to dedicate the last post of this guide to the "Rosario" new features.
All features that I will show in this post are already available in the CTP of the "Rosario" that is already released so you can start evaluating them.

These are the blog posts subjects:

1. Introduction - This is the current blog post that opens the guide. 
2. Export to MSProject - I will show different ways to export work items from the Team explorer to MSProject.
3. Publish and Refresh - I will explain how to Publish and to deal with publish problems, I will also explain how to refresh the data.
4. Get Work items - I will show how we can change the list of work items so you will have better control over your items.
5. Rosario: Links in MSProject - I will show how to add children to items and how it is shown in the MSProject, I will also show the predecessor/Successor link type.

See you on the next post...

What is "Static Testing"?

Many times when I go to a client and tell him that his QA team needs to start at the beginning of the project's development process I see a wondering look at his eyes.

A good QA process needs to start as early as possible in the development process, the type of testing that is being done at that early stage called "Static Testing".

"Static Testing" is basically documentation testing and code testing but without using the software, for example "Code Reviews", when the software is used for testing it is called "Dynamic Testing".

In this post I will focus on the "Static Testing" of the requirements only.

Why should we test the requirements?

Research shows that over 80% of the bugs are introduced before a single line of code is written.

If we think of that it make sense, how can a developer write a good application if the requirements are faulted? How can a tester test the application if he doesn't know what exactly to test? How the user can finally get what he needs if the developers don't know what exactly to develop?

So we can see that the base for the product's quality starts with good requirements.

I don't say that this is the only parameter for good quality, but it is the most influencing parameter and that people don't know.

Now we have a new question coming:
Why the QA team should test the requirements?

The QA team member has a very unique view, the QA team member can see that the requirement is testable, he can see if the requirement is well defined and he can put himself in the user's shoes by that he can spot usability problems before a single line of code is written.

Important: I don't say that the QA team members are the only people that will test the requirements but they must be in the list of people that tests the requirements.

We can see that the QA team member needs to have a wide knowledge in many fields, one of them is requirements and documentation.

How To Work with Team System using Excel - Rosario: Generate Reports

This post is the seventh and last post that builds the Excel Guide. See the first post here

On this post I will show how using the Excel you can create reports with a click of a button, it is important to mention that you need to have the rights on the reporting services server in order to create reports.

In the Rosario you don't need to be an expert in order to create a very impressive reports, just follow these simple steps:

Step 1: Create a query in order to have more accurate reports, the query must be flat means that you don't use the second part of the query builder (Query on links).
Impotent: You will need to add columns to the Results window by right clicking on one of the Results window columns and choose the "Column Options..." (Second screen shot) don't leave the defaults (ID and Title) I have added the "Assigned To" field for this example.

Note: Creating a query is out of the scope of this post.

Step 2: Open a new Excel document and click on the "Team" tab.

Step 3: Click on the "New Report" button.

Step 4: Choose a Team Project and click "OK"

Step 5: Choose a Query and click "Next"

Step 6: Check the checkboxes next to the reports you like to produce and click the "Finish" button.

Now that you have the reports, treat them like a regular pivot tables of the Excel, use the Pivot Table Fields List window to make changes.

That was my last post of the Excel guide, I will be glad to get your comments (Good or Bad), see you all on my next post.