So what is the starting point of black box testing? Black
box testing start from a description of the software or as we
call it, a functional specification. And the final result of black
box testing is a set of test cases, a set of actual
inputs and corresponding outputs that we can use to exercise our
code and to try to find defects in our code. So the
question is, how do we get from functional specification to test
cases? Doing these derivations, so going from this description to a concrete
set of tests, is a very complex analytical process.
And normally brute force generation is not a good
idea because it's inefficient and ineffective. What we want
to do instead is to have a systematic approach to
derive test cases from a functional specification. What a
systematic approach does is to simplify the overall problem by
dividing the process into elementary steps. In particular, in
this case, we will perform three main steps. The first
step is to identify independently testable features. Individual features in
the soft hood that we can test. And we're going to
expand on each one of these steps in the next
part of the lesson. The following step is once we have
these independently testable features to identify what are the relevant
inputs. So what are the inputs or the behavior that is
worth testing for these features. Next once we have these
inputs, we're going to derive test
specifications. And test case specifications are
description of the test cases that we can then use
to generate actual test cases. And proceeding in this way,
by this steps, has many advantages. It allows for the
coupling different activities. It allows for dividing brain intensive steps from
steps that can be automated, which is a great advantage.
And also we will see, it allows you for monitoring
the testing process. So to figure out whether your testing
process is going as expected, for example, if you're generating too
many test cases. Or you're generating the number of test cases that your
amount of resources available allows you to run. So let's start by looking
at the first step of this process in which our goal is to
go from a Functional Specification to a set of features that we can
test in the software. So what we want to do is to identify all
of the feature of the software. And why do we want to do this?
Well you know, in the spirit of breaking down the complexity of the
problem, it does not make sense to just try to devise test cases for
all the features of the software at once. For any non-trivial
software, that's a humongous problem, and something that we cannot really
handle effectively. A much better way is to identify independently testable
features and consider one of them at a time when generating tests.