Download as pdf or txt
Download as pdf or txt
You are on page 1of 2

Computer Science

Teacher: Maruf Ahmed


Program testing, types of program error, test data and trace table

Program testing:
Software may not perform as expected for a number of reasons such as the programmer has made a
coding mistake, the requirement specification was not drawn up correctly, software designer has made a
design error or the user interfaces were poorly designed and the user makes mistakes etc. Computer
hardware may experience failure also. However the errors are found the end user might report an error.
This is not good for the reputation of the software developer or the software house. Testing software
before it is released for general uses is essential. Research has shown that the earlier an error can be
found the cheaper it is to fix it. It is very important that the software is tested throughout the
development. The purpose of testing is to discover errors and get rid of the errors.

Types of program error: There are three types of errors that can occur in a program.
1. Syntax error: This occurs when a program does not follow the rules or grammar of a
programming language. The program will not run if there is any syntax error. The compiler or
interpreter will find them for you and usually gives you a hint as to what is wrong. Depending
your development editor (IDE), some syntax error may be flagged up by your editor. This is not
difficult to find out as the IDE can detect errors.
2. Logic error: Logic errors occur when the program gives output but not as expected. These are the
errors in the design of the solution meaning the program does not do what it is supposed to do.
These errors are usually found when the program is being tested. Trace table is a good way to find
the logic errors.
3. Run time error: It occurs when the program performs an illegal instruction / invalid operation.
When the program executes and a run time error occurs, it gets into unexpected halts or crash or it
goes into an infinite loop and the program freezes. If a program has already been released and run
time error occurs then the developers should be informed so that the program can be updated and
re-release and a patch can be sent out to all customers to solve the problem. A patch is a small
program released by the developer to run within existing program to correct an error or provide
extra functionality.

Test data: carefully chosen values that will test a program if it is correctly working or not. In order to
determine whether a solution is working as it should, it needs to be tested and for that we use different
types of test data. There are mainly 4 types of test data. They are:
1. Normal data: The program accepts the data as these are within the range or meets the criteria
2. Abnormal data / Erroneous data: The program does not accept the data as these are outside the
range or does not meet the criteria. They should be rejected and an error message should be
displayed.
3. Extreme data: The program accepts the data as these are within the range or meets the criteria.
This is used to test the limit of acceptability. Extreme data is the largest/smallest acceptable value
of a range.
4. Boundary data: This is used to establish where the largest and the smallest values occur. At each
boundary two values are required. One value is accepted and the other value is rejected. Boundary
data is the largest/smallest acceptable value and the corresponding smallest/largest rejected value.
We will take a scenario where a subject mark will be entered in the range from 0 to 100 inclusive and in
whole numbers only and we will identify different types of test data from the range.
Normal data: 20, 50, 70 etc.
Reason to use the data: To check whether the value is accepted by the system. It should be accepted as
it is within the acceptable range. Program should work as expected and give the desired result
Abnormal data / Erroneous data:
Example test data: 200, abc, -20, 72.5 etc.
Reason to use the data: To check if it is rejected or not by the system. It should be rejected as it is
outside the range or does not meet the criteria. An error message should be displayed mentioning the
reason for rejecting.
Extreme data:
Example test data: 0, 100 (only these two values can be extreme data in this scenario)
Reason to use the data: To check the limit of acceptability at the lower end and at the higher end. The
values should be accepted as both are valid values.
Boundary data:
Example test data: (0,-1) or (100,101)
Reason to use the data: To check if the lowest value of the extreme data as well as the value
immediately before that is accepted or not. This also checks if the highest value of the extreme data as
well as the value immediately after that is accepted or not.
A pair of values needs to be checked on either side. Smallest acceptable value is 0 which should be
accepted whereas largest rejected value is -1 which should be rejected. On the other end 100 is the largest
acceptable value which should be accepted and 101 is the smallest rejected value which should be
rejected by the system.

Dry run: A dry run is the process of a program to manually work through the code to trace the value of
variables. There is no software involved in this process. Dry running is done to:
 Find the output for a given set of data to test if the program gives expected result
 Check the logic of the program
 Find out what a given algorithm has been designed to do
A dry run is normally done by a technique known as trace table. This shows how the variables in the
program change at each stage. There are many advantages in doing this rather than just mentally work
through the problem. The table will have column headed with the names of the variables in the program
and normally one column for the output. The entries of each row in the table will be values of the
variables after the execution of the statement on that line. In this table you can record all relevant changes
to the variables as the program progresses, thereby test the logic of the program/algorithm. Do a dry run
before you code your program on computer and this way any logic errors will come to light during the
dry run.

You might also like