Unit 7 – Software Engineering

7.9 Testing & Documentation

1
Unit Testing
The lowest level, unit testing involves testing each module of
a program in isolation. Unit test is the most micro scale of
testing that is testing of the function of a component typically
is done by the programmer and not by tasters, as it requires
detailed knowledge of the internal program design and code

2
Black Box Testing
In this approach the program is assumed to be a black box where the processing logic unit
cannot be seen. This means that what is happening inside the program is not important to the
person who is carrying out the testing. The tester is worried about the output that the program
producers Therefore, the aim of testing is to check whether the program producers the correct
output for every single input.

Test data are selected based on the program specification and not based on the logic of the
program. Therefore, some of the logical pathway may be missed with the chosen test data.

3
White Box Testing
Here the program is assumed to be a transparent box where the logic in it is seen by the
tester, that means the processing logic is considered important in this method there for
testing is carried out to check whether the inputs are driven correctly by the logic and as a
result correct outputs are obtained
Test data are selected based on the logic. or the program to test each and every possible
logical pathway.

4
System Testing

In a working environment, a data processing application may involve anything between a

handful hundreds of programs, all of which must interact to provide a service to the user.

Testing in such an environment involves not only testing each individual program but also
testing the flow of data through the system as a whole.

Essentially this is only a larger version of the procedure used in testing a single program
because we are still testing a number of modules (in this case each is a program), the
sequence in which they operate and the communication of data between them.

5
Test Plan
It is important that any test must be fully described before they are carried out. Anyone carrying
out a test without describing the expected outcome is not testing but experimenting.
The description should include:

 The identity of the component to be tested

 The purpose of the test (which function of the component to be tested)

 The conditions under which the test is to be carried out.

 Test data to be used.

 The expected outcome (new values of global variable, new file status etc.)

6
Documentation

 All Programs should be adequately documented to facilitate the usage & the
future maintenance of the Program.

 There are 2 main categories of people who are interested in program

documentation:

 Programmers

 Users

7
Documentation for Programmers

 The documentation required to enable a programmer to maintain a program

over its life, may be divided into two categories.

 Internal Documentation

 External Documentation

8
Documentation - Programmers

Internal Documentation

This covers the aspects of programs which are embodied

in the syntax of the programming. These include

 Meaningful names used to describe data items and procedures;

 Comments relating to the function of the program as a whole and of the modules comprising
the program;
 Clarity of style and format—one instruction per line, indentation of related groups of
instructions, blank lines separating modules: and
 Use of symbolic names instead of constants or literals in the procedural code.

9
Documentation - Programmers
External Documentation

 A current listing of the source program—the program as written by the programmer,

including any memory maps, cross-references! and so on, that are able to be obtained from
the compilation process
 The program specification -the document defining the purpose and mode of operation of
the program
 An explanation of any formulae or complex calculations in the program
 A specification of the data being processed—data accepted from or displayed on a screen,
items in reports. External files processed. including the format of record structures and fields
within those records; all data being described in terms of its size, format, type and structure

10
Documentation for Users
As in the case of operators, users are concerned more
with more they interact with the program what the
program does for them than with the technicalities of how
the program goes about its tasks

All programs or collections of programs comprising a

composite system should have a manual. This document
follows more or less the same path as that of the
operating instruction except that the user will not normally
be as concerned with equipment technicalities as will the
operator.

11
Documentation for Users
The user’s manual should cover:

 Detailed description of the function performed by the program;

 The means by which the user supplies data to the program to be processed. covering format
and content of the date together with any restrictions on values included, and so on:
 A detailed description. preferably with examples, of any output produced by the program for
the user;
 Details of any error messages or exception reports which the program may produce
explaining precisely their impact on the users arid any subsequent action required on their
part;
 Details of any options to be exercised by the user, including the implications of each option
and the means of selecting each option

12
Lesson Summary

 Unit Testing
 Black box vs White box Testing
 System Testing
 Test Plan
 Documentation for Programmers
 Documentation for Users

13