In UTP 1.1 there are two predefined time-related types: Time and Duration. Time is used for starting a timer (Timer::start(expre:Time)), so it represent rather a Duration. In addition, time is ambiguous, because it is not clear what time actually represents, a particular point in time or a duration of time units.

Since UTO already defines a Duration type to express a duration of time unit, Time should be renamed to Timepoint to cope with particular points in time. Concrete timepoint formats are not given by UTP.

Furthermore, Timer should offer a second start() method with the signature Timer::start(duration:Duration). The user would be able to decide whether a time should timeout at a certain point in time or after a given duration.

The RTF agreed that the UML Testing Profile should allow to set both a duration and a timepoint for a timer to expire. This is consistent with the UML simple time concepts, where a user can express TimeEvents in terms of Duration or TimeExpression. However, it is not the intention of UTP to predefine or determine the concrete format of a Timepoint or Duration. There is ongoing work within the OMG to standardize those things.
Additionally, the RTF agreed on setting a constraint how values/instances of these two primitive types have to be expressed. In order to align the imperative timer concept of UTP with the declarative one of UML simple time, instances/values for utp::Timepoint shall be expressed as utp::TimeExpression with type set to utp::Timepoint. Consequently, instances/values of utp::Duration have to be expressed as uml::Duration with type set to utp::Duration. Again, the concrete format of such a ValueExpression is not predefined and is left open to the user. Finally, the predefined Timer interface of UTP should offer operations to start a Timer with either a Duration or Timepoint for expiration.

There was an error introduced into the textual definition of ValidationAction during the sophisticated restructuring of UTP 1.0 to UTP 1.1.

So actually, ValidationAction should extend CallOperationAction instead of Dependency (as it is correctly depicted in the abstract syntax)

This is indeed a copy and paste error. The abstract syntax and the machine readable files are correct, but the wrong base class is mentioned in the specification document. This will be changed accordingly.

During UTP 1.1 revision, the entire document structure has been modernized, cleaned-up and restructured. However, there are several typos and style glitches in the current specification, which mostly originated from copy and paste errors.

In addition, some of the figures need polishing as well (e.g. Figure 7.8, Figure B.14, Figure B.23, Figure B.26, Figure B.28)

Some obvious copy and paste errors as well as typos are addressed by this issue. However, part of the resolution is the submission of new issues requesting the correction of several figures (in particular in the examples section) and the harmonization of the style of the specification with other profiles. In case the task force decides to have a proprietary style guide, it must be assured that the style guide will be applied consistently throughout the specification.

Currently, UTP consists of four conceptual (not technical) packages: test architecture, test behavior, test data and timer concepts.

The concepts which are described within those packages (which are represented as different subsections in the normative section of the specification) can be further separated.

For example, timing (all concepts of timer concepts package) is mainly associated with test behavior. A timer can only be started if a behavior is executed. It might be more consistent to move the concepts from timer concepts into test behavoir as well, since it is clearly dedicated to test behavior.

Another example are some concepts which clearly belong to the test management area like TestObjective and/or TestLog. Those test management concepts are part of UTP since its adoption by OMG, so it would just be consequent to establish a new package exclusively for test management concepts.

A more consistent conceptual package structure could look like this:

1. Test Architecture
2. Test Behavior
2.1 Test Case and Defaults
2.2 Test Actions
2.3 Test Timer
3 Test Data
3.1 Wildcards
3.2 Test Data Structure
4. Test Management

The RTF agreed that having a modernized and polished specification document is highly beneficial. Therefore, a new outline and new introductory chapters have been written. Except from changes in the outline and introductory sections, this resolution does not change the semantics of a stereotype.
NOTE: For the sake of clarity, this resolution is split into two parts.
The first part incorporates only changes from section 1 (Scope) to 6 (Additional Information). These changes are marked with the issue tag (Issue 17224 (part one)) and are incorporated into the intermediate convenience document with change bars.
The second part incorporates changes from newly created section 7 until the end of the document. These changes are marked with the issue tag (Issue 17224 (part two)) and are incorporated into the final convenience document with change bars. The second part is responsible for several new sections, section and figure renumbering. The issue marker in the change-bared convenience document provide information whether this section has been newly incorporated or changed. This ensures a direct traceability from the old document structure to the new one.

UTP is a specification for the creation of model-based test specififcation, thus, it has an important and meaningful role in the realm of model-based testing.

Unfortunately, the introductory chapters do not mentione, nor define, model-based testing, test model or any relevant concept related to MBT techniques. As the first and the most sophisticated standardization approach of MBT concepts, the UTP specification should be much clearer on its purpose and relationship to MBT.

In fact, being incepted and mostly written almost 10 years ago, UTP needs a modernization polishing.

The RTF addressed this issues with the restructuring of the specification itself.
Disposition: See issue 17224 for disposition

The term 'LogAction' actually refers to the element FinishAction. So it should be renamed to 'FinishAction' and a new term for 'LogAction' should be included

This issue addresses a flaw in the terms and definitions section and was most probably a result of the refactoring of UTP 1.1 revision.

Since TestComponents can define test-relevant behavior, it must be ensured by definition that each base class of a TestComponent is also a BehavioredClassifier.

Behaviors for test cases can be expressed as operations in the test component, for example. To make this formally and by definition possible (and if we do not change the base class of TestComponent to Property - see previously submitted issue by me), we should also extend BehavioredClassifier and make clear that a base class, to which <<TestComponent>> is applied must be both a StructuredClassifier and BehavioredClassifier.

RTF agreed on narrowing the possible metaclasses the stereotype <<TestComponent>> down to uml::Class. Furthermore, uml::Behavior and uml::AssociationClass is excluded from the list of extendable metaclasses by a constraint, because they just do not make sense to be treated as a test component. This results in three concrete metaclasses where <<TestComponent>> can be applied to, which are: Class, Component and Node.

TestLog describe the actual execution of a test case against the SUT it was stimulating. A TestLog is described as concrete subclass of Behavior.

For particular behavioral descriptions (Activity, Interaction) the tets log allows the integration of more details for the exeuction of a single test step, e.g. a timestamp when this test step (sending of a message, performing a validation action, ...) has been carried out by the test execution environment.

Therefore, there should be at least for test log's represented as Interaction and Activity a concept like the following:

TestLogEntry extends OccurrenceSpecification/Action

The RTF agreed on introducing a new concept called TestLogEntry. A TestLogEntry can be combined with the ordinary Behavior concepts, but must be included in a Behavior stereotyped as TestLog.
As in the summary suggested, a TestLogEntry will have an only one tag definition solely, namely timestamp. The timestamp represents the point in time when a corresponding test step during a test case execution has actually been executed. Such a timestamp is part of almost every test execution tool and test case log. It helps in analyzing the log and to reveal time-dependent issues.
The RTF decided to base TestLogEntry solely on OccurrenceSpecification of Interactions. The RTF is not aware of any tooling or method that logs test case execution as Activity or StateMachine, because a test case always represents an interaction between the test environment and system under test. This is represented in almost all tools as Sequence Diagram.

This is a correction for issue #15652:

In the resolution for issue #15652 we restricted the number of <<TestComponent>> lifelines that are covered by a <<DetermAlt>> to one.

This is too restrictive. There can be of course several test component lifelines being covered by the very same <<DetermAlt>>.

Possible resolution:
Remove the first paragraph in the semantics section

Change the first sentence of the current second paragraph from

If a deterministic alternative is reached during the execution of an interaction, the involved test component waits until it receives an input

to

If a deterministic alternative is reached during the execution of an interaction, the involved test component lifeline waits until it receives an input

• Remove constraint [2]

The way UTP 1.1 has refined or clarified the ‘determAlt’ ended up in a description identical to TTCN-3, the language where the ’determAlt’ concept was taken over from. The fact that the equivalent altsteps (in TTCN-3) are applied to each test component separately should not influence the way how this concept has to be applied in UTP. UTP should rather abstract from a concrete technical implementation and describe the concept according to the possibilities or semantics of UML Interactions.
In short, the resolution partially takes over what the issue submitter said, i.e. that more than one test component can be covered by a CombinedFragment with «determAlt» applied. Furthermore, some typos and misspellings will be corrected.

