Data Tools and Software Testing : General Software Testing

Spec Explorer 2010

nihitk — Wed, 02 Dec 2009 16:51:03 GMT

I am very excited to see the latest version of Spec Explorer (which is available even for Visual Studio 2010 Beta 2) now available publicly for everyone in the world to leverage. It is available via the MSDN DevLabs page and the Spec Explorer team (the fact that there is a team dedicated to pushing this tool makes me immensely optimistic about it’s future) even has a wonderful new MSDN blog dedicated to Spec Explorer.

Kudos to the Spec Explorer team and I look forward to wonderful improvements coming from them in the years ahead to help leverage Model Based Testing in a more pervasive way across the software industry.

Future of Testing from James Whittaker

nihitk — Sat, 27 Dec 2008 02:55:19 GMT

Found this exceptionally inspiring, interesting and informative talk (I saw an internal version of the same talk) by James Whittaker (please subscribe to his blog if you remotely care about software quality), who is a pioneer in the software testing world. He also has a series of blog posts on this topic in which he covers more details.

In fact it was so inspiring, that when I tried to save this post in Windows Live Writer, I got the following dialog + a crash:

instead of a simple message followed by a SaveAs dialog which would have been so much better if there was simply no space to save this on disk.

In defense of the Live Writer test team though there were quite a few "different" things that I was doing and it just makes the same point of how diverse the usage scenarios end up being from our labs.

I have my "My Documents" setup to automatically redirect to a share for backup purposes.
I also had the blog I was targeting set to a different one instead of my MSDN blog. This is my personal site blog and since I blog on it from home, I cannot use the externally visible form of www.sitename.com (since I am behind my router on which my server is also located), I was forced to use the http://server format for that blog setup.
I was creating the draft from work, where the http://server format does not work for my personal blog anyway.
I tried to save and switch the blogs (from personal to MSDN) at the same time.

Ah, but I shouldn't be surprised. First I used to think that I was an innate tester who just naturally found bugs. But over the years, I have sadly realized that almost all our users are just as gifted as me. Thanks to the quality of our software.

Just today morning as well I got all excited reading about Microsoft Research AutoCollage software and took it out for a spin. But at the end when I tried saving and exiting the app it crashed on me. The weird part was that all along, I was expecting it to crash so it didn't bother me. Why? I think subconsciously for a couple of reasons - it was MSR so I was not expecting released product quality from it, even though we are selling the software on our brand spanking new www.MicrosoftStore.com and secondly because it was doing a lot of fancy, CPU intensive image processing which made me just hold my breath and wait for the inevitable crash (though to their credit it didn't quite occur during the processing). Oh! We have such a long way to go.

Anyway, this talk is all about the future and not the present. The present sucks, we all know that. But fear not, for we brave, intrepid testers will fix all of that (or at least find all of that - we'll need some devs to fix it for us - we can't touch the product code you know!) :)

Elements of MBT - Part 3 – Actions and Action Parameters

nihitk — Fri, 06 Jul 2007 02:45:00 GMT

In the last 2 posts we have looked at what we mean by a model of a system and defined what States and State Variables are. In this post we'll look into Actions and Action Parameters.

We can define an Action as something that modifies or exercises the system. Thus "TurnIgnitionOn" (in the car model being used in this series) can be an action which causes the system to change in some way. When considering Actions you need to think about what exactly is it that changes in the system and which all state variables are impacted by those changes. An action is therefore simply something that causes the system to change states.

Actions become much more powerful and useful when combined with the concept of Action Parameters which can be considered to be similar to method parameters. Like a method (in a programming sense) does some work which can be tweaked or controlled by the method parameters, the effect of an Action can be affected by Action Parameters. In the car driving model an example of an Action Parameter would be whether the ignition could be turned on remotely (via the keychain) or locally. In that case we might want to add an Action Parameter to the model such as TurnIgnitionOn(Mode) where the "Mode" action parameter could take values "Remote" or "Local" similar to the way state variables can have different values.

A really interesting point that emerges here is that there is no one way to model the system. In the example above if for some reason you actually wanted to track how you had opened the car, maybe for a later stage in the model when you were actually locking the car then you would need to store this information in a state variable. Anytime you find yourself using the word "track" you should think about having that value as a state variable. We could therefore break our TurnIgnitionOn action into 2 different types of actions, TurnIgnitionOnRemotely and TurnIgnitionOnLocally and track how we opened the car as a new state variable, say S3, with values Remote or Local. Our model would therefore look something like this:

