Classification Tree Editor Free Download
Nelson Suggs
The Classification Tree Method is a method for test design,[1] as it is used in different areas of software development.[2]It was developed by Grimm and Grochtmann in 1993.[3]Classification Trees in terms of the Classification Tree Method must not be confused with decision trees.
Prerequisites for applying the classification tree method (CTM) is the selection (or definition) of a system under test.The CTM is a black-box testing method and supports any type of system under test. This includes (but is not limited to) hardware systems, integrated hardware-software systems, plain software systems, including embedded software, user interfaces, operating systems, parsers, and others (or subsystems of mentioned systems).
With a selected system under test, the first step of the classification tree method is the identification of test relevant aspects.[4]Any system under test can be described by a set of classifications, holding both input and output parameters. (Input parameters can also include environments states, pre-conditions and other, rather uncommon parameters).[2] Each classification can have any number of disjoint classes, describing the occurrence of the parameter.The selection of classes typically follows the principle of equivalence partitioning for abstract test cases and boundary-value analysis for concrete test cases.[5]Together, all classifications form the classification tree. For semantic purpose, classifications can be grouped into compositions.
The maximum number of test cases is the Cartesian product of all classes of all classifications in the tree, quickly resulting in large numbers for realistic test problems.The minimum number of test cases is the number of classes in the classification with the most containing classes.
In the second step, test cases are composed by selecting exactly one class from every classification of the classification tree. The selection of test cases originally[3] was a manual task to be performed by the test engineer.
For a database system, test design has to be performed. Applying the classification tree method, the identification of test relevant aspects gives the classifications: User Privilege, Operation and Access Method.For the User Privileges, two classes can be identified: Regular User and Administrator User.There are three Operations: Add, Edit and Delete.For the Access Method, again three classes are identified: Native Tool, Web Browser, API.The Web Browser class is further refined with the test aspect Brand, three possible classes are included here: Internet Explorer, Mozilla Firefox, and Apple Safari.
The first step of the classification tree method now is complete. Of course, there are further possible test aspects to include, e.g. access speed of the connection, number of database records present in the database, etc. Using the graphical representation in terms of a tree, the selected aspects and their corresponding values can quickly be reviewed.
For the statistics, there are 30 possible test cases in total (2 privileges * 3 operations * 5 access methods). For minimum coverage, 5 test cases are sufficient, as there are 5 access methods (and access method is the classification with the highest number of disjoint classes).
The classification tree method first was intended for the design and specification of abstract test cases. With the classification tree method for embedded systems,[8] test implementation can also be performed. Several additional features are integrated with the method:
One way of modelling constraints is using the refinement mechanism in the classification tree method. This, however, does not allow for modelling constraints between classes of different classifications. Lehmann and Wegener introduced Dependency Rules based on Boolean expressions with their incarnation of the CTE.[9] Further features include the automated generation of test suites using combinatorial test design (e.g. all-pairs testing).
Recent enhancements to the classification tree method include the prioritized test case generation: It is possible to assign weights to the elements of the classification tree in terms of occurrence and error probability or risk. These weights are then used during test case generation to prioritize test cases.[10][11] Statistical testing is also available (e.g. for wear and fatigue tests) by interpreting the element weights as a discrete probability distribution.
With the addition of valid transitions between individual classes of a classification, classifications can be interpreted as a state machine, and therefore the whole classification tree as a Statechart. This defines an allowed order of class usages in test steps and allows to automatically create test sequences.[12] Different coverage levels are available, such as state coverage, transitions coverage and coverage of state pairs and transition pairs.
In addition to Boolean dependency rules referring to classes of the classification tree, Numerical Constraints allow to specify formulas with classifications as variables, which will evaluate to the selected class in a test case.[13]
The Classification Tree Editor (CTE) is used to design classification trees and create test case specifications in an intuitive way.
Describing the tree elements, setting values for it and creating a test case with its purpose as name results in a comprehensible test case specification.
In addition CTE provides features for more detailed test case specifications, for subdividing a tree in subtrees as well as an easy navigation through subtrees and elements and simplified handling by drag and drop and short keys.
However, in the ISTQB advanced level exam, questions asked will be to find the minimum/maximum number of test cases required by applying the classification tree method without the tool. Let us discuss how to calculate the minimum and the maximum number of test cases by applying the classification tree method.
In order to calculate the number of test cases, we need to identify the test relevant features (classifications) and their corresponding values (classes). By analyzing the requirement specification, we can identify classification and classes.
Consider a User Interface having one radio button, one drop-down box having four values in it and a multi-select box having five values in it. Let us identify classifications and classes for this scenario.
For this reason, a popular method for adding test cases to a Classification Tree is to place a single table beneath the tree, into which multiple test cases can be added, typically one test case per row. The table is given the same number of columns as there are leaves on the tree, with each column positioned directly beneath a corresponding leaf. Additional columns can also be added to preserve any information we believe to be useful. A column to capture the expected result for each test case is a popular choice.
One final option is to place the concrete test data in the tree itself. Notice how in the Figure 14 there is a value in brackets in each leaf. This is the value to be used in any test case that incorporates that leaf. It does mean that we can only specify a single concrete value for each group (or a pair for each boundary) to be used across our entire set of test cases. If this is something that we are satisfied with then the added benefit is that we only have to preserve the concrete values in one location and can go back to placing crosses in the test case table. This does mean that TC3a and TC3b have now become the same test case, so one of them should be removed.
In other walks of life people rely on techniques like clustering to help them explore concrete examples before placing them into a wider context or positioning them in a hierarchical structure. You would be forgiven for thinking that a Classification Tree simply provides structure and context for a number of test cases, so there is a lot to be said for brainstorming a few test cases before drawing a Classification Tree. Hopefully we will not need many, just a few ideas and examples to help focus our direction before drawing our tree.
It is worth mentioning that the Classification Tree technique is rarely applied entirely top-down or bottom-up. In reality, the outline of a tree is often drawn, followed by a few draft test cases, after which the tree is pruned or grown some more, a few more test cases added, and so on and so on, until finally we reach the finished product. But our work does not stop here. Due to their style, Classification Trees are easy to update and we should take full advantage of this fact when we learn something new about the software we are testing. This often occurs when we perform our test cases, which in turn triggers a new round of updates to our Classification Tree.
As we draw a Classification Tree it can feel rewarding to watch the layers and detail grow, but by the time we come to specify our test cases we are often looking for any excuse to prune back our earlier work. Remember that we create Classification Trees so that we may specify test cases faster and with a greater level of appreciation for their context and coverage. If we find ourselves spending more time tinkering with our tree than we do on specifying or running our test cases then maybe our tree has become too unwieldy and is in need of a good trim.
If we have chosen to represent one or more hierarchal relationships in our tree, we should ask ourselves whether they are all truly necessary. A tree with too much hierarchy can become difficult to read. By all means, we should add hierarchal relationships where they improve communication, but we should also aim to do so sparingly.
If Boundary Value Analysis has been applied to one or more inputs (branches) then we can consider removing the leaves that represent the boundaries. This will have the effect of reducing the number of elements in our tree and also its height. Of course, this will make it harder to identify where Boundary Value Analysis has been applied at a quick glance, but the compromise may be justified if it helps improve the overall appearance of our Classification Tree.
3a7c801d34