blob: e6b28fec25aa0fd3e4389a0dc179c4014a0a8ebe [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-15T12:50:34.375-0700"
version="7.2.0">
<mainDescription>&lt;p>A&#xD;
test case specifies the conditions that must be validated to enable an assessment&#xD;
of aspects of the system under test. A test case is more formal than a test&#xD;
idea; typically, a test case takes the form of a specification. In less formal&#xD;
environments, you can create test cases by identifying a unique ID, name,&#xD;
associated test data, and expected results. &lt;/p> &lt;p> Test cases can be derived&#xD;
from many sources, and typically include a subset of the requirements (such&#xD;
as use cases, performance characteristics, and reliability concerns) and other&#xD;
types of quality attributes. For more information on types of tests and their&#xD;
relationships to quality test attributes, see &lt;a class=&quot;elementLinkWithType&quot;&#xD;
href=&quot;./../../core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts_CAE80710.html&quot;&#xD;
guid=&quot;_0aJ6cMlgEdmt3adZL5Dmdw&quot;>Concept: Testing Qualitative Requirements&lt;/a>. &lt;/p></mainDescription>
<purpose>&lt;p&#xD;
> Use this artifact for the following purposes: &lt;/p> &lt;ul>&#xD;
&lt;li> To provide a way to capture test inputs, conditions, and expected&#xD;
results for a system &lt;/li>&#xD;
&lt;li> To systematically identify aspects of the software to test &#xD;
&lt;/li>&#xD;
&lt;li> To specify whether an expected result has been reached, based&#xD;
on the verification of a system requirement, set of requirements,&#xD;
or scenario &lt;/li>&#xD;
&lt;/ul></purpose>
<impactOfNotHaving>&lt;p> &#xD;
Without this artifact, it is difficult to validate system functionality.&#xD;
Because this artifact specifies the conditions of acceptance between the stakeholders&#xD;
and the developers, without the artifact, it is difficult to establish exit&#xD;
criteria and to demonstrate that the exit criteria have been met. If the original&#xD;
test cases have not been documented, it is impossible to do regression testing. &lt;/p></impactOfNotHaving>
<reasonsForNotNeeding>&lt;p&#xD;
> It might not be necessary to create this artifact to maintain or make small&#xD;
enhancements to existing systems, which likely have existing test assets that&#xD;
you can use. You also might not need this artifact if you use a package application&#xD;
that has its own set of test cases. &lt;/p></reasonsForNotNeeding>
</org.eclipse.epf.uma:ArtifactDescription>