blob: ef267a4d75d23fe3c53341ce86d8acfd126e1052 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
epf:version="1.5.0" xmi:id="_NqYIdKeqEdmKDbQuyzCoqQ"
name="test_case,_0ZS-0MlgEdmt3adZL5Dmdw" guid="_NqYIdKeqEdmKDbQuyzCoqQ" changeDate="2008-08-14T12:46:38.070-0400"
version="7.2.0">
<mainDescription>&lt;p>&#xD;
A test case specifies the conditions which need to be validated to enable an assessment of some particular aspects of&#xD;
the system under test.&amp;nbsp; A test case is more formal than a test idea and usually takes the form of a&#xD;
specification.&amp;nbsp;In less formal environments, test cases can be created by identifying a unique ID, name, associated&#xD;
test data, and expected results.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
Test cases may be derived from&amp;nbsp;many&amp;nbsp;sources but will usually include a subset of both the requirements (such&#xD;
as use cases, performance characteristics, reliability concerns) and other types of quality attributes.&amp;nbsp; For more&#xD;
information on types of tests and their relationship to quality test attributes, see&amp;nbsp;&lt;a&#xD;
class=&quot;elementLinkWithType&quot; href=&quot;./../../core.tech.common.base/guidances/concepts/types_of_test_CAE80710.html&quot;&#xD;
guid=&quot;_0aJ6cMlgEdmt3adZL5Dmdw&quot;>Concept: Types of Test&lt;/a>.&#xD;
&lt;/p></mainDescription>
<purpose>&lt;p>&#xD;
The purpose of this artifact is to:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
&lt;li>&#xD;
provide a way to capture test inputs, conditions, and expected results for a system&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
systematically identify aspects of the software to test&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
specify whether an expected result has been reached based on verification of a system requirement, set of&#xD;
requirements, or scenario&#xD;
&lt;/li>&#xD;
&lt;/ul></purpose>
<impactOfNotHaving>&lt;p>&#xD;
&lt;font size=&quot;2&quot;>Without this artifact it is difficult adequately validate system functionality.&amp;nbsp;&amp;nbsp;Since this&#xD;
artifact is also often used&amp;nbsp;to specify the conditions of acceptance between the stakeholders and the developers,&#xD;
it is more difficult to establish exit criteria and to demonstrate that the exit criteria have been met without&#xD;
it.&amp;nbsp; It is also not possible to do regression testing if the original test cases have not been documented.&lt;/font>&#xD;
&lt;/p></impactOfNotHaving>
<reasonsForNotNeeding>&lt;p>&#xD;
&lt;font size=&quot;2&quot;>It may not be necessary to create this artifact for maintenance or small enhancements to existing&#xD;
systems which will likely have existing test assets that can be utilized.&amp;nbsp; Likewise package applications often&#xD;
come with their own set of test cases that would not require a separate instance of this artifact.&lt;/font>&#xD;
&lt;/p></reasonsForNotNeeding>
</org.eclipse.epf.uma:ArtifactDescription>