Rosario Preview #4: Tester Edition

Visual Studio Team System Code Name "Rosario" Test Edition provides new functionality that lets you easily create, manage, edit and run manual tests. Read about manual tests here.

The new Tester Edition is a great tool that addresses the needs of the UI testers.  This post is a preview of the main features in this edition.

Planning a Testing Effort

Camano is a standalone application that allows users the ability to author, plan and manage a testing effort from a simple UI specialized for displaying test artifacts.  Planning a testing effort gives you the ability to manage your manual testing efforts and report on your progress. By using this functionality, you can create test plans that show what you plan to test for a specified period of time. Also, you can create test configurations that specify the test environments for your tests.

Camano’s main window

(Click on the pictures to enlarge)

Camano01[1]

Test Case Planning

Camano02[1]

Camano03[1]

Camano04TestPlan[1] 

 

Test Suite

The manual test cases you create are associated with a specific team project. You can add test steps, validation steps, and parameterized data to the manual test case.

You organize the manual tests into test suites, and then you create a test plan to define which test suites will be run on specific test configurations. You can select the tests you want to run from the test plan.

Camano05TestSuites[1]

 

Executing Manual Test Cases

When you run a manual test, you can optionally make a video recording of the test case. You can add comments, screenshots, and other files as you run the test. If the test fails, you can create a bug. This bug is automatically populated with any of the following information associated with this specific run of the test case:

  • Test steps

  • Validation data

  • System information

  • Video recording

  • Screenshots

  • Log files

  • Action log

Camano06Execute[1]

 

Because this functionality is integrated with the other parts of the Visual Studio Team System, you can publish the results to your Team Foundation Server.

 

 Camano07TestRunner[1]

 

Automate a manual test & add validation

Suppose we asked to convert the test into a coded UI test that can run in un-attended mode, we can generate the code from the background recording & then adds validation code using Visual Studio:

 Camano09CreateUITest[1]

 

Create new UI Element

Camano10AddUUElements[1]

 

Adding validation code

 Camano11QueryID2[1]

Advertisements

Team Foundation Server 2008 SP1 Preview

Brian Harry just posted about the many new impressive features and changes coming out in TFS 2008 service pack 1. It is quite a comprehensive blog post and well worth the time to read through it. Check it out at “Team Foundation Server 2008 SP1 Preview“.

List of features:

Version Control

  • Add to Source Control
  • Drag & Drop
  • Version control of unbound files
  • Simpler working folder mappings
  • Checkin date/time column
  • Local Path is now a link
  • Editable source location
  • Download files to a stream

Work Item Tracking

  • Ribbon support for Office 2007
  • Easily email work items

TFS Build

  • Easily locate TFSBuild.proj file
  • Conditionalize builds on the trigger
  • Detect test result
  • Dynamically created properties
  • Reduce build log noise
  • Query build definitions across Team Projects

Visual SourceSafe migration tool (vssconverter.exe)

  • Elimination of namespace conflicts
  • Automatic solution rebinding
  • Correction of timestamp issues
  • Improved logging

Other areas

  • SQL 2008 support
  • Team System Web Access links
  • # of projects per sever
  • Create Team Projects with a script

Performance & Scale

  • Improved syncing identities from Active Directory
  • Improved checkin concurrency
  • tf branch /checkin
  • Online index rebuilding
  • Team build support for very large checkins
  • Faster security manager
  • tf get /remap

You can’t download any prerelease version of the Service Pack yet, but it shouldn’t be too long now.

How To Deploy Data Dude Project Changes using Team Foundation Build

When you want to build and deploy database projects with team build you need to edit the database project file and the Team Build file. That’s because database projects store any non-default values for the TargetDatabase, TargetConnectionString, and DefaultDataPath properties in a <ProjectName>.dbproj.user file.  *.user files are not checked into version control in order to let every user use different values.

 

Step 1 – Modify build project file (team build .proj file)

Open the BuildDefinition.proj file, and at the bottom of the file, between the </ItemGroup> element and the </Project> element, add the following:

<Target Name="AfterDropBuild">
<MSBuild Projects="$(SolutionRoot)SolutionNameProjectNameProjectName.dbproj"
Properties="Configuration=Default;OutDir=$(SolutionRoot)..binariesDefault" Targets="Deploy" />
</Target>

 

Step 2 – modify the database project file

The target connection and database are stored in the ProjectName.dbproj.user file, which is user specific and not typically checked in to version control. You require those settings to deploy your database. Therefore, you must modify the ProjectName.dbproj file manually to specify the target connection and database.

Copy the lines that contain the definitions for the TargetDatabase and TargetConnectionString properties from the section in the ProjectName.dbproj.user file for the configuration that you want to build. These lines will resemble the following:

<TargetDatabase>MyTargetDatabaseName</TargetDatabase>
<TargetConnectionString>Data Source=ServerNameInstanceName;Integrated Security=True;Pooling=False</TargetConnectionString>

If TargetDatabase and TargetConnectionString already contain empty elements, you should overwrite those entries.

 

More into at the msdn page.

New Rosario Specifications

In addition to my previous post about influencing on TFS future, the TFS team has just uploaded two of the new Rosario Specifications:

To post feedback or ask questions about these Forums please use the forum located at: Discuss and Provide Feedback Here

  1. Resolve Improvements
  2. Core Linking Work Item Tracking
  3. Send Mail from TFS
  4. Add to Source Control
  5. Enterprise Team Foundation Server Management
  6. History Improvements
  7. Improved Label Dialog
  8. Organize team queries and my queries using a folder hierarchy
  9. Team Foundation Server Bug Submission Portal