I will end this post with a word of caution. Even though it is quite easy to add a state variable to the model to track some aspect of the system, you should be very careful when adding state variables to your model and strive to minimize this number. The reason for this guidance is to limit the amount of state explosion that takes place as a result of defining these additional state variables. Remember that every time you define another state variable the number of possible states in the model is increasing exponentially. To keep your model manageable you should not add a state variable till it is absolutely critical to the behavior being captured.

UPDATE: Just noticed that this is actually my 100th post on this blog - WOW! Never thought I'd see the 100th post when I started out...it's been fun! :)

Elements of MBT - Part 2 – States and State Variables

nihitk — Thu, 28 Jun 2007 03:52:00 GMT

This is a continuation of the Elements of MBT series of posts which I started last time with Part 1 and covered what is meant by a model of a software system. In this post I shall be covering additional concepts which you will need to know to gain a better understanding of Model Based Testing.

One of the most fundamental concepts required to define a model of a system is that of State Variables which in turn are needed to define what a State is. A State Variable is simply some aspect of the system which changes over time. For e.g. in the car driving model, one aspect that changes (and which you care about tracking for the purpose you are building the model for) is whether the car is moving or not. So this can be a state variable, say "CarMotionState", which can have values such as "Moving" and "NotMoving". Couple of important things to keep in mind is that a state variable can have multiple values (not just 2 as in the example above) and that these "values" are really just semantic terms to help us define the model. What the actual values of these do and result in (especially from an automation point of view) is tied in later when you are implementing the code for the model.

A State then becomes much easier to define as simply a combination of all the State Variables in the model with particular values assigned to each state variable. Thus if your model contains 3 state variables S1, S2 and S3 with multiple values for each state variable, a state will be defined by a unique set of values for each of the state variables S1, S2 and S3. You can therefore think of a state as simply a snapshot of all the state variable values at a given point in time. From the Part 1 car driving model we can now see that the 3 states in the model are comprised of the following unique combinations of state variable values.

S1 = { IgnitionState = IgnitionOff; CarMotionState = NotMoving; }

S2 = { IgnitionState = IgnitionOn; CarMotionState = NotMoving; }

S3 = { IgnitionState = IgnitionOn; CarMotionState = Moving; }

One thing to notice here is that not all possible states need to be defined for a particular model. Depending on the system and the reason you are creating the model or the abstraction level you want to capture, you might not include certain states in your model. Or certain states simply won't make any sense to model such as the state "IgnitionOff" + "Moving" if you do not want to capture the behavior of the car sliding down hill when the ignition has not been turned on. The great thing though is that it forces you to think of that scenario and to consider if that is something you want to capture and if so then what the expected behavior would be.

In the next post I shall cover Actions and Action Parameters and update the model to add an Action Parameter to one of the actions.

Elements of MBT - Part 1 - What is a model?

nihitk — Sat, 24 Mar 2007 03:54:00 GMT

In this series of "Elements of MBT" posts, I will be covering some basic concepts used when trying to build models of software systems for use in Model Based Testing. The aim is to give an explanation of the various elements involved in defining a model of a software system and hopefully this should get us on the same page and allow us to explore the complexities in more detail.

Let us start by going over what we mean by a "model" of a system. Put simply, a model is a description of the system and is much simpler than the actual system itself. What this means is that the model hides a lot of the details about the system and hiding these details allows us to work at a higher level of abstraction. For e.g. a simple model of driving a car could be:

One thing to keep in mind is that there is no perfect model of a system, since the same system can have completely different models depending on what you plan to use the model for. Are you creating the model of a system simply to capture the behavior and requirements of the system? Are you creating the model to auto-generate the code for the model implementation itself? To describe the data flowing through the system? Or are you generating the model to actually test a particular portion of the system?

A quote which captures this unusual thing about models really well is as follows:

All models are wrong; some models are useful.
- George Box

