UTP12 — Tag definitions of test management concepts should be of type ValueSpecification

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.