1
00:00:00,110 --> 00:00:02,570
So let me use a slightly expanded version of this

2
00:00:02,570 --> 00:00:05,560
grid. Although we're indeed looking at a needle in a haystack.

3
00:00:05,560 --> 00:00:09,560
And failing inputs are generally sparse, very sparse, in the input

4
00:00:09,560 --> 00:00:12,890
domain. However, they tend to be dense in some parts of

5
00:00:12,890 --> 00:00:15,860
the domain. Like here or here. So how can we leverage

6
00:00:15,860 --> 00:00:18,920
this? The fact that the failures are dense in some subdomains?

7
00:00:18,920 --> 00:00:22,290
As it turns out, the domain is naturally split into partitions.

8
00:00:22,290 --> 00:00:25,340
Where partitions are areas of the domain that are treated homogeneously

9
00:00:25,340 --> 00:00:28,070
by the software. And this is what happens, that normally,

10
00:00:28,070 --> 00:00:31,020
failures tend to be dense in this partitions. So the way

11
00:00:31,020 --> 00:00:34,000
to leverage this characteristic of failures, is that we don't know

12
00:00:34,000 --> 00:00:36,950
want to pick inputs randomly, in the input domain. Just here

13
00:00:36,950 --> 00:00:39,460
and there. Rather we want to do two things. First we

14
00:00:39,460 --> 00:00:43,300
want to identify partitions of our domain. And second we want

15
00:00:43,300 --> 00:00:46,950
to select inputs from each partition. And by doing so, we

16
00:00:46,950 --> 00:00:50,300
can dramatically increase our chances to reveal faults in the code.

17
00:00:50,300 --> 00:00:54,170
So the name that is normally used for this process, is partition testing.