Now, let's go back to our systematic functional testing
approach and all the steps in this process. So
far we've seen the first step and the second
step. Now we're going to look at this step in which,
once we have identified the values of interest, we
derive test case specifications for these values, or using these
values. And the test case specification defines how the
values should be put together when actually testing the system.
And test case specification describe how these values should be put
together when testing the system. So let me go back one more
time to our split program, so that we can use the
information that we already computed. At this point what we have is
some possible inputs for "string," our first parameter, and for "size,"
our second parameter. And we want to put them together, to generate
the description of what the test case should be. So let
me once more rearrange this a little bit. I first remove the
description of the subdomains, because we won't use them in this step.
And I moved out the set of all our possible inputs, that we're
going to combine to create the test case specification. And one possible way
of doing that is simply to combine the values for the first parameter,
and the values for the second parameter. So the Cartesian product. So
if we do that, what we will obtain is, for example, if we
consider the first possible input, size is equal to minus 1, we can
combine it with these two possible inputs for string, and we will get
size is equal to minus 1 string with length minus 2, or
size is equal to minus 1 string with length minus 1. And we'll
go back in a second to see what this means. Now if we
consider the second possible value for size, size is equal to one, we
also have two cases so the first one in this case that will
be considered a string with length zero. So the antistring. And we can
continue combining this value, but one thing I want to point out is
that if we just go in this straight forward and brute force sort
of way, we will obtain many combinations that don't make any sense,
like for example, this combination which doesn't make any sense because we can
not create the string with length minus 2. Similar for this combination, because
then by the same token, we cannot raise things with length minus 1.
And so there's a lot of cases that we will have to eliminate
afterwards. So what we're going to see in a few minutes is a possible
way in which we can avoid producing these meaningless cases. And at the
same time, keep under control, the number of test cases that we generate.
So lets go back for the last time to our steps
for systematic functional testing. What we just did was to derive
test case specification from a set of relevant inputs. The following
step is to use these test case specifications to generate actual test
cases. And this is normally a fairly mechanical step in the
sense that we just have to instantiate what is in the test
case specification as actual test cases. And it's really dependent on
the specific type of partitions and values identified on the specific context.
So instead of looking at that here in the, in the abstract,
I'm going to show you with an example later on, in the lesson.