Inspect and Adapt

Inspect and adapt is one of the many tenents of an agile process. Why is this tenent the main one a new team is drawn toward?

Let me draw an analogy. I just started training to run half marathons. I hired an online coach. He sent me an email asking for my goals. Well, I wanted to be in shape and I wanted to run reasonably fast for a half marathon race in 3 months. I did some research and discovered that I could qualify for the Olympic trials in marathon if I ran a 1 hour and 9 minute half marathon. That’s correct; I would qualify for the Olympic marathon without ever actually running a marathon! “Perfect,” I thought. That’s my goal.

So I planned it out. If I wanted to run 13.1 miles in 1 hour and 9 minutes I would have to run each mile at 5 minutes and 16 seconds.

I started running. I noticed that my times were a 8-minute mile for the first mile, then an 9-minute mile for the second and it was getting worse. I was nowhere near my goal. I ran for another few weeks and was still behind schedule in meeting my goal. I had to do something or I wouldn’t reach my goal by race day.

It must be the way I was running. So I bought a book on running. I’m sure many of you have purchased a book on how to manage a scrum team. I read the book cover to cover and then read it again. Stay over your feet in an athletic stance. Arms bent at 90 degree angle. Chin out. Chest out, but not too far out. Don’t land on your heels. I looked like a chicken on an energy drink when I ran. But I read a book, this has to work.

I ended up hurting myself.

What should have I done? It probably would have been a good idea for me to run a little longer and build a base of knowledge, or better yet, have an experienced runner or a running coach watch me run to help isolate my problem.

What’s my point? Before the team inspects and adapts they need to have an understanding of why certain rules and practices are in place and what are the benefits and trade-offs of those rules.

The Problem with Functional Sprints

The team had been to Scrum training and understood the practices and products. They went through release planning and created the following release with three 30 day sprints.

Each sprint started on Monday and ended the last Friday of the month with no gaps other than weekends. The team was set up as follows:

• 2 developers, 1 QA Analyst, 1 PO, 1 ScrumMaster (fresh from scrum training)
• Automated builds from source control
• Manual testing
• Manual deployment
• Automated unit tests did not exist
• Definition of “done” was a feature coded and signed off by QA and the PO

At the end of the first sprint, 10 user stories were done and 4 user stories were code complete; however, QA didn’t have enough time to complete testing.

The team had a retrospective prior to sprint 2 planning with long discussion on what to do about code that was complete but not yet tested. The team discussed automated testing but didn’t feel they could get adequate automated test coverage during sprint 2 to solve the testing dilemma. After further discussion, the product owner offered to help. But he didn’t have time to constantly retest or run regression testing every time he received a new iteration of code inside the sprint. So the team decided that sprint 2 would be a development sprint for new features and the tester and product owner would test what was left over from sprint 1. If the tester or product owner ran out of code to test then they would prepare acceptance tests for development items currently in sprint 2 or look ahead to sprint 3.

The team added an additional “Done” state of code complete so they developers could identify which stories could be “moved to QA.”

Here’s what the new release plan looked like.

The product owner moved the release date out by 30 days to handle the new approach. He wasn’t concerned as he felt involved and could learn about delays early in the process. All is well, right?

Well, not really. The developers were having a hard time determining if they should work on the committed features in the current sprint, or fix bugs that were found from the last development sprint during the QA Sprint. In many instances, the product owner was confused as to what state the feature was supposed to be in. That is, he kept expecting what development was working on would be in the code he was testing when, in fact, it was a month behind. Many bugs were entered that were really part of the feature request currently in development. This frustrated the PO and the development team.

The team was falling further behind schedule and each group was pointing the finger at the other. We need more QA resources. We need more development resources. The PO wanted a new team.

Build the Team

I was asked to work with this team to figure out why they were over 2 months behind schedule.

At the beginning of this paper I posed a question, “Why is the tenent, inspect and adapt, the one teams focus on the most?” The answer is because as we move forward in life we are always analyzing and modifying our actions to obtain the best results. The team was heading in the right direction but didn’t understand how to work together. Instead they decided to continue to do what was comfortable which was to split the team apart like they had worked in the past.

We came up with the following rules to help keep aligned with an agile process:

• Inspect and adapt is good let’s do more of it
• Train team members to be generalized specialists
• Build an actionable artifact when replacing a manual task
• Develop a “we” mentality

