<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_y3rxsMM3EdmSIPI87WLu3g" name="test_ideas,_0jzlsMlgEdmt3adZL5Dmdw" guid="_y3rxsMM3EdmSIPI87WLu3g" changeDate="2006-09-29T09:37:59.000-0700" version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Test ideas are used to generate tests.&amp;nbsp;Test ideas can come from many different sources.&amp;nbsp;In general, they can&#xD;
    be derived in different ways depending on the given development domain, the kind of application being developed, and&#xD;
    the sophistication of the testers.&amp;nbsp;Although test ideas are derived in many different ways, there are some useful&#xD;
    categories for generating them.&amp;nbsp;This guideline will describe some of these categories as well as some general&#xD;
    heuristics for creating good test ideas.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Test Ideas and Functions&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Below are some test ideas to calculate the square root:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        A number that's barely less than zero as input&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Zero as the input&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Print to a LaserJet IIIp&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Test with database full&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    The first&amp;nbsp;3 test ideas validate input while the last 2 address environmental issues.&amp;nbsp; Even though these&#xD;
    statements are very incomplete they ensure that an idea is not forgotten.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Test Ideas and Boundaries&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Test ideas are often based on fault models.&amp;nbsp; Consider boundaries. It's safe to assume the square root function can&#xD;
    be implemented something like this:&lt;br />&#xD;
    &lt;!-- START NON-TRANSLATABLE -->&#xD;
    double sqrt(double x) {&lt;br />&#xD;
    &amp;nbsp;&amp;nbsp;&amp;nbsp; if (x &amp;lt; 0)&lt;br />&#xD;
    &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; // signal error&lt;br />&#xD;
    &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ...&lt;br />&#xD;
    &lt;!-- END NON-TRANSLATABLE -->&#xD;
    It's also plausible that the &amp;lt; will be incorrectly typed as &amp;lt;=. People often make that kind of mistake, so it's&#xD;
    worth checking. The fault cannot be detected with X having the value 2, because both the incorrect expression (x&amp;lt;=0)&#xD;
    and the correct expression (x&amp;lt;0) will take the same branch of the if statement. Similarly, giving X the value -5&#xD;
    cannot find the fault. The only way to find it is to give X the value 0, which justifies the second test idea.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Test Idea and Methods&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either&#xD;
    obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is&#xD;
    found.&lt;br />&#xD;
    int Collection.find(String string, Boolean ignoreCase);&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Here are some test ideas for this method, each of which could be implemented as a test.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Match found in the first position&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Match found in the last position&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        No match found&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Two or more matches found in the collection&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Case is ignored; match found, but it wouldn't match if case was obeyed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Case is obeyed; an exact match is found&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Case is obeyed; a string that would have matched if case were ignored is skipped&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    However, different test ideas can be combined into a single test; for example, the following test satisfies test ideas&#xD;
    2, 6, and 7:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Setup:&lt;/strong> Collection initialized to [&quot;dawn&quot;, &quot;Dawn&quot;]&lt;br />&#xD;
    &lt;strong>Invocation:&lt;/strong> Collection.find(&quot;Dawn&quot;, false)&lt;br />&#xD;
    &lt;strong>Expected result:&lt;/strong> Return value is 1 (it would be 0 if &quot;dawn&quot; were not skipped)&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Test Idea Simplicity and Complexity&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Making test ideas nonspecific makes them easier to combine.&lt;br />&#xD;
    Creating many several small tests that satisfy a few test ideas makes it simpler to:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &quot;Copy and Tweak&quot; the tests to meet other test idea&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Easy of debugging - if you have test that covers 2 test ideas then you know the fault is one or two area, but if&#xD;
        the test covers 7 test ideas you will spend more time debugging the issue.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    If the test ideas list were complete, with a test idea for every fault in the program, it wouldn't matter how you wrote&#xD;
    the tests. But the list is always missing some test ideas that could find bugs. Smaller more complex tests increase the&#xD;
    chance the test will satisfy a test idea that you didn't know you needed.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Complex Tests&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Sometimes when you're creating more complex tests, new test ideas come to mind. However, there are reasons for not&#xD;
    creating complex tests.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Complex test are more difficult to debug because they usually cover multiple test ideas&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Complex tests are more difficult to create.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Constructing a test that satisfies five test ideas often takes more time than constructing five tests that each&#xD;
    satisfies one. Moreover, it's easier to make mistakes - to think you're satisfying all five when you're only satisfying&#xD;
    four.&lt;br />&#xD;
    In practice, find a reasonable balance between complexity and simplicity.&lt;br />&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
