Re: [ebxml-iic] 10/13/2003: Executable Test Case Package

[Monica Martin <monica.martin@sun.com>]

>Comment: What if there is not an executable test case?
>
>[MIKE] - In version 1.X or 2.0 of the Test Framework, it will be documented
>that if an Executable Test Case does not
>exist for a requirement, then the Test Driver simply moves on to the next
>Test Requirement defined in the Profile list, and flags
>the requirement as "not testable"
>
>What if it is
>specialized so it is tested? How can we verify the executable if we
>don't have a clear mapping between the abstract and executable?
>
>[MIKE] - The important linkage is to have  a clear mapping between
>an Executable Test Case ( or Cases ) and a single Test Requirement.  If an
>Abstract Test Case
>is represented as multiple "specialized"  Executable Test Cases, then the
>important mapping is really between
>the Executable Test Case and (its/their) Test Requirement.  An Abstract Test
>Case can be generalized,
>then implemented by multiple "specialized" Executable Test Cases.
>  
>
[mm2: Understood your explanation, thanks.  If we have an abstract set 
of test cases and we want to generate a test case stub (for those 
developing tools) we need some mechanism to verify that the executable 
test case is consistent with the abstract. Finally, even if we have an 
abstract test case and no executable one, I agree that the Test Driver 
sees it as non-testable at least by specification. Whether that is true 
in implementation, may or may not be true - I could see an industry to 
restrict what their level of rigor is and feel they could extend the 
test capabilities to test on set of functions.  In other words, they do 
implement the application knowledge to test some of those requirements.

>====================================================================================
>Envelope Element
>Comment: It seems with the inclusion of SOAP, RNIF, other to Envelope we
>may have parameters that dictate different security, reliability and
>packaging requirements on the test framework, and ultimately any
>conformance or interoperability specifications developed thereof. How do
>we maintain the integrity here or do we have a superset test framework
>that has different profiles in and of itself, or is this only allowed at
>the conformance or interoperability level? For example, taking the
>superset approach, how can we expect that the CPA ID will be a part of
>the configuration group? Does it change according to the conformance or
>interoperability being sought?
>
>[MIKE] - This is a very good question, and reflects the current issue of an
>"ebXML-centric"
>design scheme.  Perhaps a better schema for a ConfigurationGroup would have
>a "generic"
>parameter naming scheme, useable by any type of messaging:
>
>
><ebTest:ConfigurationGroup id="abc">
>    <ebTest:ConfigurationItem>
>        <ebTest:Name>myName1</ebTest:Name>
>        <ebTest:Value>myValue1</ebTest:Value>
>        <ebTest:Type>string</ebTest:Type>
>    </ebTest:ConfigurationItem>
>    <ebTest:ConfigurationItem>
>        <ebTest:Name>myName2</ebTest:Name>
>        <ebTest:Value>2</ebTest:Value>
>        <ebTest:Type>integer</ebTest:Type>
>    </ebTest:ConfigurationItem>
></ebTest:ConfigurationGroup>
>
>This would allow for passing of <ConfigurationGroup> defined parameters to a
>message or payload mutator,
>regardless of envelope type.
>  
>
mm1: This is better. Suggest you allow for multiple parameters of the 
same type (0...n). Thanks.

>Comments?
>Mike
>
>Thanks. Monica
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php.
>
>
>
>
>
>  
>