The current document generation process used to produce the UTP 2 specs is limited with respect to the illustration of property/association end modifiers (i.e., unique, ordered, redefines, subsets, read-only, union). According to UML, those modifiers shall be illustrated after der name and type and multiplicity of a property. The following grammar rule (taken from UML 2.5, Clause 9.54) specifies the textual notation of properties:
<property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

’]

In the UTP 2 document generation framework the illutration of modifiers was circumvented in a way that is is close to, but different to the notation prescribed by UML. Although, the aligned notation of UTP 2 is okay from a readers point of view, it appears that the modifiers have not been consistenly illustrated. See two examples from the spec:

In section 8.3.2.7.17 TestDesignDirective , TestDesignDirective modifies are displayed before the name of the propery:

: RoleConfiguration [*]

Even though both ways are still good enough to comprehend, from an editorial point of view, one way should be preferred to other.

The current document generation process used to produce the UTP 2 specs is limited with respect to the illustration of property/association end modifiers (i.e., unique, ordered, redefines, subsets, read-only, union). According to UML, those modifiers shall be illustrated after der name and type and multiplicity of a property. The following grammar rule (taken from UML 2.5, Clause 9.54) specifies the textual notation of properties:
<property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

’]

In the UTP 2 document generation framework the illutration of modifiers was circumvented in a way that is is close to, but different to the notation prescribed by UML. Although, the aligned notation of UTP 2 is okay from a readers point of view, it appears that the modifiers have not been consistenly illustrated. See two examples from the spec:

In section 8.3.2.7.17 TestDesignDirective , TestDesignDirective modifies are displayed before the name of the propery:

: RoleConfiguration [*]

Even though both ways are still good enough to comprehend, from an editorial point of view, one way should be preferred to other.

Curently, UTP2 supports capturing actual results of a Test Set or a Test Case execution via its Test Log capability. A TestLog is an instance of a Test Log Structure that shall specify, what exacty is to be logged. However, the current UTP2 specification does not specify, how such a Test Log Structure is to be expressed. Furthermore, when one or more Test Logs have been instantiated (after executing some Test Sets or Test Cases), the tester may whish to extract only those parts of an existing (potentially huge) Test Log that are relevant to investigate a specific problem. This is not supported by the current UTP2 specification.

Test planning should incorporate schedule and budget. Should it have the equivalent of a Gantt chart? How do we incorporate a time phased approach and get that embedded into the standard? TestExecutionSchedule helps allude to schedule, but the spec would benefit from more thought on this.

Is there a missing stereotype for instances of data ? In the conceptual section there is a mention of actual data pool which would be an instance specification of the data pool or data partition

Test planning should incorporate schedule and budget. Should it have the equivalent of a Gantt chart? How do we incorporate a time phased approach and get that embedded into the standard? TestExecutionSchedule helps allude to schedule, but the spec would benefit from more thought on this.

Is there a missing stereotype for instances of data ? In the conceptual section there is a mention of actual data pool which would be an instance specification of the data pool or data partition

Decision table testing is a major and frequently used black-box test design technique. In system and acceptance testing as well as testing of business processes, decision table testing is used to identify the test conditions within business rules by representing these rules in a tabluar format.

The Decision Modeling Notation (DMN) provides a MOF-based metamodel for modeling decision tables. Within the DMN, decition tables are an isolated part, well suited for being extracted as profile as part of UTP.

Incorporating a decision table profile into UTP, inspired by the DMN MOF-based metamodel, would improve UTP in the area of business rule testing and make UTP more complete regarding specification-oriented test design techniques.

Decision table testing is a major and frequently used black-box test design technique. In system and acceptance testing as well as testing of business processes, decision table testing is used to identify the test conditions within business rules by representing these rules in a tabluar format.

The Decision Modeling Notation (DMN) provides a MOF-based metamodel for modeling decision tables. Within the DMN, decition tables are an isolated part, well suited for being extracted as profile as part of UTP.

Incorporating a decision table profile into UTP, inspired by the DMN MOF-based metamodel, would improve UTP in the area of business rule testing and make UTP more complete regarding specification-oriented test design techniques.

Curently, UTP2 supports capturing actual results of a Test Set or a Test Case execution via its Test Log capability. A TestLog is an instance of a Test Log Structure that shall specify, what exacty is to be logged. However, the current UTP2 specification does not specify, how such a Test Log Structure is to be expressed. Furthermore, when one or more Test Logs have been instantiated (after executing some Test Sets or Test Cases), the tester may whish to extract only those parts of an existing (potentially huge) Test Log that are relevant to investigate a specific problem. This is not supported by the current UTP2 specification.

