Without much fuss, business-rule-based systems have increasingly become more commonplace.  As with all other IT systems, these systems must be tested before deployment to production.  Because of the special features and properties of these systems their testing differs from that of classical systems, and both test professionals and business analysts will need to adapt.

Customer focus

In today's competitive world, organizations aspire to be customer focused.  This requires the organization reacting and adapting in real time to changing demands of both consumers and business customers.  A customer-oriented organization places customer satisfaction at the core of each of its business decisions.  The more a business knows about its customers and their ever-changing needs, habits, and preferences, the more successful its strategies will be.

Changes to business decisions and rules are forced on organizations frequently through the imposition of new statutory regulations, government policies, or economic/market conditions.  Many businesses also modify their business rules as part of their attempts to capture new market share, minimize customer churn, and maximize revenue.  Operations and IT need to reconfigure to support this.  Most decision-making tasks are still performed manually and require retraining of staff.  No matter how excellent the training, manual decision-making is error prone, limited in efficiency (slow), and requires new hiring and training when scalability is needed.

The business case to automate decision-making tasks using rule-based systems is clear, especially where speed and scale are crucial.  EBay, for example, is powered by a rule-based system^[1] to rapidly evaluate thousands of business rules to determine how much of the price, if any, to withhold.  These rules relate to product category, seller reputation, and geographical location of seller and buyer, as well as regional legal regulations, transaction amounts, and currencies.  The eBay rule-based system ensures a smooth customer experience.

The ability to adapt and respond quickly is crucial for modern businesses.  Business agility and the agility of the business-supporting IT systems is becoming a strategic key concern for those who want to gain and maintain their competitive advantage.

Supporting customer focus

Business rules are the translation of business strategy, legal and regulatory rules, and business expertise into concrete operational guidelines.  Business rules are used in manuals, procedures, and IT systems.

One of the key roles of any information system is to enforce the business policies and business rules of the organization.  Business rules evolve frequently, in line with changing business focus, customer demands, market opportunities, and statutory regulations.

Rule-based systems purposely separate decisions (implementing business rules) from much more static processes.  This helps both business information analysts and IT staff to automate and deploy business decisions and business rules without the need for expensive and time-consuming custom coding.  As a result, this enables the business organization to respond and adapt much quicker to changing customer demands and changing regulations.  This also unshackles the IT department from updating code, allowing it to focus on technological innovation.

Updates to rule-based systems, however, are not supposed to go into production without thorough testing.  While this may seem obvious, the testing of rule-based systems poses special new challenges to the art and profession of testing.  Business rules have some specific features that make testing a particular challenge.

Organizing the IT support

Business decisions and rules extend and complement the business processes supporting a consumer-focused organization.  Decision models are developed to define how, and on what grounds, the business makes decisions, usually as a distinguishable part of a business process model.  Most large-scale organizations will have many business decisions, sporting thousands of business rules, all of which must be maintained uniformly across multiple information systems and organizational divisions.  Moreover, business rules are typically highly volatile.

Today, Scrum is seen as the most promising agile engineering approach to organize the perpetual changes to business decisions and business rules.  Since business-rule-based systems eliminate the need for (hard) coding business logic, there are no developers on the Rules Scrum team.  The Scrum team therefore consists only of the roles of product owner, Scrum master, business analyst, and tester.

Consider, for example, two User Stories — the first removing outdated and obsolete business logic, the second adding new business rules to the eligibility decision.  The User Stories are defined by the product owner role:

• As a business owner, I want outdated policy 743 removed from the eligibility decision so that eligible prospects can apply according to the current policy.


• As a business owner, I want the eligibility decision to comply with new policy 1450 and with the updated risk profile 543 so that eligible prospects can apply according to the current policy.

In a sprint, the first business analyst translates the high-level requirements ("user stories") to a decision model (representing the structure of the decision and defining rule groups) and detailed requirements (the business rules).  The tester at the same time validates the user stories and checks the changed decision models.  Next he designs test scenarios to validate the changes.  A second, somewhat more technical business analyst directly enters the business rules into the business rule management system (BRMS),^[2] while the tester immediately starts testing the effects of the newly-entered rules.

By contrast, classical coding of business logic would require much more of a change effort and would be a lot more risk prone.  How can we be sure that all coded conditions representing outdated policy 743 have been removed — and without unintentionally removing conditions of another policy?

The testing challenge

The speed this efficient team implements business rules allows for short Scrum cycles of one or two weeks.  Most of the time is spent verifying and validating the changes.  To test decisions and business rules, it is important to cover three separate (but interconnected) test aspects:  verification, validation, and simulation.

Verification

Verification is intended to check that a product, service, or system meets a set of design specifications.

Verifying business rules systems differs from the verification of classical systems.  The business rules engine is an already-tested component and can be considered functioning correctly.  This removes the need for 'unit testing' each individual rule by itself, along with all tests verifying that the rules themselves are executed correctly.  The integration of the decision component into the application landscape, for example, is tested simply by using a single rule that always returns Yes and, in another test case, using a rule that always returns No.  This is the preferred way to verify the integration because it eliminates eventual flaws in the interpretation of rules.

