<?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" xmi:id="-OrjIrRLW6v_XnqLUQ9GYaQ" name="test-ideas_catalog,1.2384224477983028E-305" guid="-OrjIrRLW6v_XnqLUQ9GYaQ" changeDate="2006-12-02T03:38:47.336+0330" version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_test-ideas_catalog__concept_of&quot; name=&quot;XE_test-ideas_catalog__concept_of&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Introduction&quot; name=&quot;Introduction&quot;>Introduction&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Much of programming involves taking things you've used over and over before, and then using them yet again in a&#xD;
    different context. Those things are typically of certain classes-data structures (such as linked lists, hash tables, or&#xD;
    relational databases) or &lt;a href=&quot;./../../../glossary/glossary.htm#operation&quot; target=&quot;_blank&quot;>&lt;i>operations&lt;/i>&lt;/a>&#xD;
    (such as searching, sorting, creating temporary files, or popping up a browser window). For example, two customer&#xD;
    relational databases will have many clichéd characteristics.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The interesting thing about these clichés is that they have clichéd &lt;a href=&quot;./../../../glossary/glossary.htm#fault&quot; target=&quot;_blank&quot;>&lt;i>faults&lt;/i>&lt;/a>. People do not invent imaginative new ways to insert something incorrectly into a&#xD;
    doubly-linked list. They tend to make the same mistakes that they and others have made before. A programmer who pops up&#xD;
    a browser window might make one of these clichéd mistakes:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        creates a new window when one that's already open should be reused&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        fails to make an obscured or minimized browser window visible&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        uses Internet Explorer when the user has chosen a different default browser&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        fails to check whether JavaScript is enabled&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Since faults are clichéd, so are the &lt;a href=&quot;./../../../glossary/glossary.htm#test_idea&quot; target=&quot;_blank&quot;>&lt;i>test&#xD;
    ideas&lt;/i>&lt;/a> that can find them. Put these test ideas in your test-idea catalog so you can reuse them.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;HowCatalogsFindFaults&quot; name=&quot;HowCatalogsFindFaults&quot;>How a Test-Ideas Catalog Finds Faults&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    One of the virtues of a catalog is that a single test idea can be useful for finding more than one underlying fault.&#xD;
    Here's an example of one idea that finds two faults.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The first fault was in a C compiler. This compiler took command-line options like &quot;-table&quot; or &quot;-trace&quot; or &quot;-nolink&quot;.&#xD;
    The options could be abbreviated to their smallest unique form. For example, &quot;-ta&quot; was as good as &quot;-table&quot;. However,&#xD;
    &quot;-t&quot; was not allowed, because it was ambiguous: it could mean either &quot;-table&quot; or &quot;-trace&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Internally, the command-line options were stored in a table like this:&#xD;
&lt;/p>&#xD;
&lt;div align=&quot;left&quot;>&#xD;
    &lt;table cellspacing=&quot;0&quot; cellpadding=&quot;2&quot; width=&quot;25%&quot; border=&quot;1&quot;>&#xD;
        &lt;tbody>&#xD;
            &lt;tr>&#xD;
                &lt;td width=&quot;100%&quot;>&#xD;
                    -table&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;td width=&quot;100%&quot;>&#xD;
                    -trace&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;td width=&quot;100%&quot;>&#xD;
                    -nolink&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
        &lt;/tbody>&#xD;
    &lt;/table>&lt;br />&#xD;
&lt;/div>&#xD;
&lt;p>&#xD;
    When an option was encountered on the command line, it was looked up in the table. It matched if it was the prefix of&#xD;
    any table entry; that is, &quot;-t&quot; matched &quot;-table&quot;. After one match was found, the rest of the table was searched for&#xD;
    another match. Another match would be an error, because it would indicate ambiguity.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The code that did the searching looked like this:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
for (first=0; first &amp;lt; size; first++) {&#xD;
    if (matches(entry[first], thing_sought)) {&#xD;
/* at least one match */&#xD;
for(dup=first+1; dup &amp;lt; size; dup++)&#xD;
    /* search for another */&#xD;
    if (matches(entry[dup], thing_sought))&#xD;
        /* extra match */&#xD;
        break;  /* error out */&#xD;
return first;&#xD;
    }&#xD;
}&#xD;
return -1;  /* Not found or ambiguity */&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    Do you see the problem? It's fairly subtle.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The problem is the break statement. It's intended to break out of the outermost enclosing loop when a duplicate match&#xD;
    is found, but it really breaks out of the inner one. That has the same effect as not finding a second match: the index&#xD;
    of the first match is returned.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Notice that this fault can only be found if the option being sought for matches twice in the table, as &quot;-t&quot; would.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Now let's look at a second, completely different fault.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The code takes a string. It is supposed to replace the last '=' in the string with a '+'. If there is no '=', nothing&#xD;
    is done. The code uses the standard C library routine &lt;font size=&quot;+0&quot;>strchr&lt;/font> to find the location of '='. Here's&#xD;
    the code:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
