Comments on: Business Rules Management and Testing – Avoid the “Mystery Box” http://www.pathf.com/blogs/2006/06/business_rules__1/ Running commentary about agile development, user experience design and Ajax. Fri, 05 Mar 2010 19:33:43 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: Ladd Bethune http://www.pathf.com/blogs/2006/06/business_rules__1/comment-page-1/#comment-5434 Ladd Bethune Thu, 08 Jan 2009 20:17:57 +0000 http://www.pathf.com/blogs/2006/06/business_rules__1/#comment-5434 How do I get access to Peter Lin's paper on http://woolfel.blogspot.com ?? The blog is by invite only We are affiliated with New Wisdom Software and its product RuleGuide - a source rule management product thanks, Ladd How do I get access to Peter Lin’s paper on http://woolfel.blogspot.com ??

The blog is by invite only

We are affiliated with New Wisdom Software and its product RuleGuide – a source rule management product

thanks,

Ladd

]]> By: Marco http://www.pathf.com/blogs/2006/06/business_rules__1/comment-page-1/#comment-945 Marco Sat, 17 Mar 2007 15:24:59 +0000 http://www.pathf.com/blogs/2006/06/business_rules__1/#comment-945 <p>Good to read topics about Rule Validation and the reference made to unit testing. There is another part of testing that was not mentioned and I thought this might be relevant; It is called rule verification. </p> <p>For the difference between rule verification and rule validation see the whitepaper:</p> <p><a href="http://www.acumenbusiness.com/whitepapers/Agile%20Business%20Policies.pdf" rel="nofollow">http://www.acumenbusiness.com/whitepapers/Agile%20Business%20Policies.pdf</a></p> <p>I agree that the rule validation part can only be done by the business analyst. Only he has the knowledge of what the intent was of the rule.</p> <p>The next version of the Rule Manager will have a rule validation component. This allows to create 'unit tests' for just business rules, by business analysts.</p> <p>The Rule Manager is available as a free download from <a href="http://wwww.acumenbusiness.com" rel="nofollow">http://wwww.acumenbusiness.com</a> site<br /> </p> Good to read topics about Rule Validation and the reference made to unit testing. There is another part of testing that was not mentioned and I thought this might be relevant; It is called rule verification.

For the difference between rule verification and rule validation see the whitepaper:

http://www.acumenbusiness.com/whitepapers/Agile%20Business%20Policies.pdf

I agree that the rule validation part can only be done by the business analyst. Only he has the knowledge of what the intent was of the rule.

The next version of the Rule Manager will have a rule validation component. This allows to create ‘unit tests’ for just business rules, by business analysts.

The Rule Manager is available as a free download from http://wwww.acumenbusiness.com site

]]> By: Peter Lin http://www.pathf.com/blogs/2006/06/business_rules__1/comment-page-1/#comment-944 Peter Lin Sat, 08 Jul 2006 01:14:16 +0000 http://www.pathf.com/blogs/2006/06/business_rules__1/#comment-944 <p>I wrote up a quick blog about validation. hopefully this clarifies a bit what I mean by validation.</p> <p><a href="http://woolfel.blogspot.com/2006/07/what-constitutes-validation.html" rel="nofollow">http://woolfel.blogspot.com/2006/07/what-constitutes-validation.html</a></p> <p>peter</p> I wrote up a quick blog about validation. hopefully this clarifies a bit what I mean by validation.

http://woolfel.blogspot.com/2006/07/what-constitutes-validation.html

peter

]]> By: Peter Lin http://www.pathf.com/blogs/2006/06/business_rules__1/comment-page-1/#comment-943 Peter Lin Sat, 08 Jul 2006 00:51:34 +0000 http://www.pathf.com/blogs/2006/06/business_rules__1/#comment-943 <p>Good comments. I'll try to explain more clearly what I mean by validation. The short explanation is testing the rule, ruleset and rulebase to make sure what gets deployed is valid. You make a good point that a single ruleset may be valid for one dataset and invalid for a different dataset. I've seen this first hand, so in my mind, the validation should be flexible and modular. I've blogged about this in the past, but in random incoherent spurts. A few years back I wrote up a 40 page functional specification describing a design and architecture for rigorous rulebase validation. Clearly, leaving out validation is asking for trouble. My bias preference is to have that as part of the authoring. The reason for that is this. We the system allows a rule to become active and is set to be deployed in the near future, how should the system deal with it? Should it exclude the rule automatically? Should it try to fix the problem? Should it include the rule, but disable it? I would prefer to tell the rule author the rule is bogus or bad as they are writing it. That way, the user gets feedback sooner than later.</p> <p>peter</p> Good comments. I’ll try to explain more clearly what I mean by validation. The short explanation is testing the rule, ruleset and rulebase to make sure what gets deployed is valid. You make a good point that a single ruleset may be valid for one dataset and invalid for a different dataset. I’ve seen this first hand, so in my mind, the validation should be flexible and modular. I’ve blogged about this in the past, but in random incoherent spurts. A few years back I wrote up a 40 page functional specification describing a design and architecture for rigorous rulebase validation. Clearly, leaving out validation is asking for trouble. My bias preference is to have that as part of the authoring. The reason for that is this. We the system allows a rule to become active and is set to be deployed in the near future, how should the system deal with it? Should it exclude the rule automatically? Should it try to fix the problem? Should it include the rule, but disable it? I would prefer to tell the rule author the rule is bogus or bad as they are writing it. That way, the user gets feedback sooner than later.

peter

]]>