Issue 15773: Contents and location of chapter 4 must be clarified (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Revision Severity: Minor Summary: Chapter 4 “Terms and Definitions” copes with defining a common terminology for the further specification. Its subsections reflects the logical packages of the UTP, hence it should be rather a subsection of chapter 6. Chapter 6 “The UML Testing Profile” deals with the profiles and its elements exclusively, so adding a subsection for defining a common terminology and providing an overall overview of the subsequently discussed profile and MOF-based metamodel (which are structured by the same logical packages) fits into the intention of chapter 6. It also concentrates the domain-specific knowledge of the profile’s concepts in the core chapter, what may help reader to find and retrieve information on a particular element. Additionally, chapter 4 must be thoroughly revised regarding its content. Currently, there is no agreement of what is included in the sections. For example, section 4.1 „Test Architecture“ contains all profile element‘s (and additional, logical concepts being no part of the profile) whereas subsection 4.4 „Timer Concepts“ just discuss a subset of the profile element‘s. Resolution: The Terms and Definitions section will be merged into just one section, so the distinction between the logical packages of UTP will be removed. To avoid redundancy, whenever a term is represented as a dedicated concept (a stereotype) in the UTP a reference to the more elaborated descriptions and semantics of the stereotype will be inserted. The information of the definition is not lost and was partially merged by the resolution of issue 15772 and 16105. Revised Text: Replace Text Replace the content of section 4 (including all subsection of section 4) with Arbiter See description of interface Arbiter (a predefined interface) Black box testing A test conducted without knowledge of the internal structure of the system under test. Coding Rule See description of «CodingRule» Component testing The testing of individual software components (see [ISTQB]). Coordination Concurrent (and potentially distributed) test components have to be coordinated both functionally and in time in order to assure deterministic and repeatable test executions resulting in well-defined test verdicts. Coordination is done explicitly with normal message exchange between components or implicitly with general ordering mechanisms. Data Partition See description of «DataPartition» Data Pool See description of «DataPool» Default See description of «Default» Glass box testing See White box testing Integration testing Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems (see [ISQTB]). LogAction See description of «FinishAction» Observation Test data reflecting the reactions from the SUT and used to assess the SUT reactions which are typically the result of a stimulus sent to the SUT. Scheduler See description of interface Scheduler in the Annex. Stimulus Test data sent to the SUT in order to control it and to make assessments about the SUT when receiving the SUT reactions to these stimuli. SUT See description of «SUT» System testing The process of testing an integrated system to verify that it meets specified requirements (see [ISQTB]). Test behavior Dynamic aspects of a test case or parts of the test components involved in the test case. Test case See description of «TestCase» Test Component See description of «TestComponent» Test Configuration The collection of test component objects and of connections between the test component objects and to the SUT. The test configuration defines both (1) test component objects and connections when a test case is started (the initial test configuration) and (2) the maximal number of test component objects and connections during the test execution. Test Context See description of «TestContext» Test Control A test control is a specification for the invocation of test cases within a test context. It is a technical specification of how the SUT should be tested with the given test context. Test Invocation A test case can be invoked with specific parameters and within a specific context. The test invocation leads to the execution of the test case. The test invocation is denoted in the test log. Test Log See description of «TestLog» Test Objective See description of «TestObjective» Testing The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects. [ISTQB]. Any activity which provide information on the qualities of a system under test. Timer See description of interface Timer (a predefined interface) Timezone See description of type Time (a predefined type) Unit testing See Component testing. Utility Part A part of the test system representing miscellaneous components that help test components to realize their test behavior. Examples of utility parts are miscellaneous features of the test system. Validation The process of determining whether or not the software and/or its specification meet system requirements and user needs at both functional and performance levels (see [IEEE1012]). Answers: Did we build the right product. Validation Action See description of «ValidationAction» Verification The process of determining whether the product of each step of the development process satisfies all of the “requirements” implemented from the previous step (see [IEEE1012]). Answers: Did we build the product right. White box testing Testing based on an analysis of the internal structure of the component or system. Wildcard Wildcards allow the user to explicitly specify whether the value is present or not, and/or whether it is of any value. Wildcards are special symbols to represent values or ranges of values. Wildcards are used instead of symbols within instance specifications. Three wildcards exist: a wildcard for any value, a wildcard for any value or no value at all (i.e. an omitted value), and a wildcard for an omitted value. See description of «LiteralAny» and «LiteralAnyOrNull» Update Text Change first bullet point of first paragraph of section 6.2 (notice that section 6.2 has been merged with section overview by resolution of issue 15772 and numbering was removed by resolution of issue 15770) from Test architecture defining concepts related to test structure and test configuration. To Test architecture defining concepts related to structural aspects of test specifications and test configuration. Actions taken: October 22, 2010: received issue October 21, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 22 Oct 2010 03:46:02 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Marc-Florian Wendland Employer: Fraunhofer Institut FOKUS mailFrom: marc-florian.wendland@fokus.fraunhofer.de Terms_Agreement: Specification: UML Testing Profile Section: 4, 6 FormalNumber: formal/05-07-07 Version: 1.0 Doc_Year: 2005 Doc_Month: July Doc_Day: 07 Page: 2-6, 9-79 Title: Contents and location of chapter 4 must be clarified Nature: Revision Severity: Minor CODE: 3TMw8 B1: Report Issue Description: Description ########################################### Chapter 4 .Terms and Definitions. copes with defining a common terminology for the further specification. Its subsections reflects the logical packages of the UTP, hence it should be rather a subsection of chapter 6. Chapter 6 .The UML Testing Profile. deals with the profiles and its elements exclusively, so adding a subsection for defining a common terminology and providing an overall overview of the subsequently discussed profile and MOF-based metamodel (which are structured by the same logical packages) fits into the intention of chapter 6. It also concentrates the domain-specific knowledge of the profile.s concepts in the core chapter, what may help reader to find and retrieve information on a particular element. Additionally, chapter 4 must be thoroughly revised regarding its content. Currently, there is no agreement of what is included in the sections. For example, section 4.1 .Test Architecture. contains all profile element.s (and additional, logical concepts being no part of the profile) whereas subsection 4.4 .Timer Concepts. just discuss a subset of the profile element.s.