I've been working on the pairwise topic for more than one month now and I went from "pairwise testing is a nice method in theory, but not applicable in our case" to "pairwise is nice in theory and might be applicable in our case" to finally "pairwise is applicable in our case!".

I have already elaborated some test plans that would save us up to 50% effort with that method. But now my boss and other colleagues are asking me for a proof that these pairwise testcases suffice to make sure our software is running well. I alredy told them when going from exhaustive testing to pairwise combinations theres always a chance you wont find some bugs because you dont test all 3- (or n-) way combinations. Thus i can't prove my testcases will find all errors (or at least as many as exhaustive testing). At best I can say because of softwareprogramming considerations pairwise methods will find "most" bugs with less effort than exhaustive testing.

So if anyone of you sees another point to convice my colleagues of pairwise testing please feel free to answer.

  • They're shooting down your suggested method of testing because it isn't proven to find all possible bugs? </bewilderedLook>
    – corsiKa
    Commented Nov 19, 2013 at 17:52
  • They are asking for "proof that these pairwise testcases suffice to make sure our software is running well". Why are you worried about "find all errors" and "less effort than exhaustive testing"? Neither of those answer the question being asked. Commented Nov 20, 2013 at 18:11

2 Answers 2


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 have a conflict of interest. That having been said, here are my experiences.


About 8 years ago, I was working at a large systems integration firm and was asked to help the firm differentiate its testing offerings from the testing services provided by other firms.

I admittedly did not know much about software testing then but by happy coincidence, my father was a leading expert in the field of Design of Experiments. Design of Experiments is a field that has applicability in many areas (including agriculture, advertising, manufacturing, etc.) The purpose of Design of Experiments is to provide people with tools and approaches to help people learn as much actionable information as possible in as few tests as possible.

I Googled "Design of Experiments Software Testing." That search led me to Dr. Madhav Phadke (who, by coincidence, had been a former student of my father). More than 20 years ago now, Dr. Phadke and his colleagues at ATT Bell Labs had asked the question you're asking now. They did an experiment using pairwise test design / orthogonal array test design to identify a subset of tests for ATT's StarMail system. The results of that testing effort were extraordinarily successful and well-documented.

Shortly after doing that, while working at that systems integration firm, I began to advocate to anyone and everyone who would listen that designing approach to designing tests promised to be both (a) more thorough and (b) require (in most but not all cases) significantly fewer tests. Results from 17 straight projects confirmed that both of these statements were true.


How did we demonstrate that this test design approach led to both more thorough testing and much more efficient testing? We followed these steps:

  1. Take an existing set of 30 - 100 existing tests that had already been created, reviewed, and approved for testing (but which had not yet been executed).
  2. Using the test ideas included in those existing tests, design a set of pairwise tests (often approximately half as many tests as were in the original set). When putting your tests together, if there are particular, known, high-priority scenarios that stakeholders believe are important to test, it is important to make sure that that you "force" your pairwise test generator to include such high-priority scenarios.
  3. Have two different testers execute BOTH sets of tests at the same time (e.g., before developers start fixing any defects that are uncovered by testers executing either set of tests)
  4. Document the following:
    • How long did it take to execute each set of tests?
    • How many unique defects were identified by each set of tests?
    • How long did it take to create and document each set of tests?*

*This third measurement was usually an estimate because a significant number of teams had not tracked the amount of time it took to create the original set of tests.

The results in 17 different pairwise testing "bake-off" projects conducted at my old firm included:

  • Defects found per tester hour during test execution: when pairwise tests were used, more than twice as many defects were found per tester hour
  • Total defects found: pairwise tests as many or more defects in every single project (despite the fact that in almost every case there were significantly more tests in the each original set of tests)
  • Defects found by pairwise tests but missed by traditional tests: a lot (I forget the exact number)
  • Defects found by traditional tests but missed by pairwise tests: zero
  • Amount of time to select and document tests: much less time required when a pairwise test generator was used (As mentioned above, precise measurements were difficult to gather here)

More recent project benefits have included these:

Fewer Tests in Pairwise Testing Case Study

More Coverage in Pairwise Testing Case Study

Those experiences - combined with the realization that many Fortune 500 firms were starting to try to implement smarter test design methods to achieve these kinds of benefits but were struggling to find a test design tool that was user-friendly and would integrate into their other tools - led me to the decision to create Hexawise.


Since creating Hexawise, I've worked with executives at companies around the world who have found themselves in the precise situation you're in, namely:

I went from "pairwise testing is a nice method in theory, but not applicable in our case" to "pairwise is nice in theory and might be applicable in our case" to finally "pairwise is applicable in our case!".

I have already elaborated some test plans that would save us up to 50% effort with that method. But now my boss and other colleagues are asking me for a proof that these pairwise testcases suffice to make sure our software is running well.

My advice is three-fold:

