Toronto VS ALM User Group kick off meeting April 12th

The first Toronto VS ALM User Group kick off meeting is being held on April 12th @6:30pm sign up at TALMUG to get the details and register.

The User Group is for all roles within the Application Life Management team. Topics presented will vary from generic ALM practices to ALM with Visual Studio. If your involved in product management, a stakeholder, a business analysis or product owner, a developer or a tester this User Group is for you.

The goal of the first meeting will be to:

  • Define the group’s mission
  • Select an appropriate name
  • Document the roles of the executive
  • Recruit volunteers
  • Funding
  • Discuss how to reach out for sponsors
  • Discuss meeting locations
  • Discuss ideas for the first few meeting topics

Come out on April 12th and help us to kick-off this new user group code named TALMUG.

Testa Smile

Editing a Build Process

If you want to edit your build process and utilize some of the custom activities in the  Community TFS Build Extensions. You may be finding it tough to drag the activity into your Workflow. Or Intellisense may not be working like you saw in that demo. Below are the steps to help you create a project to store your custom build processes and easily edit them.

First Download the Community TFS Build Extensions and copy them into a folder in source control. I like to put them in a folder under the BuildProcessTemplates folder created from your Process Template, called Custom Activities.

For example: $/ObjectSharp Projects/BuildProcessTemplates/CustomActivities

You need to make sure the build server knows where to find these so Change the Build Controller property Version control path to custom assemblies to this location in source control. You can get to it by right clicking on the Builds node in Team Explorer and selecting Manage Build Controllers. Select the Controller and click the properties button.

Make a copy of the Build Process Template that you want to edit and make sure it’s in the BuildProcessTemplates folder under source control.

  • Add the Custom activities to your toolbox.

in Visual Studio select Tools | Choose Toolbox Items… from the main menu.

On the System.Activities Components tab browse for the TFSBuildExtentions.Activities.dll and add it.

  • Create a new Class Library Project

Delete the Class1.cs that gets created.

Add the following references to the project:

From the .Net tab on the Add Reference dialog:
Microsoft.TeamFoundation
Microsoft.TeamFoundation.Build.Client
Microsoft.TeamFoundation.VersionControl.Client
Microsoft.TeamFoundation.VersionControl.Common
System.Activities

From C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
Microsoft.TeamFoundation.Build.Workflow.dll
Microsoft.TeamFoundation.TestImpact.BuildIntegration.dll
From where ever you installed it on your machine
TFSBuildExtensions.Activities

  • Add the Build Process Template to the project.

Right click on the project and select Add | Existing Item… from the context menu.
Navigate to the build process template you want to edit 
Click on the arrow next to the add button to select Add As Link

Now you can work on your build process in place from within a project so you have all the references you need to drag activities in and have the benefit of intelitrace.

Creating a Custom Link Tab for your TFS Work Item

Each work item in TFS contains an All Links Tab where you can see all the links to this work item grouped by relationship type.

There are other tabs that just show specific links like Implementation, Change Requests, Test Cases. These tabs are filtered to only show certain types of relationships and the work items that can have this relationship.

It’s very easy to create your own Tab that shows specific links and the work item types that you want the user to include.

As an example lets create a Review Tab on the Requirement work item in the CMMI Process Template so we can see the Design Reviews associated to this requirement.

Open up the CMMI process template using the Process Template editor that comes with the TFS Powertools.

Lets create a custom link type to be used for Reviews. From the Process Editor select Methodology | Work Item Tracking | Link Types and click the new Button. Fill in the New Link type to represent a  Reviewed By/Reviews relationship.

Save the Link Type and open the Requirement Work Item type editor.

In the Layout tab right click on the TabGroup node and select New Tab Page from the context Menu. You can right click on that new tab page and select Move Up or Move Down to change it’s order in the Tab control.

Change the Label on the New Tab Page to Reviewed By.

Right click on the Tab Page – Reviewed By and select New Control. Fill in the Control property grid with label, name and type information.

Now select the Control Settings field and click on the button in that field with the ellipses.

From here you can control the links that can be added and viewed with this control.

There are three filters that can be applied.

Work Item Type Filters: Allows you to select the type of work items the can be selected. You can choose to Include All work item types or Include/Exclude a subset of them. For our example we will select Include and check the Review Work item Type.

Work Item Link Filters: Allow you to force a specific work item link type. You can include/exclude all or include/exclude a subset. For our example we’ll Include the new Reviewed By link type we created.

External Link Filters: These are for the non work item links. You can include or Exclude the following external link types.

Fixed in Changeset
Result Attachment
Source Code File
Test Result
Workitem Hyperlink

See my blog entry on Requirements in TFS for an example on using the External Links.

For our example we will set this to Exclude All this way none of the external links will be allowed.