What is worth hanging onto from this definition is that a model that you create should strive to be "useful" more than anything else. It might be rough round the edges and might not tell you everything about the system (for e.g. you don't know from the above model how the gear is to be changed or what happens when a gear is changed) but if it is useful for the purpose it was created it is a correct model.

Another aspect of defining a model is the notion that the model should help predict what the behavior of the system would be under certain conditions. So if you are in the "Not Moving" state and you "ChangeGearAndAccelerate" then you reach the "Moving" state. Are there certain assumptions in the model? You bet there are! Such as assuming that the ignition is on, that the car has wheels, that the car is not hanging in the air, that there is oxygen in the air, we can go on and on and on. The hiding of these details and assumptions is what helps us look at just this behavior we are capturing. If anything is important for the purpose (say testing) for which we are creating the model, we should consider adding that detail into the model. So if we thought that it was important to know whether the ignition was on or off we would change the model to capture this as well.

Now we know that if you are in the "Ignition Off" and "Not Moving" state then if you "TurnIgnitionOn" you reach the "Ignition On" and "Not Moving" state since simply turning on the ignition does not cause the car to start moving in the model that we have created. To start moving you will need to "ChangeGearAndAccelerate" which should take you to the state of having the "Ignition On" and the car "Moving".

Hope this gives you an idea of what a model contains and what it can be used to capture. In the following posts we will look into each element of a model in more detail.

How to test a delete operation?

nihitk — Sat, 18 Nov 2006 02:08:00 GMT

Question to the community: How can you best test a delete operation?

For e.g. When you test the following API - DeleteObjectFoo("ABCD") - what should we test to verify that this function actual deleted "ABCD"? This API is just a placeholder for an API that deletes something. The question is that, in general, how do we verify that "something" was indeed deleted?

Should we simply test that "ABCD" is deleted from the database (or whatever the underlying storage is)? That is typically what is done. The question then becomes how do we catch a bug which not only deletes "ABCD" but also "XYZ"???

A colleague some time back had raised this issue since we ran into exactly this sort of a bug and found to our dismay that the existing tests were not catching this bug.

What do we change to test for a delete operation in general so that the testing becomes foolproof - or can it even be made foolproof?

Process Monitor for Debugging

nihitk — Thu, 09 Nov 2006 21:09:00 GMT

The Process Monitor looks like a great tool to help in debugging issues and includes a bunch of features from a diverse set of sysinternal utilities such as RegMon, FileMon etc. I think this is the first tool offering to come out since the acquisition of Sysinternals.com and more importantly perhaps, Mark Russinovich (who has bunch of interesting posts about debugging issues). Looks like there is even a dedicated Sysinternals Blog at TechNet and if you are not familiar with the sysinternal family of tools there is a free Tour of the Sysinternals video available.

Model Based Testing – The Yellow Brick Road

nihitk — Sat, 29 Jul 2006 04:04:00 GMT

The future was here – now it’s the past. I am, however, wiser about the ways-of-the-model-based world. Still taking baby steps really, but starting to stand up on my feet. The real-world turned out to be a whole different ball-game from what I had envisioned (and read and expected) but it has been a fun, FUN ride and the road ahead looks fascinating – though long.

In the eons since I posted my original introduction to model based testing, a lot has happened to the world. For e.g. Wikipedia now has an article on MBT. There is an Association for the Advancement of Model Driven Quality Assurance (though they don’t actually state how one can join them!). There are a host of companies dedicated to doing only model based testing (for e.g. Reactive Systems and Confirmiq). There is an IEEE workshop on Advances in Model-based Software Testing (scheduled for Nov 2006 and looks really interesting – would love to hear from someone attending it!). There is even a new acronym for the technology – MDQA for Model Driven Quality Assurance (that’s when you know something has really taken off – when people call the same thing by different names!). I find all this amazing and reflective of the direction in which the testing industry will be moving in the next 5, 10, 20 years.

So what have I been doing all this time? Well, in a nutshell, simply using MBT to actually test something that gets shipped – in this case that happens to be portions of Commerce Server 2007 that I worked on (that should be another selling point used by the sales team and on our info sheet – “Tested Using Bleeding Edge Model Driven Testing Technology”). Along the way I cleared the hurdles and burnt my fingers while trying to keep the eye on the ball – which is always simply to test as best as you can. I now plan to expound in future posts on how to adopt MBT better, what to expect and more importantly, what not to expect from this fascinating methodology.

For this post, I will just mention the most startling thing I discovered – that this dream is going to take a long time to realize. By “this dream” I refer to that futuristic world where model based approaches are entrenched in our processes and systems. Where a tester thinks first in a model based approach whenever he/she is given something to test (even a regression!). Where the metrics are tailored to encourage testers to adopt a model based approach. Where the feature teams contribute to and strive to keep their models up-to-date. And where the tools have the features and reliability that is crucial to be able to develop models and have high levels of confidence in them.

All of these are non-trivial problems and there are no easy answers that anyone can give. But maybe that’s part of the challenge? So, all in all, buckle up and put on some good music – it’s gonna be a long, FUN ride and we’ll change the world on the way!

Buggy Test Code

nihitk — Fri, 21 Apr 2006 08:40:00 GMT

All the technical jargon of the world put together cannot compensate for raw stupidity. I recently had this epiphany when I ran into one of those “DUH!” bugs in my test code. Made me feel like a fool and so I thought I would redeem some of my hurt ego by confessing and discussing general test code bugs and why they occur, in the hope that it brings me some closure!

Here’s the nasty little not-so-secret of the testing world that is rarely talked about – the test code is full of bugs. Big, bad, ugly BUGS. The product code is blessed since it will have people beating it to death and using it in different ways thus exposing most (hopefully!) of the flaws contained. But the story of the test code is quite sad – it starts out on any regular afternoon when a tester codes up a few test cases for an API or a particular scenario. The code is run once (depending on time constraints might be run ½ a time only – what that means, we’ll get to in a second) and if everything looks nice and dandy, it is checked in. This is a big moment for the test code, because my guestimate is that for a huge percentage (I would speculate almost 75%) of the code will never be looked at again. I know, I know – that’s not the way things should be. We should have every line of code reviewed (hell – let’s have it reviewed multiple times while we are day dreaming) and periodic re-reviews to ensure the test code is in sync with the API behavior. But then we should also have world peace. But we don’t. So let’s suck it up, get real and move on.

So our story continues with the checked in code that contains a bug as follows.

Bool myBuggyTestCase
{

bool testPassed = false; //Default should be test has failed

//Do a bunch of things for setup
…

//Invoke the API(s) we are interested in
…

//Check the thing worked
testPassed = VerifyThingsAreFine();

//Do the required cleanup
…

//This could be a lot of cleaning – hang in there
…

return true;

}

The problem here is that we do correctly obtain the pass / fail in the line:

returnValue = VerifyThingsAreFine();

however by the end of the test module, we just return a constant value of “true”. In the dry run that we do of this test case, where we step through the code, we find the API does what it supposed to and the returnValue = true as expected. We also step through and verify that the value actually returned by the module and logged in the automation harness is true (of course missing that fact that it is actually the hardcoded “true”). Now we are all setup for trouble. All that needs to happen now is a regression – an API has to stop doing things the way it is actually doing it currently and then all of a sudden we find (or rather not-find) that even though returnValue is correctly calculated as “False” the value returned is still “True”. This test case will happily go on logging this scenario as “Pass” till the end of eternity (or a breaking API change causing an exception or compile time failures – whichever comes first).

We sort-of have started avoiding this problem by throwing exceptions in the test code when a failure case is hit, expecting the automation harness to actually catch and log those as failures. This works much better at avoiding errors such as the one above, but has it’s own gotchas since many times you might be interested in catching exceptions and logging some information about the state you are in. Ideally you should rethrow the exception after you’re done logging, but humans have a tendency to make the same mistake in wonderfully different ways – so we might not.

Another approach that can help ameliorate this situation is the use of intentional programming which would make the code much more lean and mean, thus making the bug a little more easier-to-spot (currently I think the long cleanup parts of the code can cover up this issue as well).

But wait there is more – remember when I mentioned that you might just run some test cases only ½ a time (and you mumbled to yourself “whatever that means!”)? Well what I was referring to was the fact that when you tend to have a lot of similar test cases which are using well factored-out code (so that they all look terribly similar), you will not (and I’m ready to bet on this!) run through each of these cases. In fact you will, like any other tester with his head-screwed on tight, put break-points at key places and run through the cases by ensuring things at those break-points are as expected. But that does mean that a lot of code paths will be running “unanalysed” – with the usual baggage that comes with that word (such as unintended goof-ups).

This phenomenon is exacerbated in Model Based tests, since the test cases are by definition dynamic and so many that you cannot step through each one of them. You step through the action handlers and try and make sure things will work as designed. Plus you tend to get lost in all the jargon such as Action Handlers and Transition Rules. Net effect is that the test code which will be executed in millions of different ways, would have been stepped through for only a handful. Of course, this is exactly what we want for model based tests as well, but it just goes to highlight that the few we walk through and take a hard look at, need to be looked at REALLY HARD!.

DCRs don’t help in the least since you end up patching code on top of existing code creating the classic sphagetti (with no marinara sauce).

So, that brings me to the main agenda (I knew we’d get there someday). Here is a small bullet-list of things I believe can be useful when doing a test plan/code/coverage review (we’ll leave the differences between these for another day).

Make the test case FAIL. I think we don’t do this enough and it is the most important aspect. It is in fact the whole purpose of creating the test code – you hope that someday it fails and catches a regression. So make sure you cause failures and check if the net of your test code can catch those fish or not. Sometimes this is too easy (you just say “of course it will fail if I do that”) and therefore doesn’t get done and sometimes the excuse is that it is too hard (“how the hell do I get that to occur!").
Run through test cases in different buckets. Run through them end-to-end – right from setup, invoking the API(s), clean up, logging etc.
Refactor and modularize code so that we hopefully do the things where goof up is most costly only in a single place.
Look at refactored, modularized code that is called again and again and again using different data sets. The potential damage that bugs in these areas have, is much larger, so spend more time on them.
Spend time on algorithmic and mathematical sections. If you doing something fancy in your test code, make sure it gets looked at more than other parts.
This one would be my favorite but something I don’t see happening in the near future - injecting product code with bugs to see if the test harness can catch those bugs. This would of course entail not checking in the bugs, the “buggy” version of the software is purely a test exercise to check the effectiveness of the test cases being automated. This also goes by the name of Mutation Testing and was recently covered in this MSDN Magazine article.

One more solution that I know some teams do take is to hold the test code to the same bar and same vigorous processes that product code has to go through. I haven’t tried this first-hand but my gut feeling is that it will bog down testing more than the value it will provide. But it would be interesting to hear from someone who has actually tried this and found this to be “the fix”.

What other things would you do to make your test code more reliable? Are these steps even practical to do in the real world? What would be practical?

Spot the Bug Contest #1 Solution: The mystery of the Decimal.Parse FormatException

nihitk — Sun, 27 Mar 2005 05:31:00 GMT

Well - as promised here is the solution for the Spot the Bug (contest?) posting which was correctly answered first by Nat (Congratulations!).

The Bug:
The following line of code will fail intermittently when executed and most of the time rerunning will work. Sadly, these are the sort of bugs most easily overlooked.

return Decimal.Parse(rand.NextDouble().ToString());

where rand is a Random class instance. The exception thrown is:

FormatException Input string was not in a correct format.

What is bewildering is that on the face of it this seems like a perfectly legitimate line of code - we are simply converting a value from a Double in the range 0.0 - 1.0 (since that is what NextDouble() returns) to a Decimal value. The boundary conditions are both well contained within the Decimal range.

The only way out is to write a quick and dirty app to simulate this failure and here is what I wrote (no comments for sake of brevity):

static void Main(string[] args)
{
      Decimal decNum; Random rand = new Random(); String str = "";
      for (long counter = 0; counter < long.MaxValue; counter++)
      {
            try
            {
                  decNum = Decimal.Parse(rand.NextDouble().ToString());
                  if (counter % 1000 == 0) Console.WriteLine("Iteration: " + counter);
            }
            catch (FormatException ex)
            {
                  Console.WriteLine("Iteration: " + counter + "\nDouble value string: " + str);
                  Console.WriteLine("Exception occured: " + ex.ToString());
            }
      }
}

Running this console app with a breakpoint set inside the catch block, immediately bubbles up the root cause. The crux of the issue turns out to be that this exception occurs when the random Double value generated is so small as to need scientific notation. E.g. the double 0.000083304941692997209
will return "8.33049416929972E-05" when you do a Double.ToString() and this scientific representation is in turn not an acceptable input to the Decimal.Parse method, causing it to throw the FormatException. Mystery solved.

The Fix:

return (Decimal)rand.NextDouble();

Seems like the simpler and more logical way to write this in the first place, but that's only because this is a simplified case for illustration of this bug.

I already have another spot the bug lined up - just need some time to write it up. In case you have any such interesting bugs that you have hit as well (solved or not) that you would like to share, let me know!

SDET Memes

nihitk — Sun, 23 Jan 2005 22:56:00 GMT

Starting to see a lot of good discussion about what it means to be a test developer and the practices, ideas and challenges that go into being a successful test developer. In this post I want to talk about some insights about what I find challenging about this role and a question as old as the chicken and the egg conundrum:

Are test developers, just wannabe developers?

This is a thought that crosses the mind of most people who have worked as or with test developers (also known as Software Design Engineers in Test or SDETs) within Microsoft.

Being someone who originally came from that traditional school of thought that testers are just developers who couldn't make it as devs (similar to dentists being labeled as doctors who couldn't make it), it has taken me some time to wrap my head around the SDET job description and grow an appreciation for it. You also have to pacify your ego and let go of the prejudices. Well I did and now I am hooked onto it and think it offers a lot of great incentives not available to a traditional SDE, such as flexibility in coding, high-level view of the system and a more egalitarian workload across the product cycle. All these and more are tackled by Steve Rowe in his blog postings about why a test developer role is better than a traditional developer role and why test developers are just as "real". I liked the posts and ran into them through the Careers@Microsoft posting.

Other than these, one additional challenge that I have just begun to realize, is that as a tester, you are always trying to cope with a lot of theoretically hard problems (testing space in most cases is unbounded) and I find dealing with this computational complexity especially rewarding. It's like trying to tame a wild horse...:)

You can also read up over here, about differences between the STE / SDET positions and how vague and thin the line really is at times.

Spot the Bug

nihitk — Sun, 23 Jan 2005 20:40:00 GMT

Ran into this recently and thought it might be interesting.

Can you try and spot the bug and the possible error that can occur with the following lines of code?

Decimal randomDoubleAsDecimal()
{
Random rand = new Random();
return Decimal.Parse(rand.NextDouble().ToString());
}

Solution in the next post.

Grads Getting Good Guidance

nihitk — Mon, 17 Jan 2005 04:55:00 GMT

Joel offers some great tips to Computer Science students (or really anyone in college who is a geek and likes software and programming) who will soon be graduating - very practical advice. In addition, it would be great to see fresh graduates trying to incorporate testing into their goals as well. I took a look at one of my undergraduate projects (Static Analyzer for C++) and was amazed by how little testing we did on it. Maybe if graduates spend more time on testing and automating some of the tests for their projects, they will also develop an appreciation for the challenges and rewards that testing holds. Well - guess it's never too later too start. Would love to hear from anyone who actually used some automated testing for a college project of theirs?

Take a look at the internship options at Microsoft - definitely one of the most pampered and exhilarating internships (can vouch since I have been one myself) - and don't forget to ask for a test position if you think it might be your cup of tea!

Are we there yet?

nihitk — Sat, 01 Jan 2005 01:14:00 GMT

So have we reached the top of the graph predicted by Moore's law? Seems like it (if not the top, very close to it), especially with respect to performance of a single, lonely processor. Herb Sutter has written a very nice article on how we are reaching the end of the road, or rather a bend in the road, which will require us to be much more aware of concurrency than we are at present. The article is slated to be printed in Dr. Dobb's Journal and the C/C++ Users Journal, in 2005 - but you can steal a sneak right now.

Interestingly, this article on the PC of 2005, in PCWorld, also mentions this exact same phenomenon, stating that few major hardware changes are expected in 2005. It even starts off with "Consumers thinking about buying a new computer in 2005 might be better off putting off their purchase until 2006" which is a very brave thing to say for a magazine which relies mainly on the health of the PC Industry!

So this might be a good time to read up on software concurrency and how it relates to development and testing of software. I know I need to.

P.S. - Wishing everyone a Happy New Year! May it be a peaceful and joyous one for all.

ZDrop for eBay Sellers

nihitk — Tue, 05 Oct 2004 22:46:00 GMT

Nice to read about this very cool tool, zDrop, running on Commerce Server which helps eBay sellers to easily and cost effectively post and manage items on eBay.

Would love to hear about any other publicly available tools you know of that utilize Commerce Server.

P.S. - Sorry for not posting in a while – have been working heads-down on the next release of Commerce Server. If you have any requests for features or any questions about the next release, feel free to ping me.

P.P.S – I am getting my first real-world experience with model based testing and loving it. It is like having a genius work for you (a very diligent and monotony-loving genius)…but there is quite a steep learning curve involved. Will write more about the lessons learnt, when I have actually learnt them…:)