Apologies for the lengthy answer. I have studied this exact problem in depth for the last 8 years or so, am passionate about the topic, have put significant thought into it, and hope that you'll find some of my experiences to be relevant to your situation.
For full disclosure, I should point out that I have created a test design tool called Hexawise so I ...
The case of pairwise is most compelling when the combinatorial problem is so large that exhaustive testing is infeasible, e.g. when exhaustive testing is orders of magnitude more expensive than pairwise testing. It sounds as if that is not the case for your situation.
Alternatively, you can make both of the these points:
it is worthwhile to find ways to ...
"The value of any practice depends on its context"
N-wise testing is a technique, not a silver bullet to solve any problem.
It's your responsibility as a professional to analyze how to best approach a specific problem.
Take the example of a pairwise analysis:
valid name, valid password
valid name, invalid password
invalid name, valid password
There are tools that will generate a set of tests that cover every combination at least once without hitting all possible combinations (these work on the principle that most bugs will be surfaced by exercising pairs of settings).
Since the feature hasn't gone live, your business analyst is probably your best reference for the combinations that are most ...
If at all possible, this would be an ideal test to automate. If you decide to do that, below is an article by James Bach and Patrick Schroeder that is illuminating. The core idea of the article is that selection of a good pairing algorithm is not straightforward and a simple randomization approach is a good technique for getting effective coverage, whether ...
This is not a safe assumption for at least 2 reasons:
The code can change over time, and unless you can track it and remember you basic assumptions you are taking an unnecessary risk.
The same code snippet can see different input values under different modules (see the Ariane 5's same horizontal acceleration module as that of Ariane 4 but different ...
I read once this paragraph in the Django (Python framework) tutorial about repeating testing and it definitely convinced me:
When testing, more is better:
It might seem that our tests are growing out of control. At this rate there will soon be more code in our tests than in our application, and the repetition is unaesthetic, compared to the elegant ...
Pair Testing :
Pair testing is a collaborative effort, versus a single-person testing effort. Typically, one of the team members is a tester and the other is either a developer or a business analyst. Please refer this below link. (https://blog.testlodge.com/what-is-pair-testing/)
Pair testing helps in indentifying the ...
First of all, this is NOT a combinatorial testing problem. Combinatorial tests are based on 2 or more input parameters that accept multiple argument values.
In this case, you have a single argument which is the barcode. Your problem is a permutation problem. Essentially, you are attempting to explore various permutations of the Code 128 barcode format.
What is Pair testing?
Pairwise testing is a practice where two team members are sitting together to test the software application on the same machine. The team members for pair testing can be a tester- developer, tester-tester, tester-business analyst.
The Outcome of Pair testing
How I would approach the task. I wouldn't use pairwise technique. I would rather use Equivalent Partitioning technique. Since we're testing a finite set of rules (we do not have 100000 rules one for each route) I would concentrate not on the combinations but on the states (the more abstract the states are - the better).
Treat you rule engine as finite ...
I believe this post and associated links over on Stack Overflow give a pretty comprehensive treatment on those and other techniques - https://stackoverflow.com/questions/22595283/orthogonal-and-combinatorial-testing-techniques
The short answer is that an equilateral triangle is also an isosceles triangle.
Because you have the least restrictive check first, that check will identify all your equilateral triangles as isosceles triangles.
This is a pretty good example of why it's not a good idea to combine multiple checks into a single code routine: you aren't necessarily checking ...