Once upon a time, a young tester was wondering through the Twitter forest. He was interested in one part of that forest, part that gathered software testers. He spotted software tester @mheusser, rumbling some strange words. Apparently, one tester had to test forest feature that included 69 different trees.

OH: The number possible test cases? That’s easy. 69!
NOTE: That’s not sixty-nine excitedly, that is sixty-nine /FACTORIAL/. Yay?
i’m going to do some pairwise stuff to get that number down. If I had time, I’d do kaner/hoffman/robinson style model-driven tests.
That is, I would grab live prod data, get an answer, then try to figure out for that id, what the answer /should/ be with my own program.

A young tester only remembered strange but soundly word pairwise. A few years later, young tester took BBST Test Design course. In the last lesson of this course, he heard strange and soundly word again. After the lesson assignment, he finally understood the pairwise testing.

He also learned about the tool for pairwise testing, PICT. Another surprise was that PICT was crafted by forest habitant that he did not like so much.

As with any other tool, you have to know how to use it. PICT has to be used carefully and skilfully. Main feature of pairwise testing technique is to “cut down” number of test cases. Inexperienced tester could think that there is no any tradeoff in that process. But there is.

You have to understand test technique and tool that you are using in order to effectively test features that have explosion of test cases. Otherwise you could easily miss important test cases that were cut off by you using some of the PICT parameters and features. Use referenced links to learn to use PICT in skilful manner.