Verification of business rule systems basically concentrates on the questions:  "Is the business decision designed the correct way?" and "Does the outcome of the decision, in all cases, comply with regulations, requirements, or imposed conditions?"

To answer these questions, important points need to be checked:

• Syntactical correctness:  Formulation of the individual business rules according to, for example, RuleSpeak or the rule language of the specific business rule management system (BRMS) and rule engine.


• Decision model quality:  The correctness and completeness of the decision models, using the Decision Model and Notation (DMN).^[3]


• Logical consistency:  Having the same outcome under identical circumstances and inputs.


• Ambiguity:  Having no conflicts between two or more rules in a rule set or business decision.


• Completeness:  For each situation, there is an outcome.  This identifies eventual missing business rules, highlighting coverage gaps within a business decision such as between elements of, and at the edges of, a value range.  Some tools review existing rules and can automatically generate missing business rules.


• Redundancy:  Having the same condition only apply once.


• Logical Loop:  Detects logical loops across all rules in a rule set or business decision, thus helping find unintended loops that would cause the business logic to stall at runtime.

Modern business rule systems usually facilitate automatic rule checking,^[4] leaving considerably less manual validation testing compared to classically-coded applications.  Still, there are other non-rule-related points to be checked, for example:

• Scalability:  Does the architectural design allow for business rule execution being balanced and distributed across different servers?

Validation

Validation is intended to ensure a product, service, or system meets the operational needs of the various users and stakeholders.

By contrast, validating business rule systems differs less from that done in classical systems.  Validation still implies the question:  "Do I make the right decision?"  For example, is the business decision based on the right assumptions?  This question aims to assure a product, service, or system meets the needs of the customers and other business internal stakeholders.

In validation, these important points are checked:

• Compliance:  Do the decisions and rules adhere to the business policies, and also to the laws and regulations?  To validate this, decision requirements modeling and traceability of business rules to their sources is crucial.


• Operational validation:  Are the decisions and rules applicable in a practical manner to the business practices at hand?  To validate this, domain-based test cases are generated and a representative risk-based sample percentage is used to execute tests.

Because the frequency of change is high and the quality of decisions is important, automated regression testing in an early stage is generally advisable to detect undesired side effects of rule changes.

Simulation

Simulation is getting information about how something will behave without actually testing it in real life.

Certain kinds of change will require simulation and the testing of assumptions and different alternatives before deciding the actual change.  Simulation empowers business users to assess the results of proposed business rule changes and then to put the best results into production.  Simulation is a crucial part of the challenge since it helps to anticipate both positive and negative effects of rule changes.

• Testing new business rules using historical data and analyze the effects.


• Testing and simulating rule changes in order to detect undesired side effects by experimenting.


• Simulating what-if scenarios up front, and selecting the best from competing rule implementation strategies.


• Simulating various rule implementation forms and their effects on performance and correctness.


• Load simulation:  How does the (changed) decision service keep performing at high volumes?


• Process load:  Assessing the impact of business rule changes on the load of various (sub) processes.

Simulation complements verification and validation because it provides predictive information on envisioned developments and changes.

Adaptation needed

Business agility and business-rule-based IT systems are becoming more and more a strategic business-driven choice.  The competence to deal with these kinds of systems has become crucial to both business information analysts and test professionals.  Both complementary competencies need to gain respective business-decision- and business-rules-related expertise, along with additional expertise about verification and validation of decision models and business rules.

Along with acquiring the intellectual expertise, there needs to be an adjustment in mental state, from coping with a classical static world to being comfortable in a fast and ever-changing customer-focused environment.  Both the business information analyst professionals and the test professionals will need to go through stages of awareness and education in order to be prepared for customer-focused and highly-agile business-rule-based IT systems.

Conclusion

Organizations desire customer focus and wish to react and adapt quickly to the changing demands of consumers and business customers.  Business-rule-based systems deliver the IT agility to match the desired business agility and are gradually becoming more commonplace.  Business information analysts and test professionals are on the front line of this and will need to familiarize themselves with decision requirements modelling (DRM) and acquire business rules management (BRM) knowledge.

[1]  eBay is powered by Progress® Corticon® (https://www.progress.com/products/Corticon)  

[2]  For example using Blueriq BRMS and execution platform (https://www.blueriq.com)  

[3]  For example, using Decision Management Solutions 'DecisionsFirst Modeler' (http://decisionsfirst.com), supporting the Decision Model and Notation— DMN (http://www.omg.org/spec/DMN/)  

[4]  For example RuleXpress (http://www.rulearts.com/RuleXpress), a General Rule Book System, supporting SBVR (http://www.omg.org/spec/SBVR/) and RuleSpeak (http://www.RuleSpeak.com/)  

# # #