Last week I posted the Step 1 tutorial for creating a WPF application from scratch using Visual Studio 2010. In this post, I’m going to create a test plan and test case for the application using the new Visual Studio Test and Lab Manager project.
For this tutorial, I’m using Visual Studio Team Suite 2010 (which includes all of the roles and TFS access). I’ve already added the demo to TFS so I have full source control. For the sake of demonstration, I’ve commented out the final fix from the walk through so the label does not update:
When I run the application, the label is not updated:
The Tester
To create my test, I’m going to run the Test and Lab Manager tool from the start menu:
The main page has tabs for test plans, tests, and for tracking work items:
First I need to connect to my TFS server by click Add. My server is VLM13267036 (auto generated name by our internal Hyper-V testing tools):
I’ve already got a collection with my code stored in the Projects folder:
Next I’ll select Projects and choose the Connect option. This prompts me to set a context:
I’ll choose “Set context” which brings up the editor for my new context:
I’ll select New:
I can now edit all of the properties:
After all data has been entered, click Save and Close. The new item is now in our list:
Double clicking the item allows me to add a new test case to this test suite:
Here you can fill out all details for the test case:
Steps can now be added by clicking on the “Click here to add a step”:
I’ve added a few steps including launching the application, hitting the buttons, etc:
Now hit Save and Close to go back to the test case list. The Plan is now complete. We can run it any time a new build is produced, for each flavor of build, for different configurations, etc. To execute the test, change focus to the Test tab:
Our test plan and test case are already in the list. Right click the test case and select Run:
This will launch the test case. The manual test runner window docks itself to the left side of my desktop so I can see both the steps I want to run and the full Windows desktop:
The “Start test and record” option allows me to not only do the testing steps, but it will also allow recording a WMV of all the steps I do as well as recording my steps to help me author coded UI tests (big helper with automation). This is really handy if you want someone to see exactly what you did to produce a bug and automate testing in the future.
In this case I will select “Start test”. Notice the Test Runner now shows the steps I created above:
The first step is to “Launch the PicViewer application” which I’ll do by running the application. Since that worked, I’ll press the combo box status item behind the step and select ‘Pass’ from the drop down:
The item is now marked as passing:
I’ll repeat the process for the next two steps, so far so good:
When I get to my last step, I discover the file path isn’t actually set. That makes this item a failure. Select the drop down box and choose ‘Fail’ from the list. I’m automatically asked for comments on the failure:
Since I didn’t record a video of my steps, I would like to give the developer a screen shot of what went wrong. Select the camera tool bar button:
This will bring up a capture tool turning the cursor into a cross hair that allows me to select a region of the screen. I’ll select the top of the application to demonstrate the busted label:
Notice that the failed test now has a .png file added with the image:
I’ve got enough supporting data now so I’ll create a new bug using the toolbar:
I’m now prompted to create my bug with a description, etc:
Notice the detailed test steps I’ve taken have already been added to the bug:
As has my screen shot (the .png file):
I’ll now do a Save and Close which will commit the bug to TFS as a Work Item. Finally I’ll do End Test then Save and Close the test runner. This will return us to Test and Lab Manager.
as a tester, I could now double click the test case and see all of the same data I just saved for the failure:
I can also select My Bugs and see the bug filed for this issue (since I conveniently assigned it to me):
And just to show how everything is wired together, I can open Visual Studio, Team Explorer and look for bugs assigned to me there as well:
At this point my job as a tester is now done.
The Developer
As a developer, I can now open the bug and read through the issue. If I select Other Links I’ll find the .png which I can open to see the issue:
Sure enough, the label is not updated. If a WMV had been recorded, I could have actually watched the testing steps in action. Because the bug is quite simple to find and fix (some idiot commented out the update line!) I can simply make my fix and test it.
Now that things are fixed, I want to check in the bug fix and resolve the work item at the same time. Click on the Pending Changes tab in VS and select the correct work item:
Now we can Check In the fix:
I can now verify the bug has been Resolved:
In Summary
A key goal for Visual Studio Team System 2010 was to reduce the number of times a tester and developer wind up in a ‘no-repro’ situation. There are several things I’ve demonstrated in this tutorial which help:
- Test case steps are documented and set up for repeatable execution
- Pass/Fail steps are outlined and stored in bugs automatically
- Video capture is allowed to see all steps taken, and screen snapshots are easy to acquire and file with a bug
- System information including build number, OS, etc are recorded for you (System Info tab)
- Although not shown, I could also have collected all of the historical debugging traces from the run as well
- All data from test cases, results, work items, and source code are kept in TFS and can be shared by test and dev
I hope you’ll pick up Beta 1 and try this set of tutorials for yourself. Let us know how well it works for you and if you have any suggestions. I should also point out the work item tracking, auto resolve, etc are all part of VS 2008 so a great way to get prepared for the new version is to get TFS deployed today and get your projects into the system.
Enjoy!