Some of my regular readers said they wanted to see more "technical" content, so here is one that perplexed me a while.

While assisting a client with setting up an automating testing environment using Visual Studio 2008 Web Tests (among other things) we uncovered a need to check the results of a transaction halfway through, then when its complete to verify the results of the test.

Now I know what experienced testers and SQA people are thinking, "why didn't you just use an Extraction rule from a results page and validate that?". Yes, that's the first thing I wanted to have done as well and that works quite well under most circumstances.

Unfortunately on this particular application there is no real "confirmation" screen that displays the results of the transaction, just kind of a yeah I did or no I didn't kind of page. Not good enough in our case where I wanted to have real transaction results.

Since time was very short and I'm still working with the group to adopt more "test friendly" designs we needed a sure way of verifying the results. I though that this check DB feature would be a native feature in the VSTS2008 Web Test, but the only DB connectivity included out of the box was binding to a DB for data driven testing (which is very useful as well).

So our option was a to create a request level plug-in to go out to the DB and check the transaction results, and write them back to the test results.

My goals here were:

1. Connects to an SQL DB.
   
2. Builds a query string using a Context parameter
   
3. Puts the value pulled from the DB back into another Context parameter for use in follow on requests.

Here is how I did it (in a plug-in 101 type format), complete with code snippet I used to create this:

1. Create the following in a class library in your test project (that part is covered in detail in MSDN), compile, and reference it:

  1: using System.Text;
  2: 
  3: using Microsoft.VisualStudio.TestTools.WebTesting;
  4: 
  5: using System.Data.SqlClient;
  6: 
  7: 
  8: 
  9: namespace Test1
 10: {
 11: 
 12:     public class MyRequestPlugin : WebTestRequestPlugin
 13:     {
 14: 
 15:         public override void PostRequest(object sender, PostRequestEventArgs e)
 16:         {
 17: 
 18:             base.PostRequest(sender, e);
 19: 
 20:             int CustomerID = 0;
 21: 
 22: 
 23:             // this is my connection string
 24:             String connectionString = "Persist Security Info=False;Initial Catalog=dbname;Data Source=machinename; User Id=dbuser;Password=somepassword";
 25: 
 26: 
 27:             // select statement getting just the field I need.  Note that if this is;
 28:             // messed up it may throw an error saying is cant open the db.;
 29:             // This is misleading, its probably your select; 
 30:             SqlConnection connection = new SqlConnection(connectionString);
 31: 
 32:             string queryString = "Select CustomerID from Orders where OrderID=" + e.WebTest.Context["OrderID"];
 33: 
 34: 
 35: 
 36:             SqlCommand command = new SqlCommand(queryString, connection);
 37: 
 38:             command.Connection.Open();
 39: 
 40:             SqlDataReader reader = command.ExecuteReader();
 41: 
 42:             while (reader.Read())
 43:             {
 44: 
 45:                 CustomerID = Convert.ToInt32(reader[0]);
 46: 
 47:             }
 48: 
 49:             e.WebTest.Context.Add("CustomerID", CustomerID);
 50: 
 51: 
 52: 
 53:         }
 54: 
 55: 
 56: 
 57:         public override void PreRequest(object sender, PreRequestEventArgs e)
 58:         {
 59: 
 60:             base.PreRequest(sender, e);
 61: 
 62:         }
 63: 
 64:     }
 65: 
 66: }
 67: 
 68: 
 69: 

2. Insert the Request Plug-in (if you compiled and referenced it, it will be in the list.) AFTER the Context parameter you are using (in a production test you'll need error control, errors in a Plug-in are ugly and will mess up your results).

This whole exercise made think that a "data check" validation rule of sorts really should be part of this product.

Anyway hope this helps someone else a little further along some day using web tests. This same method also works in Visual Studio 2010 as well.

I'm always happy to see an organization I'm working with recording "lessons learned" documentation from multiple iterations of the same product, or successive project engagement.  The real key however is taking this information and turning into action items that help you get further along.  Too often I see teams committing items to Lessons Learned documents more like a confessional than a plan to not make the same mistake, or repeat a successful technique.

There are some simple steps we can use to help ensure a learning experience:

1. Document collaboratively.  This will avoid personal attacks and maximize the effort. I find it best to conduct several short meetings to get this done than one long one (again no confessionals here).
2. Successes and Failures.  Too often people are quick to point out failures but its just important to make sure we don't miss the things that worked well the next time.
3. Everyone Participates.  These sessions aren't just for the PM's, get everyone involved in the project involved.  This would also include your outside vendors if the relationship allows.
4. Rinse and Repeat.  Take your list of Lessons Learned and put them into documents used in every project Initialization phase.

Thats about it.  Hopefully we are all a few short steps away from the next level of productivity.

CRHC9HJBHU87

I'm writing this as I'm assisting an organization I've worked with frequently conduct a code review on a project they had purchased (from a CMMI Level 5 certified off-shore firm).  I had no role in the original application or any of the functional requirements so mostly I'm just a second set of eyes here. One thing (or rather the lack thereof) is jumping out at me as I'm listening to the narration.  Although the code is definitely well formated C# source, my eyes usually head right to the coders comments first, look at what they are saying they are doing, and following along with a copy of the design documents close at hand to make sure we are on track. 

In this case there was little to focus on for code comments, there weren't any.  A decent design document with UML models, good Use Cases and User Stories, just nothing to get from the class library name to what they were trying to do in terms of walking the reader through the logic or explaining the flow once you hit the source.  Now some of you may say (as they did) that good code is "self documenting".  Well to some extent that may be true, be it fails to answer a basic question I always try and answer when conducting or participating in a code review: what was the developer thinking when they wrote this?

Aside from the obvious issues of navigating fairly complex code, there is also the larger issue of maintaining a code base for code re-use.  Additionally if you are using a project as a template for more junior developers to build from (as this organization was) well commented code is usually more value than any other form of documentation.  If you are a lead developer on a project like this, staying with easy to follow design patterns should take precedence over gaining a little bit of performance (or showing off your coding skills).  So how much is too much ?  Personally, I'd rather error on the side of stating the obvious rather than taking a chance on loosing the audience.  When in doubt, explain it, especially if you are introducing a new technique to the team.