Issue 15913: Test management should be supported (uml-testing-profile-rtf) Source: sepp.med (Dr. Armin Metzger, armin.metzger(at)seppmed.de) Nature: Enhancement Severity: Significant Summary: There is missing support of test management issues within the current version of UTP in contradiction to the fact, that test frameworks usually are supported by a tool based or manual test management process. One of the major tasks of test management is to decide, which test cases must be executed. In safety-critical environments, good rationale shall be given if test cases are ommited. To establish corresponding process interfaces from model based test design to test management, the test models have to be enriched with test management features. Currently, UTP test cases are supposed to be independent of the specific configuration of the SUT. If product variants are tested, specific test cases may be required that only apply to one or several variants (but not all). This is very important to fulfill basic regulatory affairs, e.g. IEEE 826 defining the content of test plan and test design. Example 1: A test case attribute "priority" in the model can be used, to include the design of prioritized test sets within the model used for stakeholder review and later for test suite management in the test management tool used. Example 2: Explicite tags for requirements as model attributes to test cases enable a traceable and efficient requirements based test design with UTP models and can be used as a basis for tool interfaces / synchronization tools between requirements engineering and test design. Resolution: Test management aspects become more and more important. UTP should target those aspects as well. Since test management is not in scope of the initial RFP of the UTP, the RTF decided to define a basic set of test management attributes in an additional non-normative annex. The RTF defined a common set of important attributes which are reusable for a lot of test management aspects (like version, description…). Those information are grouped in a newly created stereotype called ManagedElement. As part of the resolution, an issue will be submitted to the UML, since most of those information are general purpose information and should be included in UML as well. Additionally, some more test-specific attributes are added directly into already existing concepts to enable them for test management purposes. Revised Text: Add new Annex Add a new non-normative Annex to the end of the UML Testing Profile with content Annex F - Test Management Concepts (non-normative) F.1 General This annex provides optional extensions to the UML Testing Profile to cope with test management requirements. The extensions for the stereotypes of the normative profile are optional. Only the concepts additional to the already defined concepts (in section 7) are listed. F.2 Abstract Syntax Figure F.1 – Additional test management attributes F.3 Stereotype descriptions F.3.1 ManagedElement Description A managed element provides additional project-, process- or any other meta-information to the element it is applied to. Extensions • Element (from UML::Kernel) Generalizations None. Attributes • Owner : String [0..1] Identifies the owner which is responsible for this managed element. • description : String [0..1] Provides the capability to describe the managed element in a greater detail. • version : String [0..1] Information on the version of a managed element. • criticality : String [0..1] Information of the criticality of a managed element. Semantics Managed elements are often used in combination with other stereotypes, especially of the UML Testing Profile, to indicate the version or the owner of a particular test context, for example. Constraints None. Notation No additional notation for «ManagedElement» defined. Examples None. F.3.2 TestComponent Additional Attributes • compatibeSUTVersion : String [0..*] Information on which SUT versions the test component applies to / is compatible with. • compatibeSUTVariant : String [0..*] Information on which SUT variants the test component applies to / is compatible with. Used for test management regarding product variants. F.3.3TestContext Additional Attributes • testLevel : String [0..1] Information on what part of a system a test context is aiming at. • compatibeSUTVersion : String [0..*] Information on which SUT versions the test context applies to / is compatible with. • compatibeSUTVariant : String [0..*] Information on which SUT variants the test context applies to / is compatible with. Used for test management regarding product variants. F.3.4 TestCase Additional Attributes • priority : String [0..1] Comparable value, prioritizing the test case within the model used for test management regarding review, test design and test execution. • compatibeSUTVersion : String [0..*] Information on which SUT versions the test case applies to / is compatible with. • compatibeSUTVariant : String [0..*] Information on which SUT variants the test case applies to / is compatible with. Used for test management regarding product variants. F.3.5 TestLog Additional Attributes • tester : String [0..*] Identifies which persons have been involved in producing the test log • executedAt : String [0..1] Provides information when the execution of the test case that produced this test log took place • duration : String [0..1] Provides information how long the execution of the test case that produced this test log took place • verdict : Verdict [1] The verdict created by the arbiter for the execution of a test cases that produced this test log • verdictReason : String [0..1] The reason why a particular verdict was produced. • sutVersion : String [0..1] Information against what version of the SUT the test case that produced this test log was executed at. F.3.6 TestObjective Additional Attributes • priority : String [0..1] Comparable value, prioritizing the test objective within the model used for test management regarding review, test design and test execution. Actions taken: January 5, 2011: received issue October 21, 2011: closed issue Discussion: see figure on page 105 of ptc/2011-07-18 End of Annotations:===== m: webmaster@omg.org Date: 05 Jan 2011 10:36:23 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Mr. Armin Metzger Employer: sepp.med gmbh mailFrom: armin.metzger@seppmed.de Terms_Agreement: I agree Specification: UML Testing Profile Section: all FormalNumber: formal/2005-07-07 Version: 1.0 Doc_Year: 2005 Doc_Month: July Doc_Day: 07 Page: 112 Title: Test management should be supported Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Description: There is missing support of test management issues within the current version of UTP in contradiction to the fact, that test frameworks usually are supported by a tool based or manual test management process. One of the major tasks of test management is to decide, which test cases must be executed. In safety-critical environments, good rationale shall be given if test cases are ommited. To establish corresponding process interfaces from model based test design to test management, the test models have to be enriched with test management features. Currently, UTP test cases are supposed to be independent of the specific configuration of the SUT. If product variants are tested, specific test cases may be required that only apply to one or several variants (but not all). This is very important to fulfill basic regulatory affairs, e.g. IEEE 826 defining the content of test plan and test design. Example 1: A test case attribute "priority" in the model can be used, to include the design of prioritized test sets within the model used for stakeholder review and later for test suite management in the test management tool used. Subject: AW: UTP RTF - Call for Remarks on possible resolution 15913 Date: Mon, 4 Apr 2011 05:41:06 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: UTP RTF - Call for Remarks on possible resolution 15913 Thread-Index: AcvwuFSFMsJaXmIFQ4y49ZMZRJYOnABuSPQw From: "Wendland, Marc-Florian" To: "Metzger Armin" , Hi Armin, I.ve several comments on the possible solution for test management: 1. The name of the stereotype <> is misleading from my point of view. Test management describes the overall controlling process of a test process. Actually, the test management stereotypes just bundles a set of test management relevant information, so why shouldn.t we use the stereotype <>? 2. There is no stereotype <> in the current UTP. 3. What is the semantics of a StructuredClassifier, stereotyped as <>? 4. Aggregation in metamodeling is senseless. Either use composition or association, but for stereotypes, composition is not feasible. 5. I.d prefer a solution, where <> is an abstract stereotype without an extension to an existing metaclass. Instead of, SUT, TestComponent, TestCase and TestContext should specialize <>. Since each tagged value is optional, one could make use of them if necessary. If not, all the properties can be left empty. Please find my idea attached. 6. The semantics description of <> is not sufficient, I.d say. 7. The tagged value .applicability. should be renamed. I.d prefer something that is self-explaining. Applicability is too generic for my liking. Most of them are technical issues, however, the descriptions of the tagged values do not correspond to the abstract syntax. Please double-check. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ Von: Metzger Armin [mailto:Armin.Metzger@seppmed.de] Gesendet: Samstag, 2. April 2011 00:01 An: uml-testing-profile-rtf@omg.org Betreff: UTP RTF - Call for Remarks on possible resolution 15913 Dear collegues, Please check: http://www.omgwiki.org/uml-testing-profile-rtf/doku.php?id=issue_15913 It has to be seen in connection with the solution proposed in 15914 by Florian and is intended to be a first step of introducing explicite handling of test management aspects. Any comments / findings / suggestions / ... are welcome. Have a nice weekend! Regards, Armin Geschäsfü Dipl. Inf. Florian Prester Dipl. Kffr. Maria Prester Dipl. Betriebsw. (FH) Barbara Bilen HR Fü131 Ust.IdNr. DE 179 168 106 Besuchen Sie uns auf folgenden Veranstaltungen: - MedConf in Luzern, 05.-07.04.2011 - 2. ASQF Testing und Safety Day in Franken in Nüg, 19.04.2011 - MBTConf in Mü, 27.-29.06.2011 - MedConf in Mü, 04.-06.10.2011 Wir freuen uns auf ein persöches Gesprä mit Ihnen. testmanagement_concepts.jpg Date: Tue, 5 Apr 2011 23:23:07 +0200 (CEST) From: Metzger Armin To: "Wendland, Marc-Florian" , uml-testing-profile-rtf@omg.org Subject: Re: AW: UTP RTF - Call for Remarks on possible resolution 15913 X-Mailer: Open-Xchange Mailer v6.14.0-Rev6 X-Virus-Scanned: amavisd-new at seppmed.de X-Copyrighted-Material: Please visit http://www.seppmed.de/ .Hi All, For the details, please refer to the comments below. @Florian: please take into special consideration section 6. below. I have modified the specification mainly due to Florians comments (thanks for that). You will find the revised description on http://www.omgwiki.org/uml-testing-profile-rtf/doku.php?id=issue_15913 For those of you, who already checked this issue, you find the tagged changes in the Word document attached to this mail. Thanks for further comments. Regards, Armin "Wendland, Marc-Florian" hat am 4. April 2011 um 05:41 geschrieben: > Hi Armin, > > > > I.ve several comments on the possible solution for test management: > > > > 1. The name of the stereotype <> is misleading from my point of view. Test management describes the overall controlling process of a test process. Actually, the test management stereotypes just bundles a set of test management relevant information, so why shouldn.t we use the stereotype <>? > AM: OK, I've been torn between the smart but not exact expression and the bulky word-giant. OK, agree, I've changed to the exact expression. > 2. There is no stereotype <> in the current UTP. AM: OK, I've been starting from the proposual V1.1 with Deployment already integrated. If this stereotype will be established in the release, we will have to consolidate, meaning, then we should assign TestManagementInformation to deployment. > > 3. What is the semantics of a StructuredClassifier, stereotyped as <>? AM: @Florian: coresponds to your remark #6?? > > 4. Aggregation in metamodeling is senseless. Either use composition or association, but for stereotypes, composition is not feasible. AM: OK. @Florian: Thanks for your suggestions. > > 5. I.d prefer a solution, where <> is an abstract stereotype without an extension to an existing metaclass. Instead of, SUT, TestComponent, TestCase and TestContext should specialize <>. Since each tagged value is optional, one could make use of them if necessary. If not, all the properties can be left empty. Please find my idea attached. > AM: OK. > 6. The semantics description of <> is not sufficient, I.d say. AM: OK, but with the more abstract description, the semantics are more compact and mostly refer to the tagged values. Hope it fits now (?) including the major "tbd" we both have to fix as the interfacing section between TestManagementInformation and TestSuite. > > 7. The tagged value .applicability. should be renamed. I.d prefer something that is self-explaining. Applicability is too generic for my liking. > > AM: OK, changed to "testScope". > > Most of them are technical issues, however, the descriptions of the tagged values do not correspond to the abstract syntax. Please double-check. AM: @Florian: Are there still remaining inconsistancies with the tagged values now??? Did I overlook something??? > > > > Marc-Florian > > > > ################################################ > > Marc-Florian Wendland > > Master of Science (M.Sc.) > > ------------------------------------------------ > > Fraunhofer Institut FOKUS > > Modeling und Testing Department > > Kaiserin-Augusta-Alle 31 > > D-10589 Berlin > > ------------------------------------------------ > > Tel: +49 (30) - 3463 7395 > > Email: marc-florian.wendland@fokus.fraunhofer.de > > ################################################ > > > > Von: Metzger Armin [mailto:Armin.Metzger@seppmed.de] > Gesendet: Samstag, 2. April 2011 00:01 > An: uml-testing-profile-rtf@omg.org > Betreff: UTP RTF - Call for Remarks on possible resolution 15913 > > > > Dear collegues, > > > > Please check: > > http://www.omgwiki.org/uml-testing-profile-rtf/doku.php?id=issue_15913 > > > > It has to be seen in connection with the solution proposed in 15914 by Florian and is intended to be a first step of introducing explicite handling of test management aspects. > > > > Any comments / findings / suggestions / ... are welcome. > > > > Have a nice weekend! > > > > Regards, > > Armin > > > > Geschäsfü > Dipl. Inf. Florian Prester > Dipl. Kffr. Maria Prester > Dipl. Betriebsw. (FH) Barbara Bilen > > HR Fü131 > Ust.IdNr. DE 179 168 106 > > Besuchen Sie uns auf folgenden Veranstaltungen: > > - MedConf in Luzern, 05.-07.04.2011 > - 2. ASQF Testing und Safety Day in Franken in Nüg, 19.04.2011 > - MBTConf in Mü, 27.-29.06.2011 > - MedConf in Mü, 04.-06.10.2011 > > Wir freuen uns auf ein persöches Gesprä mit Ihnen. > > > Examplchäsfü Dipl. Inf. Florian Prester Dipl. Kffr. Maria Prester Dipl. Betriebsw. (FH) Barbara Bilen HR Fü131 Ust.IdNr. DE 179 168 106 Besuchen Sie uns auf folgenden Veranstaltungen: - MedConf in Luzern, 05.-07.04.2011 - 2. ASQF Testing und Safety Day in Franken in Nüg, 19.04.2011 - MBTConf in Mü, 27.-29.06.2011 - MedConf in Mü, 04.-06.10.2011 Wir freuen uns auf ein persöches Gesprä mit Ihnen. MetzgerArmin1.vcf Subject: [issue 15913/15915] tag values Date: Wed, 20 Apr 2011 10:50:26 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 15913/15915] tag values Thread-Index: Acv/N+mwUtwVVlmmRbyJxcRo1F1WlA== From: "Wendland, Marc-Florian" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p3K8jm4T012591 Dear members, In addition to the already proposed tag values by Armin (see issue 15913 in the wiki), Armin and I suggest we should also consider the following values. See it as a starting point towards TestManagement in UTP. It is far from being complete, but a starting point: TestManagementInformation: (in addition to Armin's tags, incorporating Markus' tags) - method : String [0..1] - resources : String [0..*] - responsibility : String [0..*] - status:String [0..1] TestLog: (Armin, what exactly is the difference between time and date in your proposal? Here are my suggestions for the TestLog) - tester : String [0..*] - executionDate : String [0..1] - duration : String [0..1] - verdict : Verdict - verdictReason:String[0..1] Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ Date: Wed, 20 Apr 2011 08:27:50 -0400 From: "Hagar, Jon D" Subject: RE: [issue 15913/15915] tag values To: "uml-testing-profile-rtf@omg.org" Thread-Topic: [issue 15913/15915] tag values Thread-Index: Acv/N+mwUtwVVlmmRbyJxcRo1F1WlAAHK/zA Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-20_04:2011-04-20,2011-04-20,1970-01-01 signatures=0 All, I have been struggling a little with the idea of putting structures in for test planning. Specifically is planning within the scope of UTP, just as is project planning within scope of UML and SysML. The arguments I can see for: 1. Business process modeling are within scope and seen in tooling. BPM could be used in planning 2. The people doing software, system and test design must factor in and consider the test plan. 3. This offers an integrated solution space Things I see "against" 1. I see management activities separate from engineering (test design). They are related by separate. 2. More structures and tags complicate what one must understand, making things harder to learn. 3. If I model plans/management what is the advantage to users and customers, and is optional? Is there general direction from the OMG and agreement including these structures into standards? I think we need general direction and agreement this is within scope. Jon D. Hagar Cell - 303-903-5536 Lockheed Martin -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Wednesday, April 20, 2011 4:50 AM To: uml-testing-profile-rtf@omg.org Subject: EXTERNAL: [issue 15913/15915] tag values Dear members, In addition to the already proposed tag values by Armin (see issue 15913 in the wiki), Armin and I suggest we should also consider the following values. See it as a starting point towards TestManagement in UTP. It is far from being complete, but a starting point: TestManagementInformation: (in addition to Armin's tags, incorporating Markus' tags) - method : String [0..1] - resources : String [0..*] - responsibility : String [0..*] - status:String [0..1] TestLog: (Armin, what exactly is the difference between time and date in your proposal? Here are my suggestions for the TestLog) - tester : String [0..*] - executionDate : String [0..1] - duration : String [0..1] - verdict : Verdict - verdictReason:String[0..1] Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ Subject: AW: [issue 15913/15915] tag values Date: Thu, 21 Apr 2011 07:37:06 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 15913/15915] tag values Thread-Index: Acv/N+mwUtwVVlmmRbyJxcRo1F1WlAAHK/zAACQlkTA= From: "Wendland, Marc-Florian" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p3L5WGw7012508 Hi Jon, I don't think that those aspects are problematic or against the direction of OMG. Think about the SPEM (Software Process Engineering Metamodel - I'm not sure whether this is the correct name) what describes software development processes and the management of software development processes, or BPML for the management of business processes. The C4I subgroup at OMG is planning a dedicated metamodel for test exchange and they address management, defect tracking, change management (and a lot more) too. UTP or UML models are not restricted to represent design models. Of course, their primer intent is the design of (test) systems. Actually, consider models as defined exchange data models for tools. I think there is nothing wrong with the fact that test management tools may use UTP for exchange. From my viewpoint, those test management aspects should be even more emphasized in further minor or major revisions. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ > -----Ursprühe Nachricht----- > Von: Hagar, Jon D [mailto:jon.d.hagar@lmco.com] > Gesendet: Mittwoch, 20. April 2011 14:28 > An: uml-testing-profile-rtf@omg.org > Betreff: RE: [issue 15913/15915] tag values > > All, > > I have been struggling a little with the idea of putting structures in for test > planning. Specifically is planning within the scope of UTP, just as is project > planning within scope of UML and SysML. > > The arguments I can see for: > 1. Business process modeling are within scope and seen in tooling. BPM > could be used in planning > 2. The people doing software, system and test design must factor in and > consider the test plan. > 3. This offers an integrated solution space > > > Things I see "against" > 1. I see management activities separate from engineering (test design). > They are related by separate. > 2. More structures and tags complicate what one must understand, > making things harder to learn. > 3. If I model plans/management what is the advantage to users and > customers, and is optional? > > Is there general direction from the OMG and agreement including these > structures into standards? I think we need general direction and agreement > this is within scope. > > Jon D. Hagar > Cell - 303-903-5536 > Lockheed Martin > > -----Original Message----- > From: Wendland, Marc-Florian [mailto:marc- > florian.wendland@fokus.fraunhofer.de] > Sent: Wednesday, April 20, 2011 4:50 AM > To: uml-testing-profile-rtf@omg.org > Subject: EXTERNAL: [issue 15913/15915] tag values > > Dear members, > > In addition to the already proposed tag values by Armin (see issue 15913 in > the wiki), Armin and I suggest we should also consider the following values. > See it as a starting point towards TestManagement in UTP. It is far from being > complete, but a starting point: > > TestManagementInformation: (in addition to Armin's tags, incorporating > Markus' tags) > - method : String [0..1] > - resources : String [0..*] > - responsibility : String [0..*] > - status:String [0..1] > > TestLog: (Armin, what exactly is the difference between time and date in > your proposal? Here are my suggestions for the TestLog) > - tester : String [0..*] > - executionDate : String [0..1] > - duration : String [0..1] > - verdict : Verdict > - verdictReason:String[0..1] > > Marc-Florian > ################################################ > Marc-Florian Wendland > Master of Science (M.Sc.) > ------------------------------------------------ > Fraunhofer Institut FOKUS > Modeling und Testing Department > Kaiserin-Augusta-Alle 31 > D-10589 Berlin > ------------------------------------------------ > Tel: +49 (30) - 3463 7395 > Email: marc-florian.wendland@fokus.fraunhofer.de > ################################################ > Date: Thu, 21 Apr 2011 08:29:23 -0400 From: "Hagar, Jon D" Subject: RE: [issue 15913/15915] tag values To: "uml-testing-profile-rtf@omg.org" Thread-Topic: [issue 15913/15915] tag values Thread-Index: Acv/N+mwUtwVVlmmRbyJxcRo1F1WlAAHK/zAACQlkTAADoGC8A== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-21_02:2011-04-21,2011-04-21,1970-01-01 signatures=0 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p3LCOwtL005978 I am okay with this as long as we all agree this is the direction. When will the test planning features be fully considered, integrated and analyzed? Are we trying for this rev or will there be some focused work on this during the next rev? Also, if the test management tools may use this, it seems like we need somebody representing those kinds of tools and interfaces. Jon D. Hagar Cell - 303-903-5536 Lockheed Martin -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Thursday, April 21, 2011 1:37 AM To: uml-testing-profile-rtf@omg.org Subject: EXTERNAL: AW: [issue 15913/15915] tag values Hi Jon, I don't think that those aspects are problematic or against the direction of OMG. Think about the SPEM (Software Process Engineering Metamodel - I'm not sure whether this is the correct name) what describes software development processes and the management of software development processes, or BPML for the management of business processes. The C4I subgroup at OMG is planning a dedicated metamodel for test exchange and they address management, defect tracking, change management (and a lot more) too. UTP or UML models are not restricted to represent design models. Of course, their primer intent is the design of (test) systems. Actually, consider models as defined exchange data models for tools. I think there is nothing wrong with the fact that test management tools may use UTP for exchange. From my viewpoint, those test management aspects should be even more emphasized in further minor or major revisions. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ > -----Ursprühe Nachricht----- > Von: Hagar, Jon D [mailto:jon.d.hagar@lmco.com] > Gesendet: Mittwoch, 20. April 2011 14:28 > An: uml-testing-profile-rtf@omg.org > Betreff: RE: [issue 15913/15915] tag values > > All, > > I have been struggling a little with the idea of putting structures in for test > planning. Specifically is planning within the scope of UTP, just as is project > planning within scope of UML and SysML. > > The arguments I can see for: > 1. Business process modeling are within scope and seen in tooling. BPM > could be used in planning > 2. The people doing software, system and test design must factor in and > consider the test plan. > 3. This offers an integrated solution space > > > Things I see "against" > 1. I see management activities separate from engineering (test design). > They are related by separate. > 2. More structures and tags complicate what one must understand, > making things harder to learn. > 3. If I model plans/management what is the advantage to users and > customers, and is optional? > > Is there general direction from the OMG and agreement including these > structures into standards? I think we need general direction and agreement > this is within scope. > > Jon D. Hagar > Cell - 303-903-5536 > Lockheed Martin > > -----Original Message----- > From: Wendland, Marc-Florian [mailto:marc- > florian.wendland@fokus.fraunhofer.de] > Sent: Wednesday, April 20, 2011 4:50 AM > To: uml-testing-profile-rtf@omg.org > Subject: EXTERNAL: [issue 15913/15915] tag values > > Dear members, > > In addition to the already proposed tag values by Armin (see issue 15913 in > the wiki), Armin and I suggest we should also consider the following values. > See it as a starting point towards TestManagement in UTP. It is far from being > complete, but a starting point: > > TestManagementInformation: (in addition to Armin's tags, incorporating > Markus' tags) > - method : String [0..1] > - resources : String [0..*] > - responsibility : String [0..*] > - status:String [0..1] > > TestLog: (Armin, what exactly is the difference between time and date in > your proposal? Here are my suggestions for the TestLog) > - tester : String [0..*] > - executionDate : String [0..1] > - duration : String [0..1] > - verdict : Verdict > - verdictReason:String[0..1] > > Marc-Florian > ################################################ > Marc-Florian Wendland > Master of Science (M.Sc.) > ------------------------------------------------ > Fraunhofer Institut FOKUS > Modeling und Testing Department > Kaiserin-Augusta-Alle 31 > D-10589 Berlin > ------------------------------------------------ > Tel: +49 (30) - 3463 7395 > Email: marc-florian.wendland@fokus.fraunhofer.de > ################################################ > Date: Thu, 21 Apr 2011 16:39:56 +0200 From: Armin Metzger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 To: "Wendland, Marc-Florian" CC: uml-testing-profile-rtf@omg.org Subject: Re: [issue 15913/15915] tag values X-Virus-Scanned: amavisd-new at seppmed.de X-Copyrighted-Material: Please visit http://www.seppmed.de/ Hi All, For an answer to Florians question, please see below. Regards and happy Easter to all of you, Armin Am 20.04.2011 10:50, schrieb Wendland, Marc-Florian: Dear members, In addition to the already proposed tag values by Armin (see issue 15913 in the wiki), Armin and I suggest we should also consider the following values. See it as a starting point towards TestManagement in UTP. It is far from being complete, but a starting point: TestManagementInformation: (in addition to Armin's tags, incorporating Markus' tags) - method : String [0..1] - resources : String [0..*] - responsibility : String [0..*] - status:String [0..1] TestLog: (Armin, what exactly is the difference between time and date in your proposal? Here are my suggestions for the TestLog) Armin: date is date and time should better be named "duration" (like proposed by Markus and as listed below). - tester : String [0..*] - executionDate : String [0..1] - duration : String [0..1] - verdict : Verdict - verdictReason:String[0..1] Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ -- Mit freundlichen Grü kind regards Dr. Armin Metzger Projektmanagement sepp.med gmbh Gewerbering 9 D-91341 Rönbach Fon: +49 (0) 9195 - 931 - 204 Fax: +49 (0) 9195 - 931 - 300 EMail: armin.metzger@seppmed.de Internet: www.seppmed.de Geschäsfü Dipl. Inf. Florian Prester Dipl. Kffr. Maria Prester Dipl. Betriebsw. (FH) Barbara Bilen HR Fü131 Ust.IdNr. DE 179 168 106 Besuchen Sie uns auf folgenden Veranstaltungen: - 2. ASQF Testing und Safety Day in Franken in Nüg, 19.04.2011 - MBTConf in Mü, 27.-29.06.2011 - MedConf in Mü, 04.-06.10.2011 Wir freuen uns auf ein persöches Gesprä mit Ihnen. Date: Thu, 5 May 2011 00:33:25 +0200 (CEST) From: Metzger Armin To: Markus Schacher , uml-testing-profile-rtf@omg.org Subject: Re: Tag Values for UTP Objects X-Mailer: Open-Xchange Mailer v6.14.0-Rev6 X-Virus-Scanned: amavisd-new at seppmed.de X-Copyrighted-Material: Please visit http://www.seppmed.de/ .Hi all, as a next step of the 15913 proposual ("TestManagementInformation") I made it "slim" (based on Florian's comments) and added a set of attributes from Markus' suggestions (rationales see below). I still left my proposual as an abstract class, not as attributes to the specific objects. Please discuss this in Paris, I would strongly prefer the abstract class solution to avoid redundancies (and make the whole thing maintainable!). I added a Word document with change bars for those of you who followed the discussions and the details to get an easy overview regarding the latest changes. Have fun and fruitful discussions in Paris. Regards Armin Markus Schacher hat am 12. April 2011 um 16:23 geschrieben: > Hi all, > > > > As discussed, here are a number of test-related properties (tag definitions) we are usually using, merged with the ones from Armin's issues: > > > > TestCase > > · Name: String (usually implicit) -> implicit, OK > > · Version: String or VersionType -> already 15913 OK > > · Objective (we have this as a dependency) -> already via UTP OK > > · Priority: String or Enum -> already 15913 OK > > · Criticality: String or Enum -> already 15913 OK > > · «verify» (reference to a SysML Requirement) -> added to 15913 as option > > · Method: Enum(black box, grey box, white box, ...) -> added to 15913 as more general "description" > > · Precondition: Expression -> I would prefer realization as specialized test case (that is manageble as test object then with all related advantages like reuse, maintainability, ...) > > · Postcondition: Expression -> I would prefer realization as specialized test case (that is manageble as test object then with all related advantages like reuse, maintainability, ...) > > · Arbiter (reference to ArbitrationSpec) -> already implicit via test context OK > > · Scheduer (reference to SchedulingSpec) -> already implicit via test context OK > > · Resources: String -> already implicit via test context OK > > · Description: String -> not considered applicable for TestManagementInformation > > · Notes: String -> already via UTP OK > > · Owner: String -> added to 15913 > > · Status: String of Enum (optionally controlled by a state machine) -> added to 15913 > > > > TestContext > > · Name: String (usually implicit) -> see above > > · Version: String or VersionType -> see above > > · DefaultArbiter (reference to ArbitrationSpec) > -> see above > · DefaultScheduer (reference to SchedulingSpec) -> see above > > · Resources: String -> see above > > · Description: String -> see above > > · Notes: String -> see above > > · Owner: String -> see above > > · Status: String of Enum (optionally controlled by a state machine) -> see above > > > > TestGroup/TestSuite > > · Name: String (usually implicit) -> see above > > · Version: String or VersionType -> see above > > · Objective (we have this as a dependency) -> see above > > · Priority: String or Enum -> see above > > · Criticality: String or Enum -> see above > > · Arbiter (reference to ArbitrationSpec) -> see above > > · Scheduer (reference to SchedulingSpec) -> see above > > · Resources: String -> see above > > · ScheduledDate: Date -> test execution only, not applicable for generalized abstract class > > · LastExecutionDate: Date -> test execution only, not applicable for generalized abstract class > > · Description: String -> see above > > · Notes: String -> see above > > · Owner: String -> see above > > · Status: String of Enum (optionally controlled by a state machine) -> see above > > > > TestComponent > > · Name: String (usually implicit) -> see above > > · Version: String or VersionType -> see above > > · CompatibleVersion: String or VersionType [0..*] -> already included in 19513 OK > > · Description: String -> see above > > · Notes: String -> see above > > · Owner: String -> see above > > · Status: String of Enum (optionally controlled by a state machine) -> see above > > > > TestLog > > · Tester: String -> considered applicable for test log only > > · ExecutionDate: Date -> considered applicable for test log only > > · Verdict: Enum(pass/fail) -> considered applicable for test log only > > · VerdictComponent: String -> considered applicable for test log only > > · Notes: String -> see above > > · Owner: String -> see above > > · Status: String of Enum (optionally controlled by a state machine) -> see above > > > > SUT (as a role of a thing, not the thing as such) > > · Priority: String or Enum -> see above > > · Criticality: String or Enum -> see above > > · Notes: String -> see above > > · Status: String of Enum (optionally controlled by a state machine) -> see above > > > > As you can see, some of these properties are shown on more than one class. As I mentioned in the meeting, this would be the base for me either to abstract them out into a common superclass or leave them where they are (i.e. in the most specific class). > > > > I do not understand the semantics of "CompatibleVariant": is this not an association to another instance of the same thing (instead of a simple string)? > > > > Best regards, > > Markus > > > > P.S.: > > Bridging the gap between Business and IT: > > - KnowEnterprise(R) is the world's first enterprise repository that integrates OMGs business and IT standards! > > - Find-out more at http://www.knowgravity.com/eng/value/knowEnterprise.htm (in English) > > - or at http://www.knowgravity.com/ger/value/knowEnterprise.htm (in German) > > > > -------------------------------- > > KnowGravity Inc. > > Hohlstrasse 534 > > CH-8048 Zü> > Switzerland > > Tel +41 (0)44 43 42 000 > > Dir +41 (0)44 43 42 001 > > Fax +41 (0)44 43 42 009 > > http://www.knowgravity.com > > > UMchäsfü Dipl. Inf. Florian Prester Dipl. Kffr. Maria Prester Dipl. Betriebsw. (FH) Barbara Bilen HR Fü131 Ust.IdNr. DE 179 168 106 Besuchen Sie uns auf folgenden Veranstaltungen: - MBTConf in Mü, 27.-29.06.2011 - MedConf in Mü, 04.-06.10.2011 Wir freuen uns auf ein persöches Gesprä mit Ihnen. MetzgerArmin1.vcf 2011-05-04_UML-Testing-Profile-RTF_issue_15913.DOCX -Testing-Profile-RTF_issue_15913.DOCX 2: Explicite tags for requirements as model attributes to test cases enable a traceable and efficient requirements based test design with UTP models and can be used as a basis for tool interfaces / synchronization tools between requirements engineering and test design. UML Testing Profile RTF issue_15913 Trace: » issue_15649 » issue_15913 Table of Contents . Test management should be supported o Rational o Description . Possible Solution Test management should be supported Submitted by: Armin Metzger Status: open Done by: Armin Metzger Rational There is missing support of test management issues within the current version of UTP in contradiction to the fact, that test frameworks usually are supported by a tool based or manual test management process. Description One of the major tasks of test management is to decide, which test cases must be executed. The scope of a test phase usally does not comprise every test case that is implemented, but just a subset of all implemented test cases selected with (test phase specific) selection criteria. In safety-critical environments, good rationale shall be given if test cases are ommited. To establish corresponding process interfaces from model based test design to test management, the test models have to be enriched with test management features. Currently, UTP test cases are supposed to be independent of the specific configuration of the SUT. If product variants are tested, specific test cases may be required that only apply to one or several variants (but not all). This is very important to fulfill basic regulatory affairs, e.g. IEEE 826 defining the content of test plan and test design. Example 1: A test case attribute .priority. in the model can be used, to include the design of prioritized test sets within the model used for stakeholder review and later for test suite management in the test management tool used. Example 2: Explicite tags for requirements as model attributes to test cases enable a traceable and efficient requirements based test design with UTP models and can be used as a basis for tool interfaces / synchronization tools between requirements engineering and test design. Furthermore, the architecture of objects embedding test cases do not cover all functional parts neccessary to perform test mgmt issues. The test context rather reflects a container for test cases with fixed test case behaviour. Usually, in the test process (mainly in test execution phase) there is volatility in the context, a test case has to be performed regarding (SUT-)variant specific attributes and in the clustering of test cases during different phases of the test (initial, regression, maintenance, etc.). In the test process, this is covered by test suites. In order to improve usability of test mgmt related objects, major conceptional objects (test suite, test management attributes) should be contained in separate objects. Possible Solution The proposed solution is split in two major functional clusters: 1. Test mgmt related attributes 2. Test mgmt related architecture 1. Test mgmt related attributes ............. UTP should support test management by providing the following test case attributes: - priority : String [0..1] Comparable value, prioritizing test cases within the model used for stakeholder review and later for test suite management in the test management tool used. Required for TestContext, TestCase - criticality : String [0..1] Gives information on the criticality of the feature to be tested (which might e.g. be safety-relevant). It is closely related to the risk analysis. - testScope : String [0..*] Required for TestContext, TestCase Mark Test Cases e.g. as regression tests or as system tests. Thus, it gives information to the test manager, whether and when the test case shall be planned in a specific test context. - version : String [0..1] Especially required for TestCase, Behavior, SUT, TestComponent Information on the version of a test artefact. - compatibleVersion : String [0..*] Especially required for TestCase, Behavior, SUT, TestComponent Information on which SUT versions a test artefact applies to / is compatible with. E.g. allows the selection of test cases specifically relevant for a SUT version. The compatible version can be a combination of diferent subsystems, each with independent versions or id tags. This is comparable tot he labelling mechanism as known in configuration management, with labels comprising a set of labels defining the configuration of a system by the configuration of the components it consists of. E.g. consider system A built of Subsystem B, C and D. In this example, up to three labels are needed for unique identification, e.g. A-V1.3, B-V1.2, C-V2.12. Traceability especially required for TestCase (possibly Behavior, TestContext) is established by providing a link to e.g. requirements the test case is validating by .verifies. or .satisfies. relations. To support the test of product variants it should be possible to add the following information to a test case: - compatibleVariant : String [0..*] Especially required for TestCase, Behavior, SUT, TestComponent Information on which SUT variants a test artefact applies to / is compatible with. E.g. allows the selection of test cases specifically relevant for a SUT variant. The variant of a test case, test component, etc. uniquely corresponds to the variant oft he test object (SUT) it can be applied to. A test case might either apply to one specific configuration, to a set of several configurations or to all configurations. Furthermore, for test execution, it can be important to test all possible variants, a combination of variants or any variant out of a subset of variants as a representative. This can be implemented by proper labelling rules for the implementation of compatibleVariant, e.g. .variant1., .variant2., .variant1-or-variant2., .variant1-and-variant2.. If product variants are tested, the number of TestContext objects may become quite large. It should be possible to group several TestContexts and to obtain an overall verdict by the Arbiter for these groups, e.g. for all TestContext of a given product variant. The easiest solution would be to allow the TestContext to aggregate other TestContext, providing a manageable hierarchical structure. 1. Test mgmt related architecture ............. The TestContext is static and mainly covers test case clustering due to test objectives and test context in test design phase. Test objectives and clustering of test cases due to test context usually changes over different test phases (at least, the capability of the testbed to support flexibility to change test objectives and test context can be crucial for the usability of a test concept). Thus two additional major concepts should be introduced to UTP: TestSuite and TestManagementInformation as containers of relevant information. [1. TestSuite: Container for TestCases for specific test phase and test objective. E.g. - a test instance of a specific feature cluster of the SUT with a subset of SUT variants to be tested for a specific SUT release and - additional test instances for subsequent regression testing of incidents found and - an additional set of risk and / or priority dependent .standard. test cases in a full test and two following regression phases, each depending on the results of the previous test execution. In the model instance, 3 TestSuites have to be supplied: initial:TestSuite, regression1:TestSuite and regression2:TestSuite. Preferrably to be realized as specific implementation of a Behavior as described / to be described in 15914. Refer to the image below for architectural aspects / association within UTP.] 2. TestManagementInformation: covers all defined test mgmt relevant attributes as defined in section 1. 3. TestPlan as expansion of the TestContext concept by explicit predefined structure reflecting the top-down structure of the test plan as one of the major test relevant process assets (refer to section 1. of this issue): introduce a new behavioural element called .TestPlan. that is the aggregation of 0..* TestContext. Optional in a first step of test mgmt relevant adaptions. 1. TestSuite ====Stereotype Description==== ===Abstract Syntax=== TestManagementInformation as abstract class: covers test mgmt relevant attributes to be commonly usable for all related objects like test case, test suite, test context, etc. 1. TestManagementInformation ====Stereotype Description==== ===Abstract Syntax=== ===Semantics=== TestManagementInformation is an abstract class containing a basic [expandable!] set of attributes to be used for test managment topics. Related and defined UTP objects (TestCase, TestContext, SUT and TestComponent) can inherit these attributes if applicable in the context of profile implementation. TestManagementInformation implements a uniform attributing of test assets that have to be configurable on the basis of test management attributes and thus these attributes enable uniform treatment of all related objects regarding test management. The multiplicites of all tagged values start with zero allowing to apply them to the defined objects or not. The usage of test management attributes is optional and configurable regarding the applicable subset of attributes used. No actions / modification is applied to TestManagementInformation. TestManagementInformation attributes are used to define the content of TestSuite and TestContext. Mechanism: tbd. Traceability especially required for TestCase (possibly Behavior, TestContext) is established by providing a link to e.g. requirements the test case is validating by .verifies. or .satisfies. relations. TBD: If product variants are tested, the number of TestContext objects may become quite large. It should be possible to group several TestContexts and to obtain an overall verdict by the Arbiter for these groups, e.g. for all TestContext of a given product variant. ===Attributes=== - description : String [0..1] General specification regarding test management e.g. test method, test scope, . - owner : String [0..1] Unique owner of a test object like test case author etc. - status : String [0..1] Unique status of a test object in the context of it.s usage (test design status, test execution status, .. - priority : String [0..1] Comparable value, prioritizing test cases within the model used for for test management regarding review, test design and test executionstakeholder review and later for test suite management in the test management tool used. Required for TestContext, TestCase - criticality : String [0..1] Gives information on the criticality of the feature to be tested (which might e.g. be safety-relevant). It is closely related to the risk analysis. - testScope : String [0..*] Required for TestContext, TestCase Mark Test Cases e.g. as regression tests or as system tests. Thus, it gives information to the test manager, whether and when the test case shall be planned in a specific test context. Required for TestContext, TestCase - version : String [0..1] Information on the version of a test artefact. Especially required for TestCase, Behavior, SUT, TestComponent Information on the version of a test artefact. - compatibleVersion : String [0..*] Especially required for TestCase, Behavior, SUT, TestComponent Information on which SUT versions a test artefact applies to / is compatible with. Especially required for TestCase, Behavior, SUT, TestComponent [Annotation: E.g. allows the selection of test cases specifically relevant for a SUT version. The compatible version can be a combination of diferent subsystems, each with independent versions or id tags. This is comparable tot he labelling mechanism as known in configuration management, with labels comprising a set of labels defining the configuration of a system by the configuration of the components it consists of. E.g. consider system A built of Subsystem B, C and D. In this example, up to three labels are needed for unique identification, e.g. A-V1.3, B-V1.2, C-V2.12.] Traceability especially required for TestCase (possibly Behavior, TestContext) is established by providing a link to e.g. requirements the test case is validating by .verifies. or .satisfies. relations. To support the test of product variants it should be possible to add the following information to a test case: - compatibleVariant : String [0..*] Especially required for TestCase, Behavior, SUT, TestComponent Information on which SUT variants a test artefact applies to / is compatible with. Used for test management regarding product variants. Especially required for TestCase, Behavior, SUT, TestComponent [Annotation: E.g. allows the selection of test cases specifically relevant for a SUT variant. The variant of a test case, test component, etc. uniquely corresponds to the variant oft he test object (SUT) it can be applied to. A test case might either apply to one specific configuration, to a set of several configurations or to all configurations. Furthermore, for test execution, it can be important to test all possible variants, a combination of variants or any variant out of a subset of variants as a representative. This can be implemented by proper labelling rules for the implementation of compatibleVariant, e.g. .variant1., .variant2., .variant1-or-variant2., .variant1-and-variant2..] If product variants are tested, the number of TestContext objects may become quite large. It should be possible to group several TestContexts and to obtain an overall verdict by the Arbiter for these groups, e.g. for all TestContext of a given product variant. The easiest solution would be to allow the TestContext to aggregate other TestContext, providing a manageable hierarchical structure. see above Addiationally: «verify» (reference to a SysML Requirement) (AM: I would support that)\\ ===Associations=== see above ===Examples=== tbd in the final description Logged in as: Armin Metzger (arminmetzger) issue_15913.txt . Last modified: 2011/04/05 16:38 by arminmetzger DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7hzPZs9i1IQqPvqXbm910AtLwJgW/TKXKVRYNXvvkiI=; b=ue95cdTbWyJE5cPZODsdprSxM8iudwFAPR5iX2E5ykjnSlpbDDwFAZAu9+PYL44Oiu o6x5tANBBuQdYL2IRkjmksizqCaYp2tar1mv/MsaGinnIaIrLfmfQFvo+0S7kAF4ug2N kfeIf31dQsYiIhRbehhx7v03Cdogo79uWsKEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=GAwajfXwM7Kf+E5FM+XQgYAqJKnhcxwASNCfzPRNKZfTeCYXGvpNCwwPWPYW4/BVUF cOJ8xv7zFzcRTB67vDW/39Y0P9Gk3jjP4As+H/clJGQo/Lki87W1+2dj15Qzt6qtC5TZ TFXGqXga4cqqm3GOpI2nlbhZh+U6lp5hJpX9I= Date: Sun, 22 May 2011 12:02:22 +0200 From: Zhen Ru Dai Reply-To: ldai@gmx.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 To: "Wendland, Marc-Florian" , "uml-testing-profile-rtf@omg.org" Subject: Re: 15913/15914 Hi Florian et al, here my comments to the issues 15913 and 15914... issue 15914: I still do not see the benefit of test suite, since this is part of the test context. You may also define several test contexts in the model, when different sets of test cases are required or even if different test configurations are needed. Redundancy in the language definition only irritates the users. I think we should revise the definition of test context, instead of defining new concepts which cause redundancy. issue 15913: In this issue, the need of defining test management is argued with "The scope of a test phase usally does not comprise every test case that is implemented, but just a subset of all implemented test cases selected with (test phase specific) selection criteria." But this is exactly what a test context does: grouping test cases (e.g. for a specific test phase). The idea of defining test level is good, but since these terminologies are not uniquely understood by people, we should provide a definition of e.g. component, integration and system testing. Also terminology clashes like component testing, unit testing, module testing etc. must be clarified. Also, are we consider other test levels (integration test, acceptance test etc.) and test kinds? The attributes compatibleSUTVersion and compatibleSUTVariant are very fine-granular. Are those information really needed on the modelling level, already? If yes, can those be modelled in different test contexts? The attribute "tester" in TestLog where the name of the testing person is defined, is definitely not relevant in a model. Offen, the testing person changes. Models should be abstract, and this is too many constraints and too much information on the model level. All in all, I find the description of this issue very hard to read due to its complexity. There are definitely brilliant ideas described in the issue, but maybe we can break it down to sub-issues and decide about the sub-issues. So far my two cents! cheers Lulu Am 18.05.2011 15:46, schrieb Wendland, Marc-Florian: Lulu, Ich möe die Issues 15913 und 15914 gerne klän. Vermutlich werden sie verschoben. Kannst du bitte darlegen, warum du die Issues abgelehnt hast? Danke Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################