blob: 7d0c1663323eb805423de76e95811791d155799c [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<!-- VERSION rmc:7.1.0 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<!-- START NON-TRANSLATABLE -->
<title>\openup_basic\workproducts\developer_test.xmi</title>
</head>
<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
<body>
Element Name: developer_test.xmi<br/><br/>
<!-- END NON-TRANSLATABLE -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: presentationName<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:presentationName,_0YuXEclgEdmt3adZL5Dmdw CRC: 2474353591 -->Developer Test<!-- END:presentationName,_0YuXEclgEdmt3adZL5Dmdw -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: briefDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:briefDescription,_0YuXEclgEdmt3adZL5Dmdw CRC: 949374461 -->The instructions that validate individual software components perform as specified.<!-- END:briefDescription,_0YuXEclgEdmt3adZL5Dmdw -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: mainDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:mainDescription,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 2159502479 --><p> This artifact covers all of
the steps that are required to validate
a software component. It specifies test entries,
execution conditions, and expected results. These details
are identified for the purpose of evaluating a
particular aspect of a scenario. </p>
<p> The tests should be self-documenting in a way that
makes it clear upon completion of the test whether the component has
run correctly. </p><!-- END:mainDescription,_NqSB0qeqEdmKDbQuyzCoqQ -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: purpose<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:purpose,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 528181499 -->Evaluate that a software component performs as specified.<!-- END:purpose,_NqSB0qeqEdmKDbQuyzCoqQ -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: impactOfNotHaving<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:impactOfNotHaving,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 1718076459 -->Not having developer tests can inhibit iterative development, because
there is no assurance that modified components are still working correctly
when you modify components iteration by iteration.<!-- END:impactOfNotHaving,_NqSB0qeqEdmKDbQuyzCoqQ -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: reasonsForNotNeeding<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:reasonsForNotNeeding,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 72249732 -->If the tests can be embedded into the actual production code, you might not need a separate work product. Nonetheless, some
level of support for developer testing is always necessary.<!-- END:reasonsForNotNeeding,_NqSB0qeqEdmKDbQuyzCoqQ -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: briefOutline<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:briefOutline,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 738054710 --><p>
There is no predefined template for this&nbsp;work product and a testing tool will&nbsp;affect how the work product is
handled, but here are some key issues that should be addressed:
</p>
<ul>
<li>
Setup
</li>
<li>
Inputs
</li>
<li>
Script
</li>
<li>
Expected Results
</li>
<li>
Evaluation Criteria
</li>
<li>
Clean-Up
</li>
</ul><!-- END:briefOutline,_NqSB0qeqEdmKDbQuyzCoqQ -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: representationOptions<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:representationOptions,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 706436263 --><p align="left">
The following are recommendation and options for representing this work product.
</p>
<h4>
Recommendation: Automated Code Unit
</h4>
<p>
The most appropriate technique for running these tests is using code that tests the components fully and that you can
run regularly as you update the system during development.
</p>
<p>
When code is the&nbsp;sole form of the tests, you must take care to ensure that the code is self-documenting, including
specifications of what conditions you are testing and what setup or clean-up is required for the test to run properly.
</p>
<h4>
Option: Manual Instructions
</h4>
<p>
In some cases, manual instructions can suffice. For example, when testing a user interface, a Developer could walk
through a script, explaining the component. In this case, it can still be valuable to create a test harness that goes
straight to the user interface. That way, the Developer can follow the script without having to walk through a
complicated set of instructions to get to a particular screen or page.
</p>
<h4>
Option: Embedded Code
</h4>
<p>
Certain technologies (such as Java&trade; 5 Test Annotation) enable you to embed tests in the implementation. In those cases,
there will be a logical work product, but it will be assimilated into the code that you are testing. Here, too, take
into consideration that you must ensure that the code is self-documenting.
</p><!-- END:representationOptions,_NqSB0qeqEdmKDbQuyzCoqQ -->
</body>
</html>