First, appreciate how your own thinking has evolved and understand that other people will need to follow a similar journey (and that others won't have as much time to devote as you have had to experience learnings first-hand). When I was creating Hexawise, George Box, a Design of Experiments expert with decades of experience explaining to skeptical executives how Design of Experiments could deliver transformational improvements to their organizations' efficiency and effectiveness, told me "Justin, you'll experience three phases of acceptance and acceptance will happen more gradually than you would expect it to happen. First, people will tell you 'It won't work.' Next, they'll say "It won't work HERE." Eventually, he said with a smile, they'll tell you 'Of course this works. I thought of it first!' Your own starting point began with an assumption that "it is nice in theory but not applicable to what I'm doing." When people hear that you can double their test execution productivity with a new approach, they won't initially believe you. They'll be skeptical. Most people you're explaining this approach to will start where you did. It will take some time and experience for people to understand and appreciate how dramatic the benefits are.

Second, people will instinctively be dismissive of pairwise testing case study after case study after case study that show how effective this approach has been for testers in virtually all types of industries and all types and phases of testing. George Box was right when he predicted that people will often respond with 'It won't work HERE.' Sometimes it is hard not to smile when people take that position. Case in point: I will be talking to a senior executive at a large capital markets firm soon about how our tool can help them transform the efficiency and effectiveness of their testing group. And I can introduce them to a client of ours that is using our test design tool extensively in every single one of their most important IT projects. Will that executive take me up on my offer? I hope so, but based on past experience, I suspect odds are good that he'll instead react with 'Yes, yes, sure, if companies were people, that company would be our company's identical twin, but still... It won't work HERE.'

Third At the end of the day, the most effective approach I have found to address that understandable skepticism and to secure organizational-level buy-in and commitment is through gathering hard, indisputable evidence on multiple projects that the approach works at the company itself through a bake-off approach (e.g., following those four steps outlined above. A few words of advice though.

  • My proposed approach isn't for the faint of heart. If you're working at a large company with established approaches, you'll need patience and persistence.
  • Even after you gather evidence that this approach works in Business Unit A, and B and C, someone from Business Unit D will be unconvinced with the compelling and irrefutable evidence you have gathered and tell you 'It won't work HERE. Business Unit D is unique.' The same objections may likely arise with results from "Type of Testing" A, B, and C.
  • As powerful and widely-applicable as this test design approach is, always remember (and be clear with stakeholders) that it is not a magical silver bullet. James Bach raises several valid limitations with using this approach. In particular, this approach won't work unless you have testers who have relatively strong analytical skills driving the test design process. Since pairwise test case generating tools are dependent upon thoughtful test designers to identify appropriate test inputs to vary, this approach (like all test design approaches) is subject to a "garbage in / garbage out" risk.
  • Project leads will resist "duplicating effort." But unless you do an actual bake-off stakeholders won't appreciate how broken their existing process is. There's inevitably far more wasteful repetition hidden away in standard tests than people realize. When you start reporting a doubling of tester productivity on several projects, smart managers will take notice and want to get involved. At that point - hopefully - your perseverance should be rewarded.
  • My experience has been that in order for skeptics to really believe the benefits it is often necessary for them to see the benefits measured first-hand on an application they are familiar with using an evaluation approach that produces unequivocal evidence. That's why I strongly recommend the bake-off approach. If stakeholders refuse to do a bake-off, I would keep on encouraging them to do one because the benefits are likely to be (a) dramatic and (b) unequivocal. If your urgings ultimately fail, you can ask this simple question that gets to the heart of the matter: of the last 20 defects that were missed, how many of them would have been found through pairwise tests? Specifically, if a defect could ONLY be triggered by 3 or more specific inputs together, you could assume - for the purposes of being overly conservative - that it would not have been caught by pairwise tests even though, again, that is an overly-conservative assumption because of the reasons explained here. If a defect would have been triggered by 2 specific inputs tested together, there is a strong argument to be made that the defect would have been found with your pairwise tests PROVIDED THAT testers would have thought to include both of those test inputs in your test plan. (This is a similar analysis to the approach suggested by user246 but slightly different; this approach focuses on the increase in thoroughness that sets of pairwise tests create. The evidence I've repeatedly seen shows that pairwise tests are not only AS thorough as longer sets of manually-selected tests; they are consistently MORE thorough).

Some benefits data and case studies that you might find useful:


Lastly, remember that your new-found skills are in high demand whether or not they're valued at your current company. And know that, despite your best efforts and intentions, your efforts might not convince skeptics. Some people inevitably won't be willing to take the time to understand. If you find yourself in a situation where you want to use this test design approach (because you know that these approaches are powerful, practical, and widely-applicable) but that you don't have management buy-in, then consider whether or not it would be worth leaving your current employer to join a company that will let you use your new-found skills.

Most of our clients, for example, are actively looking for software test designers with well developed pairwise and combinatorial test design skills. And they're even willing to pay a salary premium for highly analytical test designers who are able to design sets of powerful tests. (We publicize such job openings in the LinkedIn Hexawise Guru group for testers who have achieved "Guru" level status in the self-paced computer-based-training modules in the tool).

On a related note, you might find the sqa.stackexchange question about "Systematic Approaches to Selection of Test Data" to be of interest.

  • 1
    Incredible, priceless piece of advice and practical experience! Would give +100 for that.
    – Peter L.
    Commented Nov 23, 2013 at 10:21

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 make testing go even 50% faster
  • pairwise will still find most (or all) of the bugs

The first point is not a universal truth but I believe it's usually true.

If you need help on the second point, you might try the following experiment. Create a pairwise test plan, write it down somewhere, and stick in a drawer. Now run through your exhaustive test plan, or whatever test strategy your boss and colleagues can agree on. Every time you find a bug, record the value of all the relevant variables, i.e. all the variables that appeared in your pairwise test plan. When the testing is over, pull the pairwise plan out of the drawer and check which of the bugs you would have found.

You may need to repeat the experiment over multiple test efforts because you will have any compelling results.

You seem enthusiastic about pairwise (as I was when I first learned about it). Here is a thing to remember about your experimental process. Every pairwise test plan also includes some 3-way combinations too -- just not every 3-way combination. If you find a bug requires a 3-way combination that your pairwise test plan did not cover, you may be tempted to generate a different pairwise test plan that does cover it. Resist that urge; it's cheating, and it will compromise your results.

  • thanks for your response. I like the experminet you suggested and so i asked a developer to manipulate some softwarecode in order to get some information about the errors that would be detected by pairwise. This might take some time so hang on, ill post the results.
    – Robert.Sie
    Commented Nov 25, 2013 at 6:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.