Installation VSTS 2008, Team Explorer, SQL 2005

Installations required to be followed in sequence.
1. Install IIS.
2. Visual Studio Team System 2008
3. VSTS 2008 Team Explorer
4. VSTS 2008 SP1
5. SQL Server 2005 (or 2008) (Also if you are working with Service Packs of SQL you can subsequently install that too)
6. VSTS Power Tools (If required)


If you installed Team Explorer into Visual Studio after you applied Visual Studio 2008 Service Pack 1, you’ll need to re-apply the service pack. If you don’t, then you’ll be running an unsupported “mixed mode” installation, meaning the core Visual Studio components will be at the SP1 servicing level and TE will be at the RTM servicing level.

Struggling with LoadTest Reports

Been two days I was struggling with troubleshooting Loadtest reports. Still I am not able to access the inbuilt LoadTest report which comes with VSTS 2008.

Thanks to Shai, for giving me this wonderful link which solved my purpose of reports.

Use DataSource in Unit Test

I had a unit test in C#, written to test one of the functions of my service. Considering best practices of testing like Boundary Value testing, there were number of data input which I had to consider to completely test the function. For doing that one of the ways is, instead of writing different tests with different type of inputs, we can classify the test with respect to passing tests and failing tests.

I created a test for passing input values and another test in which the Test had an Expected Exception. In both the cases I had wide range of data input. For this I used a CSV file for getting the input data. So for in a particular test, all the data combinations mentioned in the CSV will be executed.
For using a Data Source in a test we will have to perform the following steps.

1. Go to the Properties of the Test (Press F4 after selecting the Test in TestView)


2. Select the Data Connection String button
3. Then select the type of input file suitable to you (CSV or XML) In my case I used CSV




4. First Row of the CSV is automatically considered as header. (This needs to be taken care of while preparing the CSV)



5. Select Yes/No in the next dialog box if you wish to select this CSV to be added in deployment item and also get added to the solution. If you select Yes, the CSV will be added to the current project and also it will be added in the list of Deployment files in the LocaltestConfig.TestConfig file.

6. The Test will now look like

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "DataDirectory\\CSV.csv", "CSV#csv", DataAccessMethod.Sequential), DeploymentItem("Test\\QA\\UnitTestProjectName\\CSV.csv"), TestMethod]
public void TestUsingDataSource()
{
}

7. For using the data in the test you will have to write TestContext.DataRow["Name"]

Note: The name you mention here should be exact to the header name given in the CSV.
The retrieved data from CSV can be converted to string by Convert.ToString(TestContext.DataRow["Name"]).Trim();

That’s it. The test will be using the CSV whenever it runs now. The important thing to remember is whenever you run the test once from the test view, it will have individual runs inside it which will depend on the number of rows of the CSV.

Add Check-in Policy

The Check-in policy can be added at Team Project level. Below are the steps.
1. Open the Team Explorer
2. Select the Team Project
3. Right Click -> Source Control

4. Click on Check-in Policy Tab

5. Click on Add button.

You will get the options as above if you have installed PowerTools, otherwise 4 options will be displayed

1. Builds

2. Code Analysis

3. Testing Policy

4. Work Items

Paired Testing - successful implementation of a complex functionality

Pair-Testing is the exercise where a pair of testers (or any other pair of people) perform tests together (using only one interface with the AUT), with the objective of complementing each other with their backgrounds, points-of-view, experience, knowledge, or even luck.

The logic behind doing this is an additional person that looks at what you are doing and thinks about additional or different operations. This is really very helpful when testers/devs are working on a very complex bit of functionality.

One of the developers in my team was working on a functionality few days back which was really complex. He finished the first chunk of delivery. I paired up with him (Paired testing – 1 dev & 1 tester) and we started implementing the functionality. There were few unique scenario’s which we both came up individually. Been developing/testing that functionality, the dev or the tester would have forgotten implementing/testing that.

The functionality took good shape. It took more time than it was estimated at that point in time. (Naturally we were two resources working on the same bit). The code was tested by another tester and to our surprise the most complex functionality had only one new bug in it. Then we could make out that development didn’t take more time than expected as we had only one bug to fix and retest.

According to me pairing two testers and two developers always works, but we should try and experiment mixing them both in each other’s work. I am sure it will be worth for sure.