The .xmi files for the UTP2 have links that do not work. Even when separately going to the OMG UML site and downloading the StandardProfile.xmi and the PrimitiveTypes.xmi, unable to load the utp2.xmi profile. Tool vendor (Cameo Systems Modeler)--they suggest that the problem is in the references in the profile. In the utp2.xmi import may be getting stuck on the UML.xmi "used project". It will not let me manually select the UML.xmi file as it says "NOT A USED PROJECT!" Many permutations of installation have been attempted. This is preventing effective use of the standard in its application of test to our system model.

The .xmi files for the UTP2 have links that do not work. Even when separately going to the OMG UML site and downloading the StandardProfile.xmi and the PrimitiveTypes.xmi, unable to load the utp2.xmi profile. Tool vendor (Cameo Systems Modeler)--they suggest that the problem is in the references in the profile. In the utp2.xmi import may be getting stuck on the UML.xmi "used project". It will not let me manually select the UML.xmi file as it says "NOT A USED PROJECT!" Many permutations of installation have been attempted. This is preventing effective use of the standard in its application of test to our system model.

Error when attempting to open UTP 2.1 Library and Types Library. The same error message is presented when opening either file

"error on line 3 at column 80: xmlns:StandardProfile: ' http://www.omg.org/spec/UML/20161101/StandardProfile' is not a valid URI"

Error when attempting to open UTP 2.1 Library and Types Library. The same error message is presented when opening either file

"error on line 3 at column 80: xmlns:StandardProfile: ' http://www.omg.org/spec/UML/20161101/StandardProfile' is not a valid URI"

Morphing should be between data pool and data partitions for a true structure morphing mapping from one format of data to another, look into other OMG specifications to bridge concepts

DRTD04 contradicts the definition of the constraint

Morphing should be between data pool and data partitions for a true structure morphing mapping from one format of data to another, look into other OMG specifications to bridge concepts

DRTD04 contradicts the definition of the constraint

Will SysML2 <<verify>> and UTP2 <<verifies>> stereotypes become the same eventually? This is a stereotype that seems like it could become the same in both specs if worked between groups. The different stereotypes lead to unnecessary complexity which hurts adoption for users trying to use both specs.

Section 8.3.1.4.5 describes verifies.

Does SysmL2 drop the <<TestCase>> stereotype and to UTP2, or will it be maintained.  What’s the expectation between rectifying potential conflicts/confusion in using both in the same model?

Given the constraints applied to the <<Alternative>> construct why would we not just simply have it extend the ConditionalNode instead of StructuredActivityNode?

See section 8.5.2.3.1

Same for <<Loop>> should be restricted to loop node metaclass

<<Parallel>> seems to have a contradiction between the description and the constraint "Application in Activities
In an Activity, «Parallel» must only be applied to SequenceNode". We think that this is meant to say a Conditional Node not a sequence node.

We feel that this definitional rule should be applied to the arbitration result not the specification. 

DRAS01 It is necessary that an arbitration specification determines exactly one verdict.

We feel like there should be a relationship defined between a test case and a test objective in which the role is defined as "acceptanceCriteria" (this may be captured by the arbitration specifications and underlying expected response and check property actions) so perhaps a better role definition would be "testCaseObjective" or "goal". 

Another idea is that if we make it best practice to use test objectives to capture initial requirement success criteria then the Arbitration Specification would refine or be a lower level of abstraction in some way.

Why is it that there are definitional rules for limits number of preconditions to AT MOST one, couldn't there be more than one?

There are definitional rules limiting the number of test levels and test types of a test context to AT MOST one,  think of scenarios where a test context may cover more than one type and level (the XMI shows the upper limit value to be * therefore not enforcing this rule).

Believe there is an error in the definition here " 8.6.1.2.4 DataProvider
Description DataProvider: A test component that is able to deliver (i.e., either select and/or generate) data according to a data specification.
The stereotype «DataProvider» is a specialization of stereotype «TestComponent». Such a test component is used to provide a data partition, represented as a Constraint extended by the stereotype «DataPartition» (SHOULD READ classifier extended by <<Data Partition>>), by generating some new data or by selecting some existing data from another data partition or a data pool according to some data specifications (represented as a Constraint extended by the stereotype 
«DataSpecification»)."

There are predefined test design techniques in the spec but don't have predefined test design technique structures to be the classifiers of the instances

How do we handle that a test item is a part of a particular system? How can we point to a part property of a composite structure? Can we use dot notation to say my test item is not just the type OpticalSensor but the UAV.PayloadCage.OpticalSensor ?

Why does the UTP not specify InstanceSpecifications of test configurations?  Perhaps we handle this through the test log structure to have test log entries that are instances of test configurations.

This was true for v2.1 but have not confirmed that they still exist in the xmi for v2.2

The following elements are found in the XMI file but not defined within the pdf spec:

• OpaqueProceduralElementArbitrationSpecification
• ProceduralElementASBinding
• TestCaseASBinding
• TestSetASBinding

It seems that this definitional rule should not be defined as a constraint on the test procedure but actually on the TestCase

DRTP04: It is necessary that each test case invokes at least one test procedure as a main procedure invocation.

Definitional rules don't have unique identifiers in the spec. For clarification, it would be good for these not to have repeated numbers.

Made the relationship between the arbitration result relationship to the testlogentry item, currently this is a directional relationship but made it a derived property specification for bidirectional linking therefore a tag value for verdict appears in every log entry type. We did this to make metachain queries in Cameo easier for generating a RVTM. 

In the current spec, non-navigable association ends (i.e., association ends that shall belong to the association) are still listed in the section 'Associations' of the stereotype on the other side.

See for example in section 8.4.2.5 TestConfigurationRole the following entry in the sub-section 'Associations':
: TestConfiguration

The spec should be cleaned up in that regard.

StateCoverage and TransitionCoverage have same ISTQB quote... I am pretty sure that is wrong

In the current spec, the abstract syntax diagrams reside in dedictated sub-sections directly underneath the conceptual context section (e.g., 8.7.2. Test Logging) they belong to. Stereotype definitions of ths conceptual context are grouped in a dedicated sub-section 'stereotype definitions'.

In UTP 2.1 RTF turned out that this structure does not support maintainability and modifiability of the spec. Everytime an additional diagram is added to the conceptual context section (maybe due to enhacements, clean-ups, better seperation and illustration of complex diagrams), the entire stereotype definitions need to be renumbered, because the respective diagram sub-sections and the 'stereotype specification' sub-section reside on the same level.

If the abstract syntax diagrams would be sub-sections of a section called 'Abstract Syntax', there would be no need to renumber stereotypes.

Therefore, I propose to make the spec more maintainable and stable by incoporating the following structure for every concepual context section in the spec.

8.7. Test Evaluation
8.7.1 ArbitrationSpecifications
8.7.2 Test Logging
8.7.2.1 Abstract Syntax
8.7.2.2 Stereotype Specfications

Why is the specification for TestObjective a value specification? What is the use case for making it a value specification versus a primitive string and are there any case studies/examples demonstrating the application of the an expression or opaque expression.

Figure 7.2 seems to imply that test requirements are derived from System requirements. Can we clarify the relationship between SysML requirements and UTP test requirements?

The arbitration specification binding mechanism that was introduced in UTP 2.2 supersedes the former binding of arbitration specifications directly from the stereotypes. This direct binding is deprecated (since it does not scale) and should be marked as such. It should be kept nonetheless for backward compatibility

[ES20311903]

the correct link is

https://www.etsi.org/deliver/etsi_es/203100_203199/20311903/01.05.01_60/es_20311903v010501p.pdf

The icons for the stereotypes should be added to the specification as a non-normative attachment.
Files for Icons would allow the specification to have a default set of common icons associated with the stereotypes, enabling users to use them without creating their own icons. This would also create a de facto style to aid in the adoption and consistency of implementations.

Note that icons should be provided as SVG. There is also a mechanism to include these icons in the XMI, but the SVG should also be a zipped attachment to the public non-normative attachments.

The caption says "estSetArbitrationSpecification" but it should be "TestSetArbitrationSpecification".

Graphics do not align between the UTP spec and the XMI.

The empty sections 8.7.1 Arbitration Specifications and section 8.7.1.1 Arbitration Facility are relicts from UTP 2.1. They should be removed from the editorial contents of the spec. This will cause a renumbering of current section 7.2 to 7.1 and current section 7.3 to 7.2. The renumbering affects all subsection of these two sections transitively.