Inspect and adapt more

Inspect and adapt is a great principle and should be used often. So we changed the sprint length from one month to two weeks. The team was worried at first as they were convinced they couldn’t get anything done in 2 weeks. The fact was they weren’t completing anything in the month long sprint either. So, really, what was the harm in shortening the sprint?

As a team we planned the first sprint and the only rule the team had to comply with was that a user story couldn’t be considered done until it has been fully tested. The first sprint was rocky as the team planned on completing 4 user stories and only completed 1. That one story was fully tested and passed user acceptance testing by the PO. This was a huge success as now the team and the PO know what it takes to complete a user story. Additionally, it didn’t take them a month to figure this out.

Generalized specialists

Train the individual team members to be generalized specialists. I’m not suggesting that skill sets are completely interchangeable. We all know that you can’t take a person that is good at writing a technical manual and expect they can write software applications. But a technical writer needs to understand the application in order to write the user documentation. They are perfectly capable of helping do some manual testing. If a developer frees up from a user story and the next highest story needs to be tested she can certainly help test the user story. The only caveat would be that it’s general practice to not let a developer test their own code.

The team refocused on the next highest priority user story understanding the new definition of done. By keeping the focus on the next highest priority team members were more likely to ask, “How can I help with this user story so we can get it to ‘done’”?

Some of the developers would even take screenshots and draft up a tutorial that the technical writer would then edit for final draft.

Actionable artifacts

Build an actionable artifact whenever we pulled someone away from a manual task. An example of this was building Given…When…Then (GWT) scripts in Gherkin that were converted to test code using a Behavior Driven Development framework. We used Specflow for .NET.

The team started having a 3 Amigos meeting twice a week where 3 people from the team, a PO, a tester and a developer would analyze upcoming user stories to write the acceptance criteria in the domain language of the business. The acceptance criteria followed the GWT framework used in Gherkin scripts which also helped identify test data that needed to be gathered.

The GWT scripts where built into the nightly build enabling nightly integration testing. All failed tests where investigated and fixed if necessary each morning.

We are the team

The team began to realize it wasn’t necessary to get more resources, the estimates and commitments where under their control. Once the team understood everything that was involved to bring a feature to done they began to form around the features and not the tasks oriented around the features.

The developers pair programmed but the interesting discovery was that a developer and tester where more likely to pair than 2 developers.

One of the highlights for me was during one retrospective when one of the developers said that everyone should avoid phrases, such as, “I handed it off to QA.” Instead the team would respond, “We’re still testing that user story.”

Summary

Our team found that we couldn’t deliver stories at the end of a sprint as we had to wait for the QA Sprint to finish. We chose to ignore the Scrum rule of having releasable stories at the end of the sprint. That was a misguided decision.

Sprints are time-boxed. The time-box fixes the resources and schedule for a story to be developed. The only negotiable part of the project triangle is the number of user stories being developed. The team destroyed the purpose of the time box by creating functional sprints. Additionally, when a team doesn’t take responsibility for the whole user story it’s easy to develop a “throw it over the wall” mentality. If the team confuses what it means to complete a story by partially completing stories in a sprint then we lose the benefits of the time box. The time box keeps the PO and the team focused on the most important requirements in the system while maintaining the project schedule.

The team and the PO now have an understanding of how the functional sprints made communication confusing. The team and the PO are now working with a clear definition of done within the sprint.

The team and the PO now have a very good working relationship and delivered the latest release in time for a major user conference. The PO was extremely happy with the way the product demo went at the conference.

The team is still struggling with BDD and getting their percentage of code coverage to the level they want but they are working together to consistently deliver quality product. Defects found during user acceptance where down from an average of 30 per sprint to 2.

Some useful links and books

Cucumber

The Secret Ninja Cucumber Scrolls

Beck, Kent – Extreme Programming Explained, Second Edition

Cohn, Mike – Agile Estimating and Planning

This entry describes how to install SpecFlow to run with NUnit. In a future post I’ll add instructions on setting up MSTest.

1. Install SpecFlow using NuGet or from the Visual Studio Gallery – SpecFflow
2. Install SpecFlow.Assist.Dynamic from NuGet so that you get the SpecFlow Assist Helpers assembly – this is a godsend when working with tables
3. Create a .NET C# class library project, I like to name it “Specs” or “Features”
4. If you are going to drive the UI with some of your Gherkin I highly suggest using Selenium WebDriver install it using NuGet.  This will allow you to do BDD against the UI.  I still think MS Coded UI Test is clunky.  Me no likey.
5. Definitely work through this great SpecFlow video tutorial

Some good links:

VS 2010 IDE useful features

Setup SpecFlow - Official Site

1. Install the M2 eclipse plugin
2. Create a new maven project using the maven-archetype-quickstart
3. Add the cucumber-jvm dependencies to the pom.xml file
4. Add the JUnit dependencies to the pom.xml file
5. Add build plugin to the pom.xml file if not using the default jvm
6. Delete src/main/java/App.java
7. Delete src/test/java/AppTest.java
8. Run a build to automatically install the project dependencies
9. Add a source folder src/test/resources for the .feature files
10. Add the cucumber-jvm runner class to src/test/java folder
11. Run a build to generate step code

Cucumber-JVM runner class

package com.your.package;

import cucumber.api.junit.*;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@Cucumber.Options(
        format={"pretty", "html:target/cucumber"},
        features="src/test/resources/"
        )

public class CukesTest {

}

Sometimes this team reports into the Customer Support organization and acts as tier 3 support.  Other times this team will be an additional group in development that takes on products that are being sunset or that are undergoing a rewrite.  I’ll refer to all of these models as Sustained Engineering (SE).

Sustained engineering teams are all about alleviating an immediate need.  The SE team should be the organization’s model for continuous delivery.  I’ll discuss the development side of this in a future post.  This post is aimed at how to appropriately manage the SE backlog.  I’ll touch on a workflow that I’ve seen and used for Sustained Engineering and then provide a brief overview of Scrum and Kanban.  If you need more information on Scrum or Kanban drop me a note or refer to the references at the bottom of this post.

The Sustained Engineering Backlog my have many interested parties across the organization and in some cases they are Product Owners of different components of the application.  In any case, the SE Backlog still needs one product owner from the business side.  I’ve seen models where the head of support or some one in development managed this backlog and it’s a really bad idea.  Like any Product Backlog prioritization this should ideally be handled by someone from the business.

One model that an organization that I worked for used was a many to one PO delegate.  The PO delegate would run a weekly prioritization call with the PO team and have the team work through the priorities based on business needs across the organization. This works well as it provides the ability of the business to negotiate on behalf of important customers and overall business needs or risks.  The PO Delegate had the final say or the ability to escalate to the executive leadership to break any ties.

Scrum

Scrum prescribes time boxed iterations.  The iterations are typically between 2-4 weeks.  The iterations should be the same length for each sprint so that the team can develop a cadence.  Scrum limits work in process (WIP) by limiting the amount of work in the time-box.  In Scrum this is called a Sprint.  Other methodologies refer to this as an Iteration.  The team's velocity is determined by the number of story points that the team can complete inside of a Sprint.  Therefore, the WIP Limit is the Sprint team’s velocity.  During the Sprint Planning Meeting the Scrum team pulls items from  the Product Backlog based on priority until they reach their WIP limit for the upcoming sprint.  This becomes the Sprint Backlog.

One of the main tenants of Scrum is that once the Sprint begins no new items should be added to the Sprint Backlog.  I’ve seen this also written as Scrum resists change inside the sprint.  In very short sprints, often used by Sustained Engineering, injecting unplanned work items usually causes a number of ill desired side affects.  When adding unplanned items into a sprint the new work item must be estimated and then lower priority items may no longer fit inside the sprint.  In Scrum the way to handle this is to then move the lower priority item to the next sprint or back on to the Product Backlog to be re-prioritized.

Due to the speed of delivery of the SE work items this can get confusing to the number of stakeholders interested in seeing a bug fixed or a new report added.  This becomes even more frustrating for Product Owners that have communicated delivery to a customer.

Let’s say that we are running 2 week Sprints and we define “Done” as all items in the Sprint Backlog are developed, tested, passed user acceptance, and approved by Change Control or any auditing process you have in place and are waiting for a production deployment engineer to push the “deploy” button.

Our average cycle time was 34 days not 2 weeks. Yes, sometimes it took 34 days to deliver a one line change to the code. Why is that?  Work items would fail UAT and be forced to the next 2 week sprint. This all lead to a very frustrated development team and users upset with the length of time a seemingly simple change took to get into production.   This caused additional issues such as causing us to deploy items in a middle of a sprint. This breaks the rules of Scrum, all around ugly and really uncomfortable.

Mary Poppendieck asks in her writings, “How long does it take you to deploy one line of code?”

In our example it will take at least 2 weeks to deploy one line of code and in some cases 34 days.  We physically can’t or shouldn’t push code to production in the middle of a Sprint if we are following the time-boxed rules of Scrum.  So what do we do?  Shorten the sprints?  Maybe 1 week sprints are good.  What if you have production deployment windows of twice a week or heaven forbid your deployments are automated and you can deploy daily.  1 day sprints?  Say it ain't so!

Kanban

Kanban is less prescriptive than Scrum. The basic element of Kanban is to visualize the workflow by creating a visual board with columns detailing where each item is in the workflow.  Work is broken into small equally sized chunks.  You limit the WIP for each state in the workflow.  The WIP limits aren’t always necessarily the same for each workflow state.  For example, during requirements elicitation there may be multiple items in progress per team member as they may have to coordinate communication with stakeholders to determine the breadth of the requirement.  On the other hand a developer can really only work on one work item at a time.

You manage and report work items in Kanban based on cycle time.

As we move to shorter and shorter sprints we are essentially heading towards Kanban.  While Scrum limits the team’s WIP using sprints, Kanban limits WIP per workflow state. The team then works each work item in each workflow state without regard to a time limit.  As the team focuses on reducing cycle time they swarm to assist with an item that is stuck in a particular workflow state that is causing a bottleneck.

Here’s an example of a Kanban board in it’s infancy.  Given the board below we set WIP limits for Requirements Elicitation, Acceptance Criteria, Test Data Available, Development, etc all the way through to Production Deployment. As you can see from the board below we are already over all of our WIP limits. We created the second horizontal line to help us bring us back withing our WIP limits.

Additionally, our original workflow did not include "Acceptance Criteria" and "Gather test Data" these workflow items where added to make it clearer to the PO, Development and QA that the definition of "Ready for Development" included valid acceptance criteria and examples in the form of test data.

This problem wasn’t caused by Scrum, but it was hidden from view.  Once we put up the Kanban board and placed all the active items on the board it was clearer where the bottleneck existed.  The product owners didn't understand that they were necessary in the process of determining acceptance criteria.

The board shows that there are too many items in “Acceptance Criteria." Development didn’t have time to go through them to make sure the acceptance criteria was adequate.

This bottleneck led to a number of bad practices such as estimating on weak requirements.  Items would come into development and stall as the team tried to solidify acceptance criteria. This then led to a number of items “slipping” out of the sprint or failing in user acceptance testing.

Now the fun part, I took a this picture of the board and displayed it during the next prioritization call. All of this information was reported weekly to the POs in  a spreadsheet but seeing it like this started a barrage of comments. The most important of which was when one PO noticed that the column for “Acceptance Criteria” was way over the WIP limit.  After explaining that we were having a hard time getting a hold of the users to help us understand and validate the acceptance criteria, the team of POs came up with a policy that they would push down to their teams. The new policy or better defined as commitment was that any item that development called about would be handled immediately by the business team or moved to a parked queue.

This company runs change control meetings every Monday and Thursday with deployments on the same nights for approved work items.  The team now packages anything “Done” by close of business Wednesday and close of business Friday and has the paperwork submitted and ready for change control.

Cycle time greatly improved down to 17 days after 2 weeks as they were still cleaning up backlogged items.  Their goal is to decrease cycle times to between 4 hours and 3 days.

This question comes from many people as they struggle to understand their role in a newly formed Agile environment. Let's map the traditional software development roles to the Scrum roles and see where if any differences arise.

Product Manager: Scrum role please (jeez I kill me) - Product Owner.

The Product Owner owns the release. He owns the product backlog and the prioritization of each requirement. As Product Owner this individual acts as the customer. They are accountable for managing the projects sprint by sprint. Huh?  Isn’t that the ScrumMaster?  Nope. You, Mr. Product Owner are the man!  They are accountable to senior management for the success or failure of the project. If someone wants to know the status of the project they should now go to the Product Owner not to engineering or the ScrumMaster. Engineering is responsible for the quality of the project.

Project Manager: Scrum role – ScrumMaster.
The ScrumMaster is responsible for the adherence to Scrum and to remove impediments from the Scrum team. The ScrumMaster may produce the information for the information radiator but the ScrumMaster is not in charge of the project as a whole, that is the responsibility of the Product Owner. The ScrumMaster does not assign tasks to the team, the team pulls the next available task off of the Sprint Backlog. I have moved Project Managers to work with Product Owners to be a "Release Manager" to help coordinate all the additional tasks that must occur in large software organizations to deliver a product from inception to product launch. Once a team is running smoothly a ScrumMaster may spend only a small percentage of their time doing their ScrumMaster duties.

Developers, QA, Tech Writers: Scrum Role - Scrum Team
All others are members of the Scrum team. A Scrum team can vary from 2-7 people. The team is responsible for building demonstrable high-quality deliverable product at the end of every sprint. If the team does not have the appropriate resources, human or technical, then they should not begin the sprint.

Development Manager: Scrum role - None.

I saved the Development Manager for last as this role can be the most confusing to place as the organization changes.  Development mangers are used to directing their team to greatness, poking their head into design meetings, and at times acting as the architect for the project.  While their isn’t an explicit role in Scrum, the development manager is key to building teams.

The manager's role is to use one of many management techniques to build high-performing teams. Depending on the manager’s background this includes morale as well as coaching the technical staff to hone their skills.  I’m a big fan of One Minute Manager's¹ Situational Leadership techniques. So let’s look at the One Minute Manager’s PRICE System and provide our newly displaced manager with some skills that he may have lost touch with.

PRICE stands for Pinpoint, Record, Involve, Coach, and Evaluate.

Pinpoint. Define key performance areas for people in observable, measurable terms. By pinpointing the manager doesn’t say something or someone is good or bad but instead finds performance areas that can be measured. You always want to focus on areas to improve. In software development these areas may be around quality, team commitment, or quantity.

Record. Gather data to measure the baseline and then show progress towards the goal.  If a Scrum team has lower than average quality metrics at the end of a Sprint and it’s due to one team member, hey the team probably already knows who it is, so let’s not hide it. The development manager should run bug reports or defects over the number of automated tests for this developer.

Involve.  At this point the development manager shares the information with the team member.  It’s important to involve him in the realization that he needs improvement and then work together to build a plan that he and the team can implement.  Data makes this a meeting of sharing facts without judgment. This isn’t a time to reprimand but an opportunity to let him know that he is important to the team and that continuously improving is a key part of the agile manifesto.

Coach. This is the fun part.  Pair with the developer or have them pair with other team members that are strong in this area.  Coaching or teaching someone else is a very rewarding experience and in itself builds relationships and brings the team closer together.  During the sprint review show the overall quality numbers and if the individual’s improvement is the main reason the numbers went up use this time to praise the individual and the team on this major accomplishment.

Evaluate. Well didn’t we actually already do that?  While we were working with the developer, he grew, the team grew, and everyone celebrated the quick win.  Agile is about succeeding quickly, failing quickly, and learning quickly.  So don’t wait.  Be there for your team.

As the Development Manager you’ll be PRICEless (oh, stop it, you knew that was coming.)

Notes
1. Blanchard, Ken, Putting the One Minute Manager to Work

CUITe is a thin layer developed on top of the Microsoft Visual Studio Coded UI Test engine. This blog entry walks through the creation of creating a CUITe test.

I switched to CUITe framework due to the separation of the Object Repository from the automation code.  This approach moves away from the UIMaps in the base CUIT framework.  Make your own determination but I feel that CUITe makes the coding of these unit tests more like MSTest or Nunit and in that sense more developer friendly than QA Engineer friendly.  Again, make your own judgment on that aspect.

Future blogs will address scaling the framework to make CUITe usable for large applications.

All of the blog entries will use a basic website created in VS 2010. Use the steps in the walkthrough provided by Microsoft to create a website with membership and login.

Create the sample Web Site

For this installment of the blog you can stop once you reach the "Adding New Users" section of the Walkthrough.

Walkthrough: Creating a Web Site with Membership and User Login

Download CUITe from codeplex

CUITe

Create the test project

1. Open the solution created under "Create the sample Web Site"
2. Right click the Solution and select Add | New Project
3. Select Visual C# | Test project
4. Name it something appropriate. I usually append the word "Tests" to the project name I am putting under test. So in my case the web site is named WebSiteCuit so my test project is named WebSiteCuitTests
5. Your solution should look something like this in VS 2010

   

6. Delete the UnitTest1.cs file
7. Right click the test project. In this example, WebSiteCuitTests and select Add | Coded UI Test…
8. Click Cancel when the Dialog box pops asking to record or select existing. At this point we just wanted to make sure all of the Coded UI Test references are created for us.
9. Add a reference to the CUITe.dll from c:\Program Files(x86)\Microsoft\CUITe folder.
10. Create a folder "Object Repository" under the test project.
11. Your test project should look similar to this:

Let's create our first test

1. In the next step CUITe needs us to navigate to our application. In our case a web site but I've created this using the built in web server for Visual Studio so we need to launch the application once to get the local url. Right click the Default.aspx page and select View in Browser…
2. Copy the url of the homepage and close the browser window
3. Open CUITe Object Recorder (Start | All Programs | CUITe | CUITe Object Recorder)
4. Paste the url of your application in the Address Bar at the top of the CUITe Object Recorder

   

5. Verify that the language drop down is set to the programming language that you want the tests recorded in. I'm using C#
6. Click the Record button at the top left corner
7. Place your mouse pointer in the "User Name" text box and then left click. (You should see the text window at the bottom start to fill with code.
8. Place your mouse pointer in the "Password" text box and then left click.
9. Click the "Log In" button
10. Since you didn't key in your User Name and Password you will see the "Your login attempt was not successful. Please try again." Message. Place your mouse over the message and when you receive a red box around it left click it. We'll use this message in an assert.

    

11. You'll have a series of public members that look similar to this:

    

12. Click the "Code" button at the top of the Object Recorder. The page definition code will appear in a notepad instance.
13. Go back to Visual Studio and right click the "Object Repository" Folder
14. Select Add | Class. Name your class PALogin (I'm using PA to indicate Page)
15. Click Add
16. Copy and Paste the code from the notepad instance keeping the namespace of your project.

17. Your code should look something like this:

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using Microsoft.VisualStudio.TestTools.UITesting;
    using CUITe.Controls.HtmlControls;
    
    namespace WebSiteCuitTests.Object_Repository
    {
        class PALogin : CUITe_BrowserWindow
        {
            public new string sWindowTitle = "";
            public CUITe_HtmlEdit txtLogin1UserName = new CUITe_HtmlEdit("Id=Login1_UserName");
            public CUITe_HtmlPassword txtLogin1Password = new CUITe_HtmlPassword("Id=Login1_Password");
            public CUITe_HtmlInputButton btnLogIn = new CUITe_HtmlInputButton("Id=Login1_LoginButton");
            public CUITe_HtmlCell celTemp1 = new CUITe_HtmlCell(
                   "InnerText=Your login attempt was not successful. Please try again.");
        }
    }

18. Open the CodedUITest.cs file in the test project
19. Right click on the class name and select Refactor | Rename.  Name the class LoginCodedUITest
20. Right click the CodedUITest1.cs file in Solution Explorer and select Rename.  Name the class LoginCodedUITest.cs to match the class name
21. Add a using statement for CUITe

    using CUITe.Controls.HtmlControls;

22. Open up the “Additional test attributes” code region and uncomment the MyTestInitialization method and add the following line of code:

    CUITe_BrowserWindow.CloseAllBrowsers();

23. Add the following code to CodedUITestMethod1():

    CUITe_BrowserWindow.Launch("http://localhost:41901/WebSiteCuit/Login.aspx");
    PALogin pgPALogin = CUITe_BrowserWindow.GetBrowserWindow<PALogin>();
    pgPALogin.txtLogin1UserName.SetText("Jimmy");
    pgPALogin.txtLogin1Password.SetText("Jimmypwd");
    pgPALogin.btnLogIn.Click();
    StringAssert.Contains(pgPALogin.celTemp1.UnWrap().InnerText, "attempt was not successful");

24. Right click inside of the CodedUITestMethod1() and select Run Tests
25. Green Check!  Success!!  Congratulations on your first CUITe test run.

Useful Links

Testing the User Interface with Automated UI Tests

Microsoft Visual Studio 2010 Feature Pack 2

Record and Playback in IE