UML Testing Profile 2 Avatar
  1. OMG Specification

UML Testing Profile 2 — Open Issues

  • Acronym: UTP2
  • Issues Count: 32
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLTP23-61 Empty sections shall be removed from the spec UTP2 2.2 open
UMLTP23-48 Make clear which elements are conceptually deprecated UTP2 2.2 open
UMLTP23-49 Typo in caption of that section UTP2 2.2 open
UMLTP23-47 Icons used in the specification should be included for implementors UTP2 2.2 open
UMLTP23-28 MTS Part 3 is wrong UTP2 2.2b1 open
UMLTP23-29 OMG UTP Graphics UTP2 2.2b1 open
UMLTP23-26 UTP should incorporate concepts to speciy decision tables for allowing decision table testing UTP2 2.1 open
UMLTP23-27 StateCoverage and TransitionCoverage have same ISTQB quote UTP2 2.1b1 open
UMLTP23-24 Non-navigable associations ends shall be removed from the spec UTP2 2.0 open
UMLTP23-25 Generators for and Queries on Test Logs UTP2 2.0b2 open
UMLTP23-22 Harmonize illustration of property modifiers in the spec UTP2 1.0b1 open
UMLTP23-23 Group abstract syntax diagram in separate sub-section for better changeability of the spec UTP2 1.0b1 open
UMLTP23-20 TestObjective UTP2 2.2b1 open
UMLTP23-19 Test Requirement UTP2 2.2b1 open
UMLTP23-18 Schedule in Test Planning UTP2 2.2b1 open
UMLTP23-17 Data Stereotype UTP2 2.2b1 open
UMLTP23-16 CompoundProceduralElements UTP2 2.2b1 open
UMLTP23-15 DRAS01 UTP2 2.2b1 open
UMLTP23-14 Relationship Between Test Case and Test Objective UTP2 2.2b1 open
UMLTP23-12 At most one precondition UTP2 2.2b1 open
UMLTP23-13 Test design technique structures UTP2 2.2b1 open
UMLTP23-10 DataProvider UTP2 2.2b1 open
UMLTP23-11 Data pool and data partitions UTP2 2.2b1 open
UMLTP23-8 Test configurations and test items UTP2 2.2b1 open
UMLTP23-9 DRTP04 UTP2 2.2b1 open
UMLTP23-6 Definitional Rules UTP2 2.2b1 open
UMLTP23-7 Elements are found in the XMI file but not defined within the pdf spec UTP2 2.2b1 open
UMLTP23-5 Arbitration result to testlogentry relationship UTP2 2.2b1 open
UMLTP23-4 Test Case Stereotype UTP2 2.2b1 open
UMLTP23-2 Cannot access XMI library and TypesLibrary for UTP 2.1 UTP2 2.1 open
UMLTP23-3 Verifies vs verify relationship UTP2 2.2b1 open
UMLTP23-1 XMI files reference non-working URLs. Cannot import into tool. UTP2 2.1 open

Issues Descriptions

Empty sections shall be removed from the spec

  • Key: UMLTP23-61
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP2 2.2 — Fri, 4 Oct 2024 08:26 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Make clear which elements are conceptually deprecated

  • Key: UMLTP23-48
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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

  • Reported: UTP2 2.2 — Thu, 26 Sep 2024 20:26 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Typo in caption of that section

  • Key: UMLTP23-49
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

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

  • Reported: UTP2 2.2 — Thu, 26 Sep 2024 20:51 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Icons used in the specification should be included for implementors

  • Key: UMLTP23-47
  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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.

  • Reported: UTP2 2.2 — Wed, 18 Sep 2024 14:48 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT
  • Attachments:


OMG UTP Graphics

  • Key: UMLTP23-29
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

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

  • Reported: UTP2 2.2b1 — Wed, 14 Aug 2024 21:59 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

UTP should incorporate concepts to speciy decision tables for allowing decision table testing

  • Key: UMLTP23-26
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP2 2.1 — Mon, 14 Dec 2020 21:24 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

StateCoverage and TransitionCoverage have same ISTQB quote

  • Key: UMLTP23-27
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

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

  • Reported: UTP2 2.1b1 — Sat, 22 Jun 2024 21:34 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Non-navigable associations ends shall be removed from the spec

  • Key: UMLTP23-24
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP2 2.0 — Fri, 10 May 2019 10:05 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Generators for and Queries on Test Logs

  • Key: UMLTP23-25
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    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.

  • Reported: UTP2 2.0b2 — Tue, 18 Dec 2018 15:50 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Harmonize illustration of property modifiers in the spec

  • Key: UMLTP23-22
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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>] [‘

    {‘<prop-modifier > [‘,’ <prop-modifier >]* ’}

    ’]

    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:

    {read-only, union} subDirective : TestDesignDirective [*]

    In section 8.4.2.5 TestConfigurationRole, modifiers are displayed after the name of the property:
    /roleConfiguration {read-only, union}

    : RoleConfiguration [*]

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

  • Reported: UTP2 1.0b1 — Fri, 10 May 2019 10:31 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Group abstract syntax diagram in separate sub-section for better changeability of the spec

  • Key: UMLTP23-23
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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

  • Reported: UTP2 1.0b1 — Fri, 10 May 2019 10:15 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

TestObjective

  • Key: UMLTP23-20
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:29 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Test Requirement

  • Key: UMLTP23-19
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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?

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:27 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Schedule in Test Planning

  • Key: UMLTP23-18
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:25 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Data Stereotype

  • Key: UMLTP23-17
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:21 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

CompoundProceduralElements

  • Key: UMLTP23-16
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:20 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

DRAS01

  • Key: UMLTP23-15
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:17 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Relationship Between Test Case and Test Objective

  • Key: UMLTP23-14
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:16 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT
  • Attachments:

At most one precondition

  • Key: UMLTP23-12
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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).

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:12 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT
  • Attachments:

Test design technique structures

  • Key: UMLTP23-13
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:14 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

DataProvider

  • Key: UMLTP23-10
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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»)."

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:07 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Data pool and data partitions

  • Key: UMLTP23-11
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:09 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Test configurations and test items

  • Key: UMLTP23-8
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:03 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

DRTP04

  • Key: UMLTP23-9
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 03:05 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Definitional Rules

  • Key: UMLTP23-6
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

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

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 02:44 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT
  • Attachments:

Elements are found in the XMI file but not defined within the pdf spec

  • Key: UMLTP23-7
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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
  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 02:50 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Arbitration result to testlogentry relationship

  • Key: UMLTP23-5
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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. 

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 02:42 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT
  • Attachments:

Test Case Stereotype

  • Key: UMLTP23-4
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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?

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 02:38 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Cannot access XMI library and TypesLibrary for UTP 2.1

  • Key: UMLTP23-2
  • Status: open   Implementation work Blocked
  • Source: Lockheed Martin ( Justin Nguyen)
  • Summary:

    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"

  • Reported: UTP2 2.1 — Tue, 15 Feb 2022 11:40 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

Verifies vs verify relationship

  • Key: UMLTP23-3
  • Status: open  
  • Source: Lockheed Martin ( Ms. Annemarie Kibbe)
  • Summary:

    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.

  • Reported: UTP2 2.2b1 — Sat, 23 Dec 2023 02:25 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT

XMI files reference non-working URLs. Cannot import into tool.

  • Key: UMLTP23-1
  • Status: open   Implementation work Blocked
  • Source: JHU APL ( Trisha Radocaj)
  • Summary:

    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.

  • Reported: UTP2 2.1 — Fri, 1 Apr 2022 14:36 GMT
  • Updated: Fri, 1 Nov 2024 01:16 GMT