In most situation in the UML superstructure, the abstract metaclass ValueSpecification is used when flexibility should be granted to the user in how to model concrete values for an attribute/tag definition.

Using ValueSpecification allows a clear way for tools to deal with different ways of how user model values.

In the test management extension chapter, the tag definitions are typed as semantic-free string types, which makes it hard to calculate them automatically and to interchange the models.

Going from String to ValueSpecification would allow user to define their UML_compliant way of value modeling and still not restrict the user to a certain modeling method.

Example:

TestCase

A user could therefore provide an enumeration for priorities he uses in his test process like

MyPriorityKind

This allows the user to fill the priority tag definition of test case with a user-specific value of priority.

instance:TestCase{
slot{
definingFeature = priority
value=InstanceValue

}
}

Possible solution:
Change tag definition types in the test management extension chapter from String to ValueSpecifcation

The necessity to have additional and normative test management concepts available for several main artifacts in UTP is high. In UTP 1.1 we already introduced a set of optional concepts, mainly tag definitions that cope with some standard test management concepts. In this resolution we decided to move some of those non-normative tag definitions into the normative part, but keep the backward compatibility by declaring all tag definitions as optional, i.e. a lower multiplicity of 0. The main target was to harmonize UTP with industry-relevant testing standards, in particular with ISO 29119, IEEE:829-2008, ETSI and ISTQB. The RTF found that UTP should cope with the required information of this standards, since they represent a common knowledge of wat is deemed necessary to plan and document/report testing process, without being methodology-dependent. The RTF paid high attention to kep UTP as open ended as possible, but precise as necessary.
For TestLog the following tag definitions will be moved from the non-normative part to the normative part (in parenthesis a justification by stating what standards require the information): Tester (required by IEEE829, ETSI)
– executedAt (required by IEEE829, ETSI, ISO 29119, ISTQB)
– duration (required by IEEE829, ETSI, ISO 29119, ISTQB)
– verdict (required by IEEE829, ETSI, ISO 29119, ISTQB)
– verdictReason (required by IEEE829, ETSI, ISO 29119, ISTQB)
For TestContext, the RTF decided to move the following concept to the normative part:
– testLevel (required by ISO 29119, IEE829)
For TestCase, the RTF decided to move the following concept to the normative part:
– priority (required by ISO29119, ISTQB, ETSI)
– testType (required by ISO29119, ISTQB)
A precise definition of the changes is given below.
All time-related tag definitions reuse the UTP’s predefined primitive types Timepoint or Duration. All other tag definitions are typed as ValueSpecification, since this provides the highest degree of flexibility to the user. Instead of predefining a certain schema for test levels, priorities or test types, UTP rather allows to be tailored for any process or methodology. The RTF found that this information cannot be predefined by UTP at all, since they are varying from company to company, even from project to project.
The resolution will, however, show examples how the new tag definitions can be leveraged.
Furthermore, a new issue will be submitted to consider an additional library with some well-known values and concepts for test level (e.g. an enumeration of component, integration, system, acceptance etc.) or a quality schema for test type (e.g. ISO 9126, FURPS etc.). This will most probably solved and elaborated in in the upcoming UTP 1.3 RTF.

This issue is probably coupled with (at least related with issue #15941 http://www.omg.org/issues/uml-testing-profile-rtf.open.html#Issue15941) and targets a more convenient handling of UML instance specifications for test modeling to avoid redundancy.

TTCN-3 offer quite efficient and proven concepts to exploit already defined/created instance specifications (called template in TTCN-3). The concept is called "modifies" and allows the derivation of new templates by reusing existing templates.

See Clause 15.5 of TTCN-3 core specification (ETSI ES 201 873-1 V4.2.1) for further information.

UML is very inflexible with regard to the reuse of already modeled InstanceSpecifications. This may be caused by the fact that concrete data and InstanceSpecifications are rather pertinent and more used in testing than in other system development. However, the RTF agreed on having a dedicated concept in UTP that allows tester to exploit already existing InstanceSpecifications in order to defined large sets of complex data by avoiding redundancy. Therefore, UTP will get a new and very important, yet useful concept called Modification that resembles the modifies concept of TTCN-3.