${taskforce.name} Avatar
  1. OMG Task Force

UML Testing Profile 2 (UTP2) 2.1 RTF — All Issues

Open Closed All
All Issues

Issues Descriptions

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

  • Key: UMLTP21-19
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP2 1.0b1 — Thu, 20 Jun 2019 15:11 GMT
  • Disposition: Resolved — UTP2 2.1
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 18:00 GMT

Abstract TestDesignDirective concepts into abstract TestDirective

  • Key: UMLTP21-2
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 2.0b1 — Tue, 23 Jan 2018 10:00 GMT
  • Disposition: Resolved — UTP2 2.1
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 18:00 GMT
  • Attachments:

UTP test log facility ought to enable logging on procedural element level

  • Key: UMLTP21-3
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 2.0b1 — Tue, 23 Jan 2018 20:30 GMT
  • Disposition: Resolved — UTP2 2.1
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 18:00 GMT
  • Attachments:

LoginExample is not in synch with latest Profile Specification

  • Key: UMLTP21-1
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

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

  • Reported: UTP 2.0b1 — Tue, 16 Jan 2018 09:17 GMT
  • Disposition: Deferred — UTP2 2.1
  • Disposition Summary:

    Deferred due to lack of time

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

  • Updated: Tue, 8 Oct 2019 18:00 GMT