Test Design Technique – Data Combination Test
Aug12
As an ongoing story, here, again, is something about a test design technique. I wrote this post also I’ve been educating some testers in the art of testing with this test design technique. The Data Combination Test (DCoT) is a versatile technique where no specific test basis required.
“DCoT can be used with information in the experts’ heads”
The DCoT is a technique that can be used for creating test cases on a multitude of documentation which describe the functionality of the systems. These are formal system documentation (like functional design, logical data model and requirements), informal documentation (like manuals, folders, pre-surveys and memos) and domain expertise that are not documented, but reside ‘in the experts’ heads’.
The DCoT has a strong informal character. Because of this the quality of the test cases designed with it is largely determined by the expertise and skill of the test engineers involved.
“DCoT covers the quality attribute Functionality”
As with the UCT the DCoT covers quality characteristics (ISO 9126 or TMap) of the test object. For DCoT this is functionality. Both overall and detail functionality.
Like the UCT from here there are standard 5 steps that need to be taken:
Test Situations
The DCoT determines that the test situations are reasoned from within the data attribute as to which variations should be tested. The basic technique that can be used is equivalence classes, but depending on the agreed depth of the test, the coverage can be extended by combining the equivalence classes of two or more different data. These can be with pair wise testing and a complete decision table (multiple condition coverage) on selected data attributes.
“Test situations can be created with equivalence classes”
Also the test cases can be reinforced by using boundary value analysis. The boundary values can be used as specific data attribute within the equivalence classes.
Creating, or identifying, the test situations is a creative process but contains the following five activities:
- Determine data attributes influencing the functionality.
- Determine equivalence classes for each data attribute
- Determine relationships between data attributes.
- Create a Classification Tree.
- Define the data pairs to be combined.
Determine data attributes influencing the functionality
Not necessarily all data attributes need to be used by the functionality that is to be tested. Only the data attributes for which equivalence classes can be created are used. These can be entities, attributes or functional concepts.
Determine equivalence classes for each data attribute.
The entire value range of a parameter is partitioned into classes, in which the system behaviour is similar (equivalent).
Determine relationships between data attributes.
There are some data attributes that only influence the behaviour of the SuT under certain conditions. This happens when another data attribute has a value from a specific other equivalence class. This can be illustrated using a classification tree.
Create a Classification Tree.
The classification tree is a graphical display of the grouping of data attributes that logically belong together. Equivalence class are hung under data (branches on the tree) and the view of relationships is visible (data attribute varies equivalence class of other data attributes).
Define the data pairs to be combined.
Depending on agreed weight all the equivalence classes of one data attribute need to be combined with other equivalence classes’ data attributes.
“Identifying test situations is shown by a Classification Tree”
Logical test cases
A logical test case is derived from the data attributes from one equivalence class in the classification tree. As a result the whole tree should be covered by logical test cases. When test depth varies also the combinations of the different data attributes of the equivalence classes cover the classification tree.
The Classification Tree Editor is an open source tool that can be used here.
“The logical test cases can be derived by using the Classification Tree Editor”
Physical test cases
For the physical test cases the concrete values for all the input data should be chosen. Like always every physical test cases should have a predicted result.
“Physical test cases always should have a predicted result”
Test script
The starting point needs to be developed from the physical test cases. After this the test script can be build.
“The test script derives from the starting point and physical test case”
August 13th, 2009 at 04:26
Ewald,
Nice post. In my view, efficient and effective test design techniques are a dramatically under-appreciated part of being an effective software tester.
Structured approaches such as the one you lay out above, which enroll the power of computers to “keep track of the details” and ensure that proper coverage is achieved can be significantly more effective than purely manual test case identification methods (which are prone to accidentally omitting coverage). This is particularly true when testers are trying to identify potential defects that will only be triggered upon the interaction of two or more values or configuration settings.
Keep up the good work in educating testers about important test design techniques!
- Justin Hunter
August 14th, 2009 at 04:13
Justin,
Thanks for the appreciation. You are correct using the correct test techniques is far better compared to manual test cases. But unfortunately testers still don’t use the test techniques, because they don’t know them. Question is: How do those project cover their test strategy?
We are going to write even more about the test design techniques. So check back.
Ewald
August 26th, 2009 at 05:16
[...] with the DCoT, the PIT covers the quality characteristic (ISO 9126 or TMap) functionality of the test object. But [...]
April 14th, 2010 at 14:50
Get all WooThemes WordPress themes by joining Mega Themes Club…
Mega Themes Club offers WooThemes WordPress Themes to all club members. Joining is easy and affordable……
May 3rd, 2010 at 15:46
hi guys…
hi guysI would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well and i have start my own blog now, , thanks for your effort…
June 8th, 2010 at 15:43
http://delicious.com/freestyleonnet…
Exchange their ideas under the release of everyone’s ideas to creative freedom to fly!…
February 16th, 2011 at 14:14
[...] Test innovation and the future Test Design Technique: Data Combination Tests [...]
November 12th, 2011 at 10:37
useful articles…
[...]Test Design Technique – Data Combination Test :: Software Testing and more[...]…