Handling of different AUT versions/configurations in automation

My main AUT is a standard system for pension, insurance and fund administration. Since business logic is complex for those areas, the AUT is also a very complex system with lots of functionality which normally for a typical major finance company are distributed at several different systems.

The AUT has a release cycle of at least 4 major releases/year and some test object properties changes for each release. In addition the AUT has different customer configurations which in worst case results in slightly different ways to handle the business logic.

How to handle that situation in automation in a cost effective way?

Well, totally unaware of what best practise is in this area I have implemented the following solution:

1. One of my favorite developers did on my request a web service where you get the AUT release number.
2. Using the WS I begin each test suite execution to store the release number into a parameter which is passed to most functions via a Dictionary (see prevoius posts).
3. Each test case data set has a customer configuration id which is also becomes a "global" parameter.
4. Within each test case code I use the parameters to handle release/customer specific behaviour by using if or select statements (not nice but it works)

If objParameter("Release") <= "2.3.1" Then
'Do the old way
Else
'Do the new way
End If

5. When a release no longer is supported (after a year or so) I remove statements which is absolete.

In some rare cases I have to branch a test scenario data set (which is a set of nested test cases) if for example the test case execution order changes due to major change of business logic.

Fortunatly in most cases a generic behaviour/test properties works for all releases and customer configurations...which is main idea for a standard system :-)

One advantage with this approach is that I need only one set of "production" automation code (no code branching which I guess is the main alternative) which can be executed to different test environments containing different versions/configurations at any time.

Since we also handle AUT service updates between the major releases for each customer this is quite handy I think since it allows for backward automation compability as well as new automation features does not have to be implemented to several code basis.