Rod Claar

My buddy Charles Sterling, Program Manager at Microsoft has posted a new webcast video showing the basics of how to create a test plan, test case, recording a test, filing a bug and playing back the test using the Beta 2 version of Visual Studio 2010.

You can see the video here:

How to create record and playback Test Cases in Visual Studio Beta2

This new central place for QA teams to create and manage test plans and tests is a great addition to Visual Studio for traditional QA teams.  However my primary interest is in how could an Agile team use this new tool to move testing forward in the Agile process.

Firstly I think that this tool could be a good place for Product Owners and Test Professionals to collaborate on the Acceptance Tests for an upcoming iteration.  The User Stories could be the basis for creating the actual test cases that would be used to validate the delivery of the anticipated business value from the User Story.

During Sprint (Iteration) planning the team could use the test case to understand the intent of the story and get clear on what the real acceptance criteria is.  I would expect that more detail and more tests would be added during the planning session as clarity is improved.

While working the story in the Sprint the team would continue to update the tests with recorded steps of the newly developed feature and run the acceptance tests to monitor the Sprint progress.

When the Acceptance Tests all passed, the User Stories would be functionally complete and they would provide a safety net for performance tuning, refactoring and integration.

I hope you have noticed that I am completely ignoring the coded automation of the Acceptance Tests.  I am a big proponent of automating Acceptance Tests.  However in my experience the road to fully automated Acceptance Tests starts with understanding the process of writing the Acceptance Tests and the Agile team using them to drive development.

I’m sure I will come back to the topic of Automated Acceptance Tests later, but if your team is looking for an easy way to get your QA professionals involved in your Agile team, using Visual Studio Test and Lab Manager to author Acceptance Tests is a great place to start!

I’ve been helping a pretty large team for a few months now.  Today I attended a user group meeting today on SecondLife delivered by Brian Harry of VSTS/TFS.  It is very clear that there are some issues that get exacerbated when you have a very large project.  

The first one that comes to mind for me is the formation of teams.  It seems that while some organizations are moving to cross-functional teams to some degree, the silos of discipline management still exist and tend to get in the way.   Brian Harry talked about the “Feature Crew” at Visual Studio.  These teams are cross functional but are created for specific feature sets.  These teams have specific goals and tend to be disbanded when the set of features are complete.  The team members often have multiple assignments simultaneously.  I’ll have to say that this is a step in the right direction in that the system and business capabilities are grouped with a team to deliver them.  This tends to help with the coordination of work between teams.  However the fact that they do not let the teams work together over an extended period means there is a lot of forming and learning about the team that is overhead.  

One of the other problems is the tracking and processing of bugs.  Because of the integration issues and the use of branching techniques to give the teams a relatively stable platform to work on, there are lots of bugs created and significant effort has to be put into managing and tracking them.  If you have a project with thousands of active bugs, you have a very big problem. 

However the biggest issue I’m seeing is the lack of visibility of the delivery of business value.  Huge projects are generally managed by feature delivery and bug rates and counts.  Most of this comes from the coordination of the work on the teams and the poor communication of vision down to the scrum team level.  This results in the scrum or feature teams doing massive amounts of interpretation on the requirements and the result is a bloated codebase with excessive complexity and enormous testing and integration issues.  Without a clear top-down expression of the vision for the product and the release the feature teams are virtually free to dump on the product.

All of these problems lead to release plan accuracy issues.  The traditional way this happens is slipping the ship date.  However the more dangerous risk is not delivering what the user needs.  How do we reduce the impact of these issues?

Firstly we should NEVER slip a ship date.  Our customers, users, clients need what we are building, otherwise they would not be paying for it.  They get no value out of software that they can’t use.

Secondly we MUST adopt a business value driven approach to managing the work and the teams.  This means that product and project management have to change.  Traditionally either the specifications/requirements are either so massive as to not be understandable or so limited they are little more than hand waving. 

To accomplish these two goals we have to prioritize the business value and constantly react to what the team is delivering.   The scope of the release WILL change, but if we have prioritized based on relative cost and relative business value we can deliver the important features on time.

This takes metrics and project status reporting. Brian Harry said that metrics should be about making you ask questions.  I could not agree more.  However the most important question should be about the progress toward delivering high priority business value.  If the teams were organized around business value items and the bugs were categorized by business value area then we could stop working on bugs that don’t impact the release plan.  We could also concentrate more on the quality of the code with the basic principles of cohesion, low coupling, testability and clarity.

It does not matter what tools you are using, the focus should be on the delivery of business value.  Track stories, bugs and scenarios in an appropriate way for your team, but concentrate, reward and deliver business value early in a way that will allow you to deliver business value quickly in the future.

I’m just getting started with this site and blog.  I plan to make log of the things I discover as I go about my daily process of encouraging people to be more agile.

Here is my biggie for the week.  This one saved me a ton of time and simplified my code.

I’ve been working on some TFS reports for a team at Microsoft.  A report publishes the results of an MDX query.  The latest report I have been working on is complex enough to need some VB code.  There are lots of examples of how to pass the individual fields from the query to the VB code, but I had to search and interpolate to come up with how to pass the entire Fields set (not technically a collection) to the VB Code.

As it turns out, it is very simple.  For this example we will say the name of the VB function that you want to send the set to is “GetValue”.  That would make the expression in the report look like this.

Code.GetValue(Fields, FieldName)

This will cause the report to show whatever GetValue returns.

To enter the VB code you open the Properties dialog for the report and select the Code tab. In your VB code you will have to extract the exact fields that you want from Fields, but that is pretty simple too.

Public

   Return  myFields(myField).Value

End Function

Normally in the report itself your expression would be something like this.

               =Fields!FieldName.Value

To use custom code to do this would be a bit silly.  However consider a scenario where you want to compare multiple values or do some calculation on the field values.  Suppose your dataset has fields used to track the progress in your project based on Story Points and you would like to display a Per Cent Complete value on your report or chart this value over time.

After adding the GetValue function to your Code you might add a function like this.

Public Function GetPerCentComplete(ByVal ReportFields As Microsoft.ReportingServices.ReportProcessing.ReportObjectModel.Fields, _
             ByVal StoryPointEstimate As String, ByVal StoryPointRemaining c) As String

   Dim PerCentComplete As Double
   Dim myFields As Fields
   Dim Estimate As String
   Dim Remaining As String

   myFields = ReportFields
   Estimate = StoryPointEstimate
   Remaining = StoryPointRemaining

   PerCentComplete = Convert.ToString(Convert.ToDouble(GetValue(myFields, Estimate)) / Convert.ToDouble(GetValue(myFields, Remaining) )

   Return PerCentComplete

End Function

Then your report could have a call like this:

            =Code.GetPerCentComplete(Fields, “CumulativeStoryPointEstimate”, CumulativeStoryPointRemaining”)

This is much easier to read and deal with in your report.

Next, I will show how to make this testable outside SQL Reporting Services.

Have fun!