You can also select what columns you would like to show in the list of related work items. I’ll add Called By and Called Date to the selected Columns.

Now with a project created from this process template the Requirement will have a Reviewed By tab that allows users to add Reviews with the link type Reviewed By.

 

Looking for tester who can create Unit Tests – What?

In the blog Functional/System testing with Visual Studio/Test Manager we talked about unit testing. Testers in the near future are going to need unit testing skills. Now that is a very scary statement given 70% of testing is done manually. Now is the time to start learning by taking programming courses, unit testing courses, pairing with developers to learn and searching the web.

In the Visual Studio magazine Jeff Levinson article Take Unit Testing to the Next Level talks about how to add unit tests to requirements to show test coverage. Jeff supplies code you can download and instructions on creating simple unit tests then how to link them to requirements. If you have Visual Studio give it a try.

Thanks Jeff

 Testa Smile 

Agile book pre order deal – Software in 30 Days

New Agile book by Ken Schwaber and Jeff Sutherland can be pre-ordered at Amazon for a great discounted price.

About the book from Amazon:

A radical approach to getting IT projects done faster and cheaper than anyone thinks possible

Software in 30 Days summarizes the Agile and Scrum software development method, which allows creation of game-changing software, in just 30 days. Projects that use it are three times more successful than those that don't. Software in 30 Days is for the business manager, the entrepreneur, the product development manager, or IT manager who wants to develop software better and faster than they now believe possible. Learn how this unorthodox process works, how to get started, and how to succeed. Control risk, manage projects, and have your people succeed with simple but profound shifts in the thinking.

The authors explain powerful concepts such as the art of the possible, bottom-up intelligence, and why it's good to fail early—all with no risk greater than thirty days.

I highly recommend reading this book.

Testa Smile

 

Requirements Traceability in Visual Studio

Team Foundation Server (TFS) and Visual Studio(VS) excels when it comes to requirements traceability. Depending on what process you are using in TFS your stakeholders needs are documented in a work item called one of the following: requirements, user stories, use cases or backlog items. For this blog I am using the term requirement.

What is requirements traceability?

Continuous knowledge of the life of a requirement from conception to creation to design to development to verification to implementation and change. The ability to trace a requirements state and/or status at any time during a project.

First step in making requirements traceable.

In Visual Studio other work items are used to identify work that needs to be done to a requirement before it can be deemed done. There are different work item types depending on the process template you are using, however all contain the following: Task, Test Case, Shared Step, Bug. Additional work items can be added if not in your process template like Review, Issue, Change Request to name just a few. All these work items can be linked to the requirement they are helping to fulfill. Visual Studio 2010 introduced the concept of hierarchy by which a work item is linked to another work item using a linked type. The work item task is a child of a requirement, two requirements can be related, a test case tests a requirement. Work items like tasks may be linked to show predecessor or successor of another task. To learn more about choosing link types to effectively track your project click here MSDN Library.

Linked type listing:

image

Example of a requirement with linked work items:

image

What can be traced?

In Visual Studio during diagram modeling requirements and other work item types can be attached to objects in the model. During modeling you can either create or link requirements. This allows you to trace work items like requirements from a model diagram.

Example of a Use Case model with requirements linked:

image

Within the requirement work item I can see all other linked work items and information about them like state, assigned to. Knowing the state of work items linked to a requirement tells me the state and status of the actual requirement itself.

Development when checking in code to VS source control can be forced to associate what requirement or other work item their code relates too. Code check-ins create a Change Set that contains information about the check in and gets linked to the work item(s) associated during a check-in. When fixing bugs this is a nice feature.

In Visual Studio I can create queries to show any type of traceability report. Examples: Requirements to Tests Matrix, Requirements to Tasks, Requirements to Issues, Test Cases with Bugs to name just a few. Queries can also be exported or opened in excel, sent to someone thru email or opened in Microsoft Project. Queries exported to excel allows for adding additional excel reporting features like a Pivot Charts.

Requirements to Test Matrix – is there test cases for each requirement

image

Visual Studio comes with many reports that trace Requirements showing linked tasks and remaining work left, test case results state and many more scenario’s. Remember depending on what process template you are working with will determine the reports you see.

Example:

image

Checkout MSDN library for lots more information on Requirements Traceability in TFS & VS.

Testa Smile

Functional/System testing with Visual Studio/Test Manager

If your reading this blog you likely understand what functional testing and you may use the term system testing.

Wikipedia defines these terms as:

System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic”

Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.”

If you have read Agile Software Engineering with Visual Studio (by Sam Guckenheimer & Neno Loje) you will have heard about “reducing waste”. Identified as tasks that reduce waste are functional and system testing. These two tasks can be done during code development through unit tests reducing the cost of bug fixes, bug analysis, creating a suite of automated tests and automated regressions tests and reducing the number of people involved in testing and the bug. In some teams developers and testers have been testing the same thing one through unit tests and then again later by a testers. This is duplication of work effort that is a expensive waste.

