Issue 15914: Test scheduling should be supported explecitely (uml-testing-profile-rtf) Source: sepp.med (Dr. Armin Metzger, armin.metzger(at)seppmed.de) Nature: Enhancement Severity: Significant Summary: Some test cases might required additional hardware that is only available in specific timeframes. This means the test cases must be scheduled in detail and in certain sequences. Also, test cases may depend on each other. Corresponding model element assignments can be established in principle with the current UTP specification, but a corresponding rule-set or a basic standard is missing. Such kind of rule-set standard is necessary for potential tooling support of scheduling aspects coming out of an UTP test model. Resolution: Revised Text: Actions taken: January 5, 2011: received issue Discussion: Deferred due to time restrictions End of Annotations:===== m: webmaster@omg.org Date: 05 Jan 2011 10:46:27 -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 scheduling should be supported explecitely Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Some test cases might required additional hardware that is only available in specific timeframes. This means the test cases must be scheduled in detail and in certain sequences. Also, test cases may depend on each other. Corresponding model element assignments can be established in principle with the current UTP specification, but a corresponding rule-set or a basic standard is missing. 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 ################################################ Such kind of rule-set standard is necessary for potential tooling support of scheduling aspects coming out of an UTP test model.