After several iterations of intensive analysis, business modeling, agile rule writing and meticulous ruleset testing, your BRMS application is finally ready for prime time and just got deployed to production. So, quickly give yourself a pat in the back, and get ready to move on to some real testing action!

Because, while BRMS technology certainly makes our life easier for creation, update and deployment of business rules, it does not dispense us from performing thorough functional tests on the business decision services.

Testing, which is already a grueling activity in traditional software development, actually takes on some new twists with BRMS, the most obvious being “short notice”.

We promised to carry business policy updates to production in a matter of days or even hours. Now, in that short time frame, the rule changes must not only be analyzed, designed, implemented, but above all tested against defects that would potentially have severe business consequences. Below are a few non-technical recommendations to help you win the testing race.

Prepare for Change: One easy way to buy yourself some time for testing the change is to spend some time up-front preparing for it. It is essential to do some pro-active work with the SMEs and gather as much information as possible beforehand on the different types of potential change requests that can be expected, analyze and categorize them, and use this information to create a collection of re-usable test plans for these types of changes, whenever possible.

One important benefit of well-prepared and well-understood changes is that the testing can be delegated to resources with little or no business knowledge (e.g. pure IT Quality Assurance team members), thus relieving the SMEs for more knowledge-intensive changes.

Secure the SMEs Availability: Subject Matter Experts are key to help define pertinent test cases for complex changes. There should be an organizational commitment from the business owner to make the needed SMEs available to support the testing activity. Ideally, while a change is analyzed with the help of one SME for implementation, another concurrently writes test cases for the change.

In exchange for their time, the SMEs should be rewarded with a business friendly environment to compose their test cases. In the same way that the expression of business rules rely on a business-friendly vocabulary, the process of creating test scenarios should mask the underlying complexity of the object model. For this reason, the SMEs must be the prime source of requirements when the testing process and tools are elaborated.

Demand Mature Change Requests: As the project stakeholders start to witness the extreme agility of a well-oiled BRMS, they may become overly giddy and start to issue half-baked business change requests. Don’t shrug in disbelief: I’ve actually seen this happen! Half-baked change requests mean that the implications of the policy changes have not been fully studied and/or the understanding of the policy is not yet shared throughout the company. This is especially true when the surrounding business environment gets extremely competitive.

Resulting problems usually get uncovered during testing, as different SMEs may have a different interpretation on how the system should behave with respect to the policy change for certain uncommon test cases. Generally, getting an agreement on the outcome of these test cases will force a late iteration on analysis between the stakeholders and may delay the deployment of other pending changes.

If this type of risk materializes, it is important to assign to one of the stakeholders, let’s call him the Change Manager, the responsibility to ensure that each change request is fully understood and has been fully disseminated before it is considered for implementation.

Demand Complete Change Requests: Somewhat related to the previous point, some business policy changes involve multiple parts, coming from different business groups (e.g. Eligibility and Pricing), and the deployment must include all the parts to be consistent and complete. Here again, the Change Manager has the responsibility of verifying among the different business groups and LOBs that a change issued by one is supported by the others, and that all the needed parts are included in the change request.

Educate Stakeholders: Not all changes are born equal: introducing a typo in the text of a contract stipulation rule does not usually have any devastating business consequences. However, setting a single erroneous eligibility threshold within a decision table will lead to either turning away the good customers or taking on some overly risky ones. Both updates amount to a simple value changes in a single rule, but the consequences are quite different.

It is thus important to train the different BRMS stakeholders to recognize the risk, understand the difference in potential impact between the different cases, and appreciate that while the implementation time may be identical, the magnitude of required testing time and efforts is not.

In conclusion, we can see that the common thread here is “preparation”: prepare the people, the organization, the templates and the tools so that as much work as possible is taken out of the reactive task of change management.