Unlike strong domain testing, weak domain testing requires a series of tests for each boundary inequality, while for strong domain testing we use a separate set of tests for each boundary segment. But this does not mean using a particular strategy. Your testing may be weak in relation to one set of boundaries and strong in relation to other. It all depends on the situation. Use weak testing, if you do not have special reasons for using a strong one, similar to the ones specified below.
- Discontinuity in the boundary inequality. This means that you have three segments to be tested. You, of course, may want to test the gap segment separately, but it will be better if you test both sides of the boundary inequality on both sides of the gap as inequalities, and not as segments.
- Changing the closure direction in one or more segments is a good reason to choose a strong strategy in relation to this inequality.
- The treatment process goes in such a way that some test points appear in an area that is not subsequently processed. Suppose we have several domains and any input that does not fall into these domains is discarded. The program code goes through three stages – checking of data conformity, classification of input, processing. Using weak testing, you select points that fall into the forbidden area. They are discarded, but testing the logic of equivalence partitioning is, in fact, not what interests you. Two sets of overlapping domains are everything what do you have.
- The first set specifies when to accept / discard data, and the second one determines when to begin data processing. Such implementation is in a certain sense superfluous, but this approach is unusually popular. If you use a weak strategy in this case, it may lead you to confusion. Many inputs will be discarded, since they fall outside the domains being processed, but they are discarded because of being randomly correct. Choosing a weak strategy, you draw a conclusion about the correctness of the boundaries that determine when the processing should start, based on boundary value analysis. This is a dangerous delusion. Strong domain testing is likely to be more secure. To make an informed choice, you will have to look into the code.
- Understand the programming style. If you see a clear, table-driven processing node with precisely identified boundary inequalities, and besides, there is a universal module that performs the classification, it is most likely that there is no need for strong testing.
Famous Ukrainian qa company offers application testing services for desktop, mobile and ecommerce apps. Our expert engineers are always an integral part of any project that we work on to provide the deliverables that satisfy the strictest quality standards.