Page 269 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 13: Testing

3. ………………….are often viewed as a single document commemorating the end of a life Notes
cycle phase.
( a) Criteria (b) Exit criteria
( c) Entry criteria (d) Entry and exit criteria
4. Which type of output from test includes:

( a) Test plan (b) Design document
( c) Turnover document (d) Change control
5. Exit criteria are not defined as the specific conditions or ongoing activities that must be
present before a life cycle phase can be considered complete.
( a) True (b) False

13.4 Black Box Testing

The black box approach is a testing method in which test data are resulting from the specified
useful requirements without regard to the final program structure. It is also termed data driven;
Input/Output driven or requirements based testing. Because only the functionality of the
software module is of concern, black box testing also mainly refers to functional testing method
emphasized on executing the functions and examination of their Input and Output data. The
tester treats the software under test as a black box only the inputs, outputs and specification are
visible, and the functionality is determined by observing the outputs to corresponding inputs.
In testing, various inputs are exercised and the outputs are compared against specification to
validate the correctness. All test cases are derived from the specification. No implementation
details of the code are considered.
It is understandable that the more we have covered in the input space, the more problems we
will find and therefore we will be more confident about the quality of the software. Ideally
we would be tempted to exhaustively test the input space. But as stated above, exhaustively
testing the combinations of valid inputs will be impossible for most of the programs, let alone
considering invalid inputs, timing, sequence, and resource variables. Combinatorial explosion is
the major roadblock in functional testing. To make things worse, we can never be sure whether
the specification is either correct or complete. Due to limitations of the language used in the
specifications (usually natural language), ambiguity is often inevitable. Even if we use some
type of formal or restricted language, we may still fail to write down all the possible cases in
the specification. Sometimes, the specification itself becomes an intractable problem, it is not
possible to specify precisely every situation that can be encountered using limited words. And
people can seldom specify clearly, they usually can tell whether a prototype is, or is not, what
they want after they have been finished operating system like Windows, a website like Google,
a database like Oracle or even our custom application. Under Black Box Testing, we can test
these applications by just focusing on the inputs and outputs without knowing their internal
code implementation.
13.4.1 Black Box Testing Steps

Initially requirements and specifications of the system are examined. Tester chooses valid
inputs to check whether SUT processes them properly. Also some invalid inputs (negative test
scenario) are chosen to verify that the SUT is able to detect them. Tester determines expected
outputs for all those inputs. Software tester constructs test cases with the selected inputs. The
test cases are executed. Software tester compares the actual outputs with the expected outputs.
Defects if any are fixed and re tested.

LOVELY PROFESSIONAL UNIVERSITY 263