Posted by: ahmedashfaque | September 21, 2014

Lessons learnt: Testing complex business logic

Once I was involved in testing a business component which was extremely complex. This component was supposed to make a business transaction under varying business scenarios. Based on applicable hard and soft constraints, it was supposed to return possible business transactions and the end user was supposed to pick one of the transaction and committ it. It had some 20 main constraints. These constraints were further divided into many sub constraints. In total there were some 500 constraints. The problem was further exascerbated by the fact that some of these constraints were hard constraints whereas others were soft constraints.

The hard constraints could never be overridden but the soft constraints could be overridden. That meant, if a hard constraint is applicable in a business scenario then transaction could not take place. In such cases, a test case will fail and no further testing is required for that business scenario. However if in a business scenario, a hard constraint as well as a soft constraint is applicable at the same time then the soft constraint will be overridden and only the hard constraint will be applicable. Testing this component was a daunting task indeed because for any transaction, tester had to check for all these constraints (numbering 500) in one test case!

Initially no tester was ready to take this challenge. Then a brain storming session was organized consisting of a team of line managers, business analysts and testers. All of these people were obviously not at one place so the session took place in the cyber space, over a virtual conference call. After breaking our heads for 3 hours, over 3 sessions of one hour each, a strategy was evolved. It was decided to make a decision grid which will guide as to when a transaction will take place or not, based on the test data input as well as prevailing business scenario for that test case. Each prevailing business scenario was identified later and test cases created. In each business scenario, which constraints were applicable and which were not was clearly indentified. Similarly whenever a soft constraint was applicable, it was made sure if any hard constraint was overriding it or not.

Finally test data was created on the testing system and testing got started. Later most of the test cases were ported to test the production instance as well.

Sometimes brain storming sessions work!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: