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

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

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

Double-check that the LoginExample copes with the latest version of the spec.

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.

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.

Deferred due to lack of time

The RTF agreed that this a valid, but pure editorial issues. As explained in the issue description, the reason for these varying property modifiers lies in the document generation framework. Since all required information is available, though, the RTF agreed to resolve this issue in a future RTF.

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

Deferred due to lack of time

The issues requests a pure editorial change for better maintainability of the specifcation. The RTF agreed that the proposed change makes sense, but due to lack of time, the resolution of that issue will be resolved in a future RTF.

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.

Deferred due to lack of time

The RTF agreed that this is indeed a valid, yet pure editorial issue. The reason for showing non-navigable association ends in the stereotype specifications lies in the document generation framework that is used to produce the specification document. It is, at the moment, not possible to spare non-navigable association ends from the generation process. In the next RTF, it will be resolved by either enhancing the document generation framework in a way so that it can spare non-navigable association ends or by adding an editorial explanation to clause 6.2 Typographical conventions.

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.

Deferred due to lack of time

The RTF agreed that there should be a tighter integration between decision tables and utp2 to perform decision table testing. Due to lack of time, the RTF agreed to defer the resolution of this issue to a subsequence RTF

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.

Deferred due to lack of time

RTF agreed that this issues is a helpful extension to the language. It will, thus, be addressed in a future revision due to lack of time.

Double-check that the LoginExample copes with the latest version of the spec.

Deferred due to lack of time

This issue is still valid, but will be addressed in a future RTF due to lack of time.

"Figure 8.15 - Test-specific actions Overview" needs to be cleaned up. Stereotype shapes are overlapping.

Replace Figure 8.15 with new figure

RTF agreed to correct this pure editorial issue.

The specification documents (both ptc/23-04-02 and ptc/23-04-03) that were submitted with the UTP 2.2 RTF report (doc#: ptc/23-04-01) contained some issue with editiorial content. Some words that were set in (bold) blue do not represent links, but the typographical convention for these words are not given in the specification. Furthermore, the newly added clauses made not use of those links at all.

Complementary editorial/typographical changes from AB comments

The following resolution and the editing instructions represent complementary editorial corrections of the already submitted specification documents (both ptc/23-04-02 and ptc/23-04-03) because of the Ab review comments recieved after submission of the UTP 2.2 in May 2023 (doc# ptc/23-04-01).
The editing instructions describe only the delta of changes, thus, all the changes reported by the editing instructions of the formert report (doc# ptc/23-04-01) are present in the new specifications documents. In addition, the new submitted specification documents (ptc/24-07-02 and ptc/23-07-03) contain editing instructions as a result of the AB review of the former submission (ptc/23-04-01).

The machine-readable files submitted with UTP 2.2 RTF report (doc#: ptc/23-04-01) contained some syntactical issues that prevented the import of the machine readable files into compliant tools.

Minor editorial changes to the XMI

The machine-readable file for the UTP2 metamodel (utp2.xm, ptc/23-04-06) contained the following issues that prevent import/validity:

Issue in Line 1091
<ownedEnd xmi:type="uml:Property" xmi:id="_1CSfwPAuEeW2VZXfgcC2cA" name="referencedBy" type="_omHdQKJVEeS8gLY2208_PA" isDerived="true"association="_1CR4sPAuEeW2VZXfgcC2cA">

Corrected to:
<ownedEnd xmi:type="uml:Property" xmi:id="_1CSfwPAuEeW2VZXfgcC2cA" name="referencedBy" type="_omHdQKJVEeS8gLY2208_PA" isDerived="true" association="_1CR4sPAuEeW2VZXfgcC2cA">

Issue in line 1231:
<ownedLiteral xmi:type="uml:EnumerationLiteral" xmi:id="_MPcSIFeHEeihnpddrZbjug" name="implicitExpect"i/>

Corrected to:
<ownedLiteral xmi:type="uml:EnumerationLiteral" xmi:id="_MPcSIFeHEeihnpddrZbjug" name="implicitExpect"/>

Issue in Line 1566:
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="KAmGUHJKEemyx_XW_ukewg" name="extension_TestTechniqueStructure" type="_90Z0HJJEemyx_XW_ukewg" aggregation="composite"association="_KAc8YHJKEemyx_XW_ukewg"/>

Corrected to:
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="KAmGUHJKEemyx_XW_ukewg" name="extension_TestTechniqueStructure" type="_90Z0HJJEemyx_XW_ukewg" aggregation="composite" association="_KAc8YHJKEemyx_XW_ukewg"/>

There is an obvious misplaced change bar marker in the beginning of section "8.6.1 Data Specification". It needs to be removed.

Changebar not present anymore in UTP 2.1 official document

This pure editotial issue has been already fixed with the release of the UTP 2.1 document

UTP 2 defines for each element that may produce a verdict (i.e. test set, test case and all procedural elements), default arbitration specifications that prescribe how to calculate that verdict. The default arbitration specifications are optimized for functional testing, though. In case of testing non-functional aspects such as fault tolerance, performance or security, the rules to determine functional verdicts do usually not suffice anymore. Therfore, UTP 2 enables the definiton of proprietary arbitration specification (mainfested as stereotype <<ArbitrationSpecification>>) to grant the hightest flexibility possible to the user.

However, the current mechanism to associate a test set, test case or procedural element with a dedicated arbitration specification is restricted to only one arbitration specification. Even though this would be sufficient in many situations, the problem with the current binding mechanism is that the test set, test case or procedural element is literally changed by the binding. This may lead to situations where elements are copied only for the sake of associating a different arbitration specification to a that element. This is a situation that should be avoided under all circumstances.

We suggest adding a loosely coupled arbitration specification binding mechanism that keeps the elements and the arbitration specifications that ought to be bound to that element separated from each other. This would bring the benefit that test sets, test cases and procedural elements stay clean of any arbitration specification. This would also foster reusability of these elements.

The loosely coupled mechanism to bind arbitration specifications to the test sets, test cases and procedural elements could be based on a new concept 'ArbitrationDirective' , similar to the 'TestDesignDirective' concept that already exists in the language and proved its applicability. By doing so, users could define and assign an arbitrary number of arbitration specifications to a test set, test case or procedural element without technically modifying any of these elements.

Introducing an arbitration specification binding mechanism

The RTF agreed that the current arbitration facility is not flexile enough and will result in a number of duplicated model elements just for the purpose of assigning different pass/fail criteria. The RTF has developed an arbitration specification binding mechanism that loosely couples arbitration targets with arbitration specifications. Bindings can be overridden in a cascading manner that fosters reuse of existing arbitration specification.

The last paragraph of Clause 8.6.2 Data Values is an unintended left over from the revised submission. In the revised submission, there was the attempt to precisely define the semantics of matching ValueSpecifications. This attempt ought to be entirely removed. Thus, this paragraph should be removed.
For the sake of clarity:

Both stimuli and expected responses yield data values for distinct signature elements. A signature element is defined
as instance of either a Parameter or Property (i.e., this specification introduces a virtual metaclass SignatureElement that is the joint superclass of Property and Parameter and has at least the following attributes: type : UML::Type,
lower : Integer, upper : UnlimitedNatural). Given by UML [UML25], a "... Type specifies a set of allowed values
known as the instances of the Type." This specification denotes this set in the context of a SignatureElement
expressed as type(se), with type(se) as SignatureElement.type, and use T as abbreviation for type(se).
We specify
with se instance of SignatureElement and lower(se) as SignatureElement.lower and denote it by SE type.
A ValueSpecification V as an argument for a SignatureElement is specified as
These basic definitions are further used for the specific ValueSpecification matching mechanism extensions
introduced by UTP.

Remove last paragraph

RTF agreed to remove the last paragraph as it represents a relict from the initial submission.

Figure 9.3 shows a contained package "UTP Types Library" which is a relict from the initial submission. The UTP Types Library is a stand-alone library, technically unrelated to the UTP Auxiliary Library. This is also reflected in the machine readable files. Figure 9.3 needs to be corrected in that regard.

Replace Figure 9.3 with new figure

Task force agreed that this minor, pure editorial issue should be resolved by replacing the erroneous figure with a corrected one

This linebreak can be removed.

Issue not present anymore

The reported issue is not anymore present in the document with number formal/20-08-05.

This is an urgent issue, raised by the AB with respect to the correctness of the XMI files as well as the URI of the XMI files and the correct URIs mentioned on the cover page of the UTP 2.1 specification.

Correct XMI files and URI of machine-readable files for UTP 2.1

As discussed during the AB meeting at the Amsterdam meeting, the XMI file needed some cleanup and also the URI of the machine-readable files need to be corrected on the cover page.

The current TestDesignFacility og UTP 2 is based on the stereotypes TestDesignDirective, TestDesignTechnique, TestDesignDirectiveStructure and TestDesignTechniqueStructure. These elements are tightly integrated by means of the Profile's abstract syntax. So far, this is fine for the test design purposes. As such, the offered concepts support the definition of platform-independent instructions how to derive test cases, test data, test sets, test procedures and/or test execution schedules. These instruction can be put into effect by either a manual test designer or translated into the inpurt for a test generator.

UTP 2, however, is capable of describing test automation architectures (ISTQB TAA) or the architecture of automated testware - both terms are considered to be synonyms. In a test automation architecture, further activities need to be specified such as the generation of executable test code, the configuration and automated setup of the test execution environment and tool (setup and teardown of the automated test environment; compilation of test scripts, automated scheduling of test cases in a test set according to a given test execution schedule etc.), the configuration of the logging facility (e.g., depths and structure of logged information), the configuration of the arbitration specification (which arbitration specifications shall be used, linked to test cases, test sets and procedural elements, etc.).

All these configurations are essentials parts of an automatedt testware and can be used in combination or separately from each other (e.g., specifying a specific arbitration specification for verdict calculation on already executed set of test cases in a post-execution manner).

UTP is currently too restrictive and only offers concepts for configuring the test design activities. As a test modelling language designed in particular for test automation, UTP should offer also concepts for the other activities that need to be performed in an test automation solution.

Therfore, UTP should abstract from TestDesignDirective and TestDesignTechnqiue into abstract classes TestArchitectureDirective and TestArchitectureCapability (and the respective structures). That would, one hand, enables user-specific extensions in order to cope with the aforementioned, not yet supported concepts of test script generation, test execution, test logging and verdict arbitration, on the other hand prepare UTP 2 for potential improvements in that area in further revisions of the language.

Introduce an abstract TestDirective facility

The RTF agreed that an integration of an abstract test directive concepts (similar to the already existing and proved test design directive facility) enables test engineers to capture information relevant for carrying out certain test-related activities such as test design, test execution and/or arbitration. Allowing test engineers to model these kind of information opens the door for automating them.

UTP 2 offers currently rudimentary test log capabilities. It is possible to capture the minimal test execution information for test cases and test sets. These information are sufficient for the sake of coverage calculation or high-level test reporting, however, the details of a test case execution (e.g., the execution of CreateStimulusActions or ExpectedResponseAction) are completely omitted. This wastes a lot of potential UTP could offer for building test automation architectures like post-execution comparison/verdict calculation, incorporation of test execution traces from heterogeneous test tools in order to process the captured information solely on model level (raising the level of abstraction for automated results checking), comprehensibility or high-level failure analysis and test execution comparison (trends etc.).

As high-level test modelling language, UTP ought to provide at least a facility to enable sophisticated activities on fine-grained test execution logs by capturing the execution on procedural element level.

Enable logging on procedural element level

The task force agreed that the ability of abstracting from technical test logs into platform-independent test logs opens the door for UTP 2 to integrate the execution details of different test results potentially created by different test exeuction tools, as well as additional information such as information obtained from dynamic analysis tools by means of a single platform-independent language. UTP 2 may use these information for many purposes such as visualizing the executed test cases in a unique way; post-processing the execution results to calculate an overall verdict; perform further analysis like timing violations etc.
Having a single, integrated view on the results of test executions may become very conventient particulary in situations with heterogeneous testing landscapes where the eventual verdict of a test execution log has to be computed by a comprehensive analysis of diverse test execution logs.
UTP 2 can be seen as a kind of test information integration language that enables the specification and implementation of analyses over a set of originally seperated test execution logs.

Double-check that the LoginExample copes with the latest version of the spec.

Deferred due to lack of time

This issue is still valid, but will be addressed in a future RTF due to lack of time.