BDW, You can taste Rosario here!

March 2008 TFS Power Tools now available

Brian Harry has just announced that the March 2008 Team Foundation Power Tools have been released:

We’ve just released a new version of the TFS Power Tools.  This new Power Tool release will work only with the VS/Team Explorer 2008 client (but against either a TFS 2005 or TFS 2008 server).  If you haven’t taken the time to upgrade yet, I highly recommend it – you are missing out on lots of great new value we are delivering.

This release includes:

  • Process Template Editor support for custom work item controls
  • TFSServerManager client
  • TFS BPA support for Windows Server 2008
  • Work Item Template improvements Scriptable Team Project creation
  • Support for 64-bit Sharepoint farms
  • Unshelve to a different branch
  • Improvements to tfpt review
  • Delete global lists in the work item tracking system
  • Update bound Microsoft Office docs when the TFS server name changes
  • Performance improvements in tfpt online

Click here to download.

Enjoy!

Rosario Preview #3 – Developer Edition

The 3rd preview of Rosario’s April 2008 CTP will focus on the Development Edition. This edition has some great features, my favorites are: Historical Debugger, Standalone Debugger and Rule Sets for Code Analysis.

(Click on image to enlarge it)

Historical Debugger

Visual Studio Historical Debugger captures and records what the application does while it is running. When an error occurs, you can quickly find the root cause by investigating the information that was recorded by the Historical Debugger. At any time during debugging, you can go backward and forward in time to determine where an error occurred.

debug_history[1]

Historical Debugger increases debugging productivity by reducing the time it takes to reproduce and diagnose an error in your code.

debug_history2[1]

Code Analysis with Rule Sets

We are presented with a list of built-in rule sets when we configure Code Analysis. We can either use the minimum recommended rules, or we can select alternative rule sets that relate to our project type. In either case, the rule sets can also be customized to fit your project requirements
For example, you can select a rule set that is suited for scanning code for a publicly available API.

CodeAnalysis[1]

Available Rule Sets

Rule Set Description
All Rules This rule set has all rules enabled.
General API Design Guidelines This rule set contains rules that apply to any API, especially if the API is intended for external use. These rules closely follow the design guidelines for the .NET Framework. Use this rule set if you are building a programming interface such as a class library, Web service, WCF service or workflow library.
General Web Development Guidelines This rule set contains rules that apply to Web development. This includes Web applications, server controls, AJAX and Web services. This rule set enables additional security and performance rules that help ensure that your Web site is reliable.
General Windows Application Guidelines This rule set contains rules that apply to Windows application programming. Use this rule set to help you assess the quality of your Windows application. This rule set applies to Windows Forms applications, console applications, WCF applications, WPF applications and workflow applications.
Legacy Code Cleanup This rule set contains rules that can help clean up legacy code. The rules that are violated can be fixed without having to change the public interfaces of your code. Therefore, they are ideally suited to cleaning up a legacy code base. These rules apply across all project types for which analysis is enabled.
Minimum Recommended Rules This rule set has the minimum set of rules enabled. If you encounter warnings when a scan with this rule set is enabled, it is likely that there is an error in your code.
Release Criteria This rule set contains rules that should be applied to an application that is undergoing final checks before release.

Debugging with the Standalone Debugger

Visual Studio Stand-Alone Debugger is a lightweight, stand-alone debugger that allows you to quickly diagnose problems in development, test, and production environments.

Visual Studio Stand-Alone Debugger (VSSD) does not require setup or configuration, which makes it ideal for situations where it is important to have minimal impact on the environment. In addition, deploying Visual Studio Stand-Alone Debugger is as simple as copying a few files. We can carry Visual Studio Stand-Alone Debugger on a USB thumb drive for “Just-In-Time” troubleshooting….

Creating the Standalone Debugger

Standalone%20Debugger[1]

Wizard …

Standalone%20Debugger2[1]

Standalone%20Debugger3[1]

 

This is the wizard’s product – folder which contains the debugger…

 

Standalone%20Debugger4[1]

And the debugger!!

Standalone%20Debugger5[1]

Once the Standalone Debugger is running, we can click the “Attach: Process” link on the start page to start debugging.

Additionally, the VSSD does not touch the system’s registry. The VSSD uses most of the features that are available in the Visual St
udio Debugger.

Summary

The development edition  has several new features, most of them in the area of the debugging and testing. I’m sure that the productivity of the developers and the quality of code will increased.

Enjoy!!

Rosario Preview #2 – Team Build

This is the second post in a series about April CTP of Rosario’s.

Team Build System Based on Windows WorkFlow Foundation

The new Team Build system in Rosario built on Windows Workflow Foundation, featuring dynamic build machine allocation from a machine pool and distributed build functionality.

WorkFlowBuild[1]

New Term – “Build Controller”

In Rosario, Team Build uses an agent/controller architecture where the controller is responsible for managing a pool of agents. Notice the notion of “Tags” which let you define metadata for a build controller/agent. Then you can target your builds at agents/controllers that have a specified tag.

BuildAgent[1]

Controller that hosts a build execution is the pool of build machines where the build will run. Additionally, the workflow that comprises your build process will run on both the controller and the agent with coordination activities occurring on the controller.

ManageBuildController[1]

BuildController[1]

No doubt, Rosario’s Team Build introduce interesting issues especially the support in WF – it seems that most of the problems in the area of custom task(s) can be handled by this issue. I’ll check it out and post about it later.

Enjoy!!

%d bloggers like this: