October, 2008

  • Visual Studio SharePoint Development Blog

    How we test – a high level overview

    • 1 Comments

    Hello, my name is Erik Cutts and I'm a tester (SDET) on the Business Applications team in Visual Studio. As a tester working on developer tools for several years I have had the unique opportunity to build tools for the best (and most demanding) customers in the world: Developers! As such I'd like to give you some insight into our day-to-day test activities which refine the quality of the tools you use in Visual Studio. In return, maybe you can share some thoughts on testing Office and SharePoint applications or just testing in general. Be aware that these practices do vary across Microsoft and this is based solely on personal experience.

    Testers are involved throughout the development cycle, from initial product design through shipping and servicing. Initially, we work with our team on product planning and design to ensure that customer scenarios are being met and that we are shipping the right set of features. We also ensure that the product is testable and scoped correctly so that we have enough time to refine the features within the resource constraints we have set.

    Once initial product design is defined test is responsible for authoring an overall test specification. The "Test Design Specification" document is a high-level overview of how we will test the product. This test strategy describes the scope of testing, test schedule, test configurations, external dependencies, risks and mitigations, division of labor and test tools and technologies. This document is live and is updated throughout the development cycle to stay up to date (features and schedules change as do customer requirements). The document is reviewed by our peers and management until we're on the same page.

    Now the real fun begins, developers are writing code, features are being checked in. How do we make sure the product is of good quality? Test begins by authoring detailed test-case enumerations which include all the areas we need to hit. These include user scenarios, performance, accessibility, globalization, API testing, security and the list goes on. These tests are reviewed and updated. Once features start to come together we do some exploratory testing. This manual testing involves attacking specific feature areas and logging code-defects (bugs), suggestions, and spec-issues. These issues are resolved by our team and we verify that their resolutions are acceptable. As an aside, our division uses Team Foundation Server to store and track our issues. It's a complete solution for our bug tracking needs which provides excellent configurability, reporting and best of all it is integrated with all the other Visual Studio Team System features.

    As our features mature we are ready to start test-case automation. Many of you are familiar with the benefits of test automation. In short, it allows us to execute test scenarios more often and across multiple configurations than a tester can execute manually. Most importantly it alerts us if product functionality which was working has regressed to a non-optimal state. Automation written by dev is different in that they write unit tests which exercise discrete components of the product. Testers excel at writing automation on a scenario level to ensure that the product works as a user would exercise it. Tests are broken down into priorities to determine how often they are executed. Test automation comes in many forms. API testing is used to test internal object models or libraries exposed to the user. UI testing is based on executing the product from the UI using accessibility interfaces to click buttons, enter text, use menus and exercise all other input methods. There are many other types of automated testing such as performance tests, stress tests, fault-tests, and other areas. It's worth mentioning that we are authoring and executing some tests using the Visual Studio test-projects with success.

    As the product matures it is the testers' responsibility to report the overall quality of the product across the team. This is a difficult task. How do you measure quality? Number of bugs, performance results, code-coverage, and automation pass-rates are some of the measures. However, they don't tell you how it feels to use the product. For this task we really put ourselves in the customers' shoes. It's the overall feeling of how complete the product is, how it responds, how difficult or easy it is to complete a task that is most important to us. This Overall Goodness Factor (OGF) is incredibly helpful in understanding how close we are to release.

    Throughout the product cycle we are working with the customer to get feedback and requirements for the product. Community Technology Preview (CTP) and Beta releases are great opportunities to gather this data. There are early adoption customers and partners which participate in the Technology Adoption Program (TAP). These customers promise to provide detailed feedback while we sign-up to support them with representatives from the product groups of the components they are using. We also use blogs (such as this one) and forums to get in touch as well as customer visits and conference attendance.

    As the product cycle comes to an end the tester has a great responsibility. We double check the exit criteria and put our name on the dotted line for Release to Market (RTM) readiness. Once that's done the DVDs are burned and the ship party is scheduled. Each employee receives a shiny plaque on a ship-it award to remind us of our accomplishment.

    I hope you've learned something about testing in our group. We're interested in learning more about how you do testing. How do you schedule testing? Do you have a specific test role in your business? Are you authoring automation for your tests or is this mostly a manual process? What examples do you have of testing for SharePoint and Office applications? How can we make it easier for you to test your products? If you are interested in hearing more about any of the above our team will be happy to continue blogging in more detail on these subjects. We look forward to discussing them with you.

  • Visual Studio SharePoint Development Blog

    Creating a simple sequential workflow

    • 4 Comments

    Purpose of this post is to show you how to get started developing SharePoint MOSS 12 workflows with Visual Studio 2008 by creating a simple sequential workflow. Let's say we want to create a workflow that creates a task each time user creates new announcement in Announcement list.

    First step is to launch Visual Studio 2008 and navigate to File → New → Project (or press Control + Shift + N) to open the New Project dialog. One note on launching Visual Studio 2008 – you have to launch it with administrator privileges in order to create SharePoint Workflow projects. SharePoint workflow project templates are located under Office 2007 node.

    As soon as you click OK the New Office SharePoint Workflow wizard is displayed. On the first page of workflow wizard you can choose the name of your workflow and the local URL (you can use http://localhost) to which you want to deploy your workflow. For this example accept the defaults on first page and click the Next button.


    First wizard page

    On the next wizard page you can choose a library or list to associate your workflow with. The other two combo boxes are for selecting workflow history list and task list – by default there's only one history list and one task list on your SharePoint site (if you have added additional task lists, you will see them here).


    Second wizard page

    Selecting the "Automatically associate workflow" checkbox will associate the workflow with the selected list. If you unselect the check box you have to take care of workflow association manually.

    Since we said we want our workflow to be associated with Announcements list, go ahead and select Announcements list from the first combo box and click Next. Last wizard page appears and it looks like the figure below.


    Third (last) wizard page

    There are three more settings on the last wizard page you can select. Below is the description of settings:

    • Manually by users: when checked, users can manually start the workflow.
    • When an item is created: when checked, the workflow is started when a list/library item is created (or uploaded).
    • When an item is changed: if checked, the workflow is started each time item in the list is changed.

    We won't worry about these settings in our sample so click Finish to close the wizard. Once you click Finish the wizard is closed and our workflow project is created. I won't go into the details on files that are created in the project at this time. Let's focus on creating a task when a new announcement is added to the Announcements list.

    Workflow designer should already be open and it contains one default activity: onWorkflowActivated1. This is executed, well, when workflow is activated. Go ahead and follow the below steps to add another activity to the designer:

    1. Open the toolbox (View → Toolbox or Control + Alt + X) if it's not opened.
    2. Locate CreateTask activity (it should be in the SharePoint Workflow tab) and drag & drop it onto designer, below the onWorkflowActivated1 activity. Sequential workflow designer should look like the one in figure below.

     

     

    Notice the red exclamation mark on the createTask1 activity which is telling us that we have to set some additional properties. To do this, right click on createTask1 and from context menu and select Properties (or click on the activity and press F4 to open Properties window). When properties window is opened you can notice small exclamation mark next to the CorrelationToken property. Correlation token is basically an identifier – you can read more about CorrelationToken here (http://msdn.microsoft.com/en-us/library/ms475438.aspx). Type 'taskToken' in the CorrelationToken property. Notice the exclamation mark is still there. Expand the property (notice the + sign before the property name) and for OwnerActivityName select Workflow1.

    In order to create a task we have to specify the TaskId and TaskProperties properties:

    1. Locate TaskId property in the property grid.
    2. Click on the ellipsis (...) next to the property.
    3. Binding dialog is displayed.
    4. Click 'Bind to a new member ' tab.
    5. In 'New member name' text box type: 'taskId'.
    6. Select Create Field.
    7. Click OK.

    Above steps will create a field in our code which represents task ID. You can repeat the same steps for TaskProperties – name the field taskProperties. Now that we have our ID and properties only thing left is to set the values for our task:

    1. Double click createTask1 activity.
    2. Once the code window is displayed type in the following code:

      private void createTask1_MethodInvoking(object sender, EventArgs e)

    {

    taskId = Guid.NewGuid();

    taskProperties.AssignedTo = "someone@example.com";

    taskProperties.Description = "Description of my task created with workflow.";

    taskProperties.DueDate = DateTime.Today.AddDays(5);

    taskProperties.Title = "My super task from super cool workflow.";

    }

    The above code assigns new GUID to task ID and assigns some values to the task. You probably noticed that you don't have to actually call a method to save or create the task – the createTask activity takes care of this. All you need to do is to set properties for the task e.g. description, title, due date, assigned to. There are several additional properties you can set – just type taskProperties and after you type the dot ('.'), intellisense shows up and you can browse through other properties.

    Now we're ready to debug! Insert a breakpoint in the createTask1_MethodInvoking and the breakpoint will be hit. When you press F5 your workflow is deployed and the browser should open up at Announcements list. To test the workflow, add a new Announcement to the list. Once you add the new announcement there should be a new column added to the list. The name of that column should be equal the name of our workflow (SimpleWorkflow) and it contains the status of the workflow (you should see Completed in that column).

    If you click on the status (e.g. Completed) you are redirected to the workflow status page and you will see the task that was created as a part of our workflow. It should look similar to the one in the figure below.

    Peter Jausovec

Page 1 of 1 (2 items)