ptr = strchr(string, '=');  /* Find last = */&#xD;
if (ptr != NULL_CHAR)&#xD;
    *ptr = '+';&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    This problem here is also somewhat subtle.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The function &lt;font size=&quot;+0&quot;>strchr&lt;/font> returns the &lt;i>first&lt;/i> match in the string, not the last. The correct&#xD;
    function is &lt;font size=&quot;+0&quot;>str&lt;b>&lt;u>r&lt;/u>&lt;/b>chr&lt;/font>. The problem was most likely a typographical error. (Actually,&#xD;
    the deep underlying problem is that it's definitely unwise to put two functions that differ only by a typo into a&#xD;
    standard library.)&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This fault can only be found when there are two or more equal signs in the input. That is:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &quot;a=b&quot; would return the correct result, &quot;a+b&quot;.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &quot;noequals&quot; would return the correct result, &quot;noequals&quot;.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &quot;a=b=c&quot; would incorrectly return &quot;a+b=c&quot;, not the correct &quot;a=b+c&quot;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    What's interesting and useful here is that we have two faults with completely different root causes (typographical&#xD;
    error, misunderstanding of a C construct) and different manifestations in the code (wrong function called, misuse of&#xD;
    break statement) that can be found by the &lt;i>same&lt;/i> test idea (search for something that occurs twice).&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;GoodCatalogs&quot; name=&quot;GoodCatalogs&quot;>A Good Test-Ideas Catalog&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    What makes a good catalog?&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        It contains a small set of test ideas that can find a much larger set of underlying faults.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It's easy to read quickly (skim). You should be able to skip test ideas that are not relevant to your situation.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It contains only test ideas that you will use. For example, someone who doesn't ever deal with Web browsers&#xD;
        shouldn't have to keep skipping over test ideas for programs that use Web browsers. Someone working on game&#xD;
        software will want a shorter catalog than someone working on safety-critical software. The game person can afford&#xD;
        to concentrate only on the test ideas with the highest chance of finding faults.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Given these rules, it seems best to have more than one catalog. Some data and operations are common to all programming,&#xD;
    so their test ideas can be put into a catalog that all programmers can use. Others are specific to a particular domain,&#xD;
    so test ideas for them can be put into a catalog of domain-specific test ideas.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A sample catalog (&lt;a href=&quot;./resources/tstids_short-catalog.pdf&quot; target=&quot;_blank&quot;>tstids_short-catalog.pdf&lt;/a>) (&lt;a href=&quot;http://www.adobe.com/products/acrobat/alternate.html&quot;>Get Adobe Reader&lt;/a>), used in the following example, is a&#xD;
    good one from which to begin. &lt;a href=&quot;../../../examples/extrnlcntrbtns/test/tstatmtch.htm&quot;>Test Ideas for Mixtures of&#xD;
    ANDs and ORs&lt;/a> provides another example.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;UsingACatalogExample&quot; name=&quot;UsingACatalogExample&quot;>An Example of Using a Test-Ideas Catalog&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Here's how you might use the sample catalog (&lt;a href=&quot;./resources/tstids_short-catalog.pdf&quot; target=&quot;_blank&quot;>tstids_short-catalog.pdf&lt;/a>) (&lt;a href=&quot;http://www.adobe.com/products/acrobat/alternate.html&quot;>Get&#xD;
    Acrobat Reader&lt;/a>). Suppose you're implementing this method:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
