The category-partition method and the classification-tree method help construct test cases from specifications. In both methods, an early step is to identify a set of categories (or classifications) and choices (or classes). This is often performed in an ad hoc manner due to the absence of systematic techniques. In this paper, we report and discuss three empirical studies to investigate the common mistakes made by software testers in such an ad hoc approach. The empirical studies serve three purposes: (a) to make the knowledge of common mistakes known to other testers so that they can avoid repeating the same mistakes, (b) to facilitate researchers and practitioners develop systematic identification techniques, and (c) to provide a means of measuring the effectiveness of newly developed identification techniques. Based on the results of our studies, we also formulate a checklist to help testers detect such mistakes. q

Various black-box methods for the generation of test cases have been proposed in the literature. Many of these methods, including the category-partition method and the classification-tree method, follow the approach of partition testing, in which the input domain is partitioned into subdomains according to important aspects of the specification, and test cases are then derived from the subdomains. Though comprehensive in terms of these important aspects, execution of all the test cases so generated may not be feasible under the constraint of tight testing resources. In such circumstances, there is a need to select a smaller subset of test cases from the original test suite for execution. In this paper, we propose the use of white-box information to guide the selection of test cases from the original test suite generated by a black-box testing method. Furthermore, we have developed some techniques and algorithms to facilitate the implementation of our approach, and demonstrated its viability and benefits by means of a case study. . Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15. For personal use only. 114 Y. T. Yu et al.due to the huge size of the input domain. Thus, a more practical approach is to construct a test suite, that is, a subset of the input domain for testing [2,3].The construction of a test suite is a critical component of the testing process, since it affects the scope and comprehensiveness of the test. Moreover, it largely determines the amount of testing resources required. Ideally, a test suite has to satisfy many requirements, but in reality some of these requirements may be conflicting. For example, the test suite should be as comprehensive as possible so that it is effective in detecting faults in the software, and it should be as small as possible in order to control the cost of the testing. A very comprehensive test suite containing a large number of test cases can be too costly to be practical, while a small but inadequate test suite may fail to detect some of the faults that exist.Various testing strategies have been proposed for systematic construction of a test suite. These strategies have been broadly classified as white-box (or code-based ) testing or black-box (or specification-based ) testing. The former refers to testing based on the information derived from the source code of the program, whereas the latter makes use of information from the specification. Both white-box and blackbox testing have their own merits and limitations; they are generally considered complementary to each other [4][5][6]. In principle, a testing methodology based on either black-box or white-box information alone is necessarily incomplete.Generally, white-box testing requires the test cases to execute the various components of the program code. Typical examples are (a) branch and path testing [7], which are based on the program's control flow structure, (b) data-flow testing [8,9], which exploits the definition-use associations of the program variables, and (c) mutation tes...

An early step for most black-box testing methods is to identify a set of categories and choices (or their equivalents) from the specification. The identification is often performed in an ad hoc manner, thus the quality of categories and choices is in doubt. Poorly identified categories and choices will affect the comprehensiveness of test cases. In this paper, we describe several comparative studies using three commercial specifications and discuss the major results. The objectives of our studies are (a) to investigate the differences in the types and amounts of mistakes made between inexperienced and experienced software testers in an ad hoc identification approach and (b) to determine the extent of mistake reduction after discussing the mistakes with the software testers and providing them with an identification checklist.

The choice relation framework (CHOC'LATE)

The quality of a requirements specification has a great impact on the quality of the software developed. Because of this, a requirements specification should be complete, correct, consistent, and unambiguous. Otherwise, defects may remain undetected, resulting In this paper, we propose a problem-driven approach for supporting the PBR technique. We also discuss the experience of applying our proposal to a real-life requirements specification.