In Visual Studio there are unit testing tools and third party add in tools that developers can use to create very robust unit tests. You maybe thinking “the developers do not test the same “stuff” that testers do”. Your right, I agree. However since the team is encouraged to make changes to reduce waste why don’t we testers help them. In Visual Studio we can create test cases that are associated to the requirement/user story work item that describes what needs tested. We can pair up with developers to help them write robust unit tests to cover all the testing including boundary, error and data testing.

There are people that believe the future of the “software testers” is about to make a big change. Testers will need to be able to write and execute unit tests themselves therefore requiring the basics of coding and the ability to add assertions (validation) to the unit tests. (Check out MSDN’s Verifying Code by Using Unit Tests topics. ) I believe this will be a reality in the future but I also believe it will evolve.  If you want to start now pair up with your developers to help them create unit tests that execute both the “happy path” and boundaries of an individual method, class or component. Help them to create system integration tests. Getting expose to how unit tests are designed and coded will help you move into the future. In addition having knowledge of what has been unit tested reduces test duplication later. TFS and Visual Studio help us with all this through work item traceability.

Example of work item traceability:

image

Example of a Test Case and Associated Automation:

imageimage

Visual Studio has the tools that will help us move into the future with confidence and the security we’ll need. Humans in general are not adapt to change but change we must. I am one of those people that embraces change and excels in change but then I have had Visual Studio in my pocket!

- Kent Beck

The role of professional testing will inevitably change from “adult supervision” to something more closely resembling an amplifier for the communication between those who generally have a feeling for what the system must do and those who will make it do.

Kent Beck author of Test-Driven Development (Addison Wesley 2002), 86.

Visual Studio – my companion, my mentor, my stability, my aid, my reporter, my success

Testa Smile 

(stay tuned, next blog  I will show you how easy it is to create a unit test!)

Microsoft Update – Multi-line steps in test case

An update is available that includes the following:

Support for multi-line test steps in Microsoft Test Manager

Changes to the 2010 client to allow it to work with a TFS 11 Server

KB2522890 – Team Explorer Crashes when opening build from TFS 2008

KB2552300 - Gated Check-ins fail with the “Preserve local Changes” option

KB2561827 – DiffMerge closes with unhandled exception when comparing two files.

Here is the update: http://go.microsoft.com/fwlink/?LinkID=212065&clcid=0x409 

Testa Smile

Microsoft Lab Manager improvements in TFS11

Microsoft is making improvements to Lab Manager in TFS11. Brain Harry explains in this blog the primary addition of “Standard Environments” that enables the use of VM Ware with Lab Manager. Brian’s blog goes through how it all works and more.

Brain Harry’s blog.

Testa Smile

MTM - Test Case State and Reason fields

If you are using Microsoft Test Manager you will notice that the work item Test Case does not contain the field Reason. This statement really isn’t true, there is a reason and it is being set for you but not displayed.

The field Reason indicates why a work item is in a particular state. By default the reason field is being set.  States Active and Ready only have one reason which get sets by default for you. The state Closed has three options however since it is not displayed by default reason is be set to “Obsolete”. The other reasons available for the closed state are “Deferred” and “Duplicate”.

There maybe other reasons that you are closing a Test Case or setting the state to ready. One example is Test Case reviews. For this scenario you may want to add a reason that indicates the Test Case is in the state of ready “For Review” then a second “Review Done.

We can customize the available reasons but that is for another blog. Below are instructions on how to add the field Reason to display in your work item Test Case.

How do I get the field Reason to display:

1. In the main toolbar of Visual Studio select Tools > Work Item Types > Open WIT from Server

image

2. Connect to Team Project Collection window opens where you select the collection then click the Connect button.

3. Select Work Item Type window opens where you select a Team Project and the work item Test Case. Click Ok

image 

4. The Work Item Type editor opens as displayed below and you can scroll through to see all the fields available. Reason’s reference name is System.Reason and it is a string data type.

image

5. Click on the Layout tab where we will add the field Reason to the Test Case.

6. You are looking at a preview of the form layout. Find Group > Column > Group-State > Column. Right click on the second Column and select New Control.

7. The window pane to the right displays. Find Field Name in the adjoining cell click the dropdown arrow and select System.Reason from the listing. Find Label in it’s adjoining cell enter the label you want to display on the Test Case, likely Reason.

Under Column you will see Control – Reason added to the bottom of the listing you can move it up under Control-&State if you want. Where it is in this view is where it will display in the work item.

image

8. Save your changes and refresh TFS depending on how often TFS is being updated the field Reason will display as below in your Test Case work item.

image

Testa Smile