void applyToCommonFiles(Directory d1,&#xD;
                Directory d2,&#xD;
                Operation op);&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> takes two directories as arguments. When a file in the first directory has&#xD;
    the same name as a file in the second, &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> performs some operation on that pair&#xD;
    of files. It descends subdirectories.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The method for using the catalog is to scan through it looking for major headings that match your situation. Consider&#xD;
    the test ideas under each heading to see if they are relevant, and then write those that are relevant into a &lt;a class=&quot;elementLink&quot; href=&quot;./../../../xp/guidances/concepts/test-ideas_list.html&quot; guid=&quot;8.834380241450745E-306&quot;>Test-Ideas List&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;b>Note:&lt;/b> This step-by-step description might make using the catalog seem laborious. It takes longer to read about&#xD;
    creating the checklist than it does to actually create one.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    So, in the case of &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font>, you might apply the catalog in the manner described&#xD;
    throughout the rest of this section.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The first entry is for &lt;b>Any Object&lt;/b>. Could any of the arguments be null pointers? This is a matter of the contract&#xD;
    between &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> and its callers. The contract could be that the callers will not pass&#xD;
    in a null pointer. If they do, you can't rely on th expected behavior: &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> could&#xD;
    perform any action. In such a case, no test is appropriate, since nothing &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font>&#xD;
    does can be wrong. If, however, &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> is required to check for null pointers, the&#xD;
    test idea would be useful. Let's assume the latter, which gives us this starting Test-Ideas List:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        d1 is null (error case)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d2 is null (error case)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        op is null (error case)&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The next catalog entry is &lt;b>Strings&lt;/b>. The names of the files are strings, and they're compared to see if they&#xD;
    match. The idea of testing with the empty string (&quot;&quot;) doesn't seem useful. Presumably some standard string comparison&#xD;
    routines will be used, and they will handle empty strings correctly.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    But wait... If there are strings being compared, what about case? Suppose &lt;font size=&quot;+0&quot;>d1&lt;/font> contains a file&#xD;
    named &quot;File&quot; and &lt;font size=&quot;+0&quot;>d2&lt;/font> contains a file named &quot;file&quot;. Should those files match? On UNIX, clearly&#xD;
    not. On Microsoft&amp;reg; Windows&amp;reg;, they almost certainly should. That's another test idea:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Files match in the two directories, but the case of the names is different.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Notice that this test idea didn't come directly from the catalog. However, the catalog drew our attention to a&#xD;
    particular aspect of the program (file names as strings), and our creativity gave us an additional idea. It's important&#xD;
    not to use the catalog too narrowly-use it as a brainstorming technique, a way of inspiring new ideas.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The next entry is &lt;b>Collections&lt;/b>. A directory is a collection of files. Many programs that handle collections fail&#xD;
    on the empty collection. A few that handle the empty collection, or collections with many elements, fail on collections&#xD;
    with exactly one element. So these ideas are useful:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        d1 is empty&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d2 is empty&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d1 has exactly one file&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d2 has exactly one file&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The next idea is to use a collection of the maximum possible size. This is useful because programs like &lt;font     size=&quot;+0&quot;>applyToCommonFiles&lt;/font> are often tested with trivial little directories. Then some user comes along and&#xD;
    applies them to two huge directory trees with thousands of files in them, only to discover that the program is&#xD;
    grotesquely memory inefficient and can't handle that realistic case.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Now, testing the absolute maximum size for a directory is not important; it only needs to be as large as a user might&#xD;
    try. However, at the very least, there should be &lt;i>some&lt;/i> test with more than three files in a directory:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        d1 contains very many files&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d2 contains very many files&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The final test idea (duplicate elements) doesn't apply to directories of files. That is, if you have a directory with&#xD;
    two files that have the same name, you have a problem independent of &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font>-your&#xD;
    file system is corrupt.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The next catalog entry is &lt;b>Searching&lt;/b>. Those ideas can be translated into &lt;font     size=&quot;+0&quot;>applyToCommonFiles&lt;/font> terms like this:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        d1 and d2 have no files in common (all the names are different)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d1 and d2 have exactly one file in common (it's alphabetically the last element in the directory)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d1 and d2 have more than one file in common&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The final test idea checks whether &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> terminates too soon. Does it return as&#xD;
    soon as it finds the first match? The parenthetical remark in the test idea before that assumes that the program will&#xD;
    fetch the list of files in a directory using some library routine that returns them, sorted alphabetically. If not, it&#xD;
    might be better to find out what the last one really is (the most recently created?) and make that be the match. Before&#xD;
    you devote a lot of time to finding out how files are ordered, though, ask yourself how likely it is that putting the&#xD;
    matching element last will make finding defects easier. Putting an element last in a collection is more useful if the&#xD;
    code explicitly steps through the collection using an index. If it's using an iterator, it's extremely unlikely that&#xD;
    the order matters.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Let's look at one more entry in the sample catalog. The &lt;b>Linked structures&lt;/b> entry reminds us that we're comparing&#xD;
    directory &lt;i>trees&lt;/i>, not just flat collections of files. It would be sad if &lt;font     size=&quot;+0&quot;>applyToCommonFiles&lt;/font> worked only in the top-level directories, but not in the lower-level ones. Deciding&#xD;
    how to test whether &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> works in lower-level directories forces us to confront&#xD;
    the incompleteness of its description.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    First, when does &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> descend into subdirectories? If the directory structure&#xD;
    looks like this&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;162&quot; alt=&quot;&quot; src=&quot;resources/tstidsctl-img1.gif&quot; width=&quot;334&quot; />&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;picturetext&quot;>&#xD;
    Figure 1: A directory structure&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    does &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> descend into &lt;font size=&quot;+0&quot;>Cdir&lt;/font>? That doesn't seem to make&#xD;
    sense. There can be no match with anything in the other directory tree. In fact, it seems as if files in subdirectories&#xD;
    can only match if the subdirectory names match. That is, suppose we have this directory structure:&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;165&quot; alt=&quot;&quot; src=&quot;resources/tstidsctl-img2.gif&quot; width=&quot;334&quot; />&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;picturetext&quot;>&#xD;
    Figure 2: A second directory structure&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The files named &quot;File&quot; don't match because they're in different subdirectories The subdirectories should be descended&#xD;
    only if they have the same name in both &lt;font size=&quot;+0&quot;>d1&lt;/font> and &lt;font size=&quot;+0&quot;>d2&lt;/font>. That leads to these&#xD;
    test ideas:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        some subdirectory in d1 is not found in d2 (no descent)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        some subdirectory in d2 is not found in d1 (no descent)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        some subdirectory appears in both d1 and d2 (descend)&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    But that raises other questions. Should the operation (&lt;font size=&quot;+0&quot;>op&lt;/font>) be applied to matching subdirectories&#xD;
    or just to matching files? If it's applied to the subdirectories, should it be applied before the descent or afterward?&#xD;
    That makes a difference if, for example, the operation deletes the matching file or directory. For that matter,&#xD;
    &lt;i>should&lt;/i> the operation be allowed to modify the directory structure? And more specifically: what's the correct&#xD;
    behavior of &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> if it does? (This is the same issue that comes up with&#xD;
    iterators.)&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    These sorts of questions typically arise when you carefully read a method's description of creating test ideas. But&#xD;
    let's leave them aside for now. Whatever the answers are, there will have to be test ideas for them-test ideas that&#xD;
    check whether the code correctly implements the answers.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Let's return to the catalog. We still haven't considered all of its test ideas. The first one-empty (nothing in&#xD;
    structure)-asks for an empty directory. We've already got that from the &lt;b>Collections&lt;/b> entry. We've also got the&#xD;
    &lt;b>minimal non-empty&lt;/b> structure, which is a directory with a single element. This sort of redundancy is not&#xD;
    uncommon, but it's easy to ignore.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    What about &lt;b>a circular structure&lt;/b>? Directory structures can't be circular-a directory can't be within one of its&#xD;
    descendants or within itself... or can it? What about shortcuts (on Windows) or symbolic links (on UNIX)? If there's a&#xD;
    shortcut in &lt;font size=&quot;+0&quot;>d1&lt;/font>'s directory tree that points back to &lt;font size=&quot;+0&quot;>d1&lt;/font>, should &lt;font     size=&quot;+0&quot;>applyToCommonFiles&lt;/font> keep descending forever? The answer could lead to one or more new test ideas:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        d1 is circular because of shortcuts or symbolic links&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        d2 is circular because of shortcuts or symbolic links&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Depending on the correct behavior, there may be more test ideas than that.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Finally, what about &lt;b>depth greater than one&lt;/b>? Earlier test ideas will ensure that we test descending into one&#xD;
    level of subdirectory, but we should check that &lt;font size=&quot;+0&quot;>applyToCommonFiles&lt;/font> keeps descending:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        descends through several levels (&amp;gt;1) of d1's subdirectories&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        descends through several levels (&amp;gt;1) of d2's subdirectories&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;CreatingYourOwnCatalogs&quot; name=&quot;CreatingYourOwnCatalogs&quot;>Creating and Maintaining Your Own Test-Ideas Catalog&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    As mentioned previously, the generic catalog won't contain all of the test ideas you need. But &lt;a href=&quot;./../../../glossary/glossary.htm#domain&quot; target=&quot;_blank&quot;>&lt;i>domain&lt;/i>&lt;/a>-specific catalogs haven't been&#xD;
    published outside of the companies that created them. If you want them, you'll need to build them. Here's some advice.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Do not fill a catalog with your speculations about what ideas would be good for finding faults. Remember that each&#xD;
        test idea you put in the catalog costs time and money: &#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                your time to maintain the catalog&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                other programmers' time to think about the test idea&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                possibly other programmers' time to implement a test&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&lt;br />&#xD;
         Add only ideas that have a demonstrated track record. You should be able to point to at least one actual fault&#xD;
        that the test idea would have caught. Ideally, the fault should be one that was missed by other testing; that is,&#xD;
        one that was reported from the field. One good way to build catalogs is to browse through your company's bug&#xD;
        database and ask questions about how each fault could have been detected earlier.&#xD;
    &lt;/li>&#xD;
    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
        &lt;br />&#xD;
        &lt;br />&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It's unlikely to work if creating and maintaining a Test-Ideas Catalog is something you do in your spare time.&#xD;
        You'll need time specifically allocated to this task, just like for any other important one. We recommend you&#xD;
        create and maintain your Test-Ideas Catalog during &lt;a href=&quot;wfs_imptstast.htm&quot;>Workflow Detail: Improve Test&#xD;
        Assets&lt;/a>.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&lt;br />&#xD;
&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
