blob: efaea24b21f71419485b9b04ae054f4ae6587e7a [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" xmlns:epf="" epf:version="1.5.1" xmlns:rmc="" rmc:version="7.5.1" xmi:id="-LP0SlsHoERAIzSe1UpKmlw" name="build_test_scenario,_1dlWkH3GEd2sJcA0evSBQw" guid="-LP0SlsHoERAIzSe1UpKmlw" authors="Jerome Boyer" changeDate="2008-09-22T09:48:44.000-0700" version="7.5.1">
style=&quot;FONT-SIZE: 10pt; FONT-FAMILY: 'Times','serif'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: DE; mso-bidi-language: AR-SA&quot;>&lt;font
face=&quot;Arial&quot;>Developing without testing has no sense today (we hope!). Developing rules deployed in rule engine
helps&amp;nbsp;us supporting efficiently a Test Driven Development approach. Rule set can be isolated&amp;nbsp;early in the
development process and can be tested in a sandbox environment. Writing tests before the rule makes testing part of a
validation feedback loop.&amp;nbsp;&amp;nbsp;So during the harvesting phase the analysis team needs to develop test scenario
and data elements to support the rule writing and testing. Working on concrete scenario leads to clarify ambiguities,
find holes in the decision processing, and enhance rules decision coverage, and the overall quality.&lt;/font>&lt;/span>
At this level the scenario description can be built as user story with persona involvement, and data point to
illustrate the scenario.