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