Program Debugging and Testing

The program debugging and testing phase of the PDLC involves testing the program
to
ensure is it correct and works as intended. It starts with debuggingthe process of
ensuring
that a program is free of errors, or bugs (for a look at the origin of the term bug, see
the
Inside the Industry box). Debugging is usually a lengthy process, sometimes
amounting to
more than 50% of a programs development time. The more careful you are when
you are
designing a program, testing the logic of the programs design, and writing the
actual code,
then the less time you will typically need to debug the program.
Translating Coded Programs into Executable Code
Before a program can be runand, therefore, before it can be debuggedit needs
to be translated from the source code that a programmer writes into object code
(a binary or machine language version of the program) that the computer can
execute.
Code is converted from source code to object code using a language translator.
Typically,
a programming application program includes the appropriate language translator so
the program can be coded, translated, and executed using the same software
program. The three most common types of language translators are discussed next.
Compilers
A compiler is designed for a specific programming language (such as Java or
Python) and translates programs written in that language into machine language so
they can be executed. For instance, a program written in the Java programming
language needs a Java compiler; Java source code cannot be converted into object
code using a Python compiler. A typical compiling process is shown in Figure 13-11.
First, the source code for a program is translated into object code (the compile
stage), then it is combined with any other modules of object code (either previously
written by the programmer or stored in a common library) that the computer needs
in order to run the program (the link-edit stage). This produces an executable
program called a load module, which typically has an .exe file extension. At this
point, the compiling process has reached the Go (execution) stage and the
executable load module can be executed, as well as retained for later use.
Interpreters
Interpreters are also language-specific, but they translate source code differently
than compilers. Rather than creating object code and an executable program, an
interpreter reads, translates, and executes the source code one line at a time as the
program is run, every time the program is run. One advantage of using interpreters
is that they are relatively easy to use and they help programmers discover program
errors more easily because the execution usually stops at the point where an error

is encountered. Consequently, interpreters are useful for beginning programmers.

The major disadvantage associated with interpreters is that they work less
efficiently than compilers do because they translate each program statement into
machine language just before executing it each time the program is run. As a result,
interpreted programs run more slowly. This is especially true when the program
must repeatedly execute the same statements thousands of times, reinterpreting
each one every time. In contrast, a compiler translates each program statement
only oncewhen the object code is created. Compiled programs need to be
recompiled only when the source code is modified, such as if an error is discovered
and corrected, or the program is updated.
Assemblers
The third type of language translator, an assembler, converts assembly language
statements
into machine language. Assembly language, discussed later in this chapter, is used
almost
exclusively by professional programmers to write efficient code and is associated
with a
specific computer architecture, such as specific Windows computers, specific
Macintosh computers, a particular type of mainframe, a specific supercomputer, or
a specific type
of mobile device. An assembler works like a compiler, producing object code.
However,
instead of being associated with a specific programming language, it is used with a
specific
assembly language and, consequently, with a specific computer architecture.

Preliminary Debugging
The debugging process begins after the source code is complete and it is ready to
be compiled
or interpreted. With most programs, compiling or interpreting a program for the first
time will result in errorsthe preliminary debugging process consists of locating and
correcting
these errors. The first goal is to eliminate syntax errors and other errors that
prevent
the program from executing; then, any run time errors or logic errors can be
identified and
corrected, as discussed next.
Compiler and Syntax Errors
Errors that occur as the program is being interpreted or compiled (often called
compiler errors since most programs are compiled) prevent the program from
running and so need to be corrected before the logic of the program can be tested.
These errors
are typically syntax errors, which occur when the programmer has not followed the
proper syntax (rules) of the programming language being used. For example, a

computer is not able to understand what you are trying to do if you misspell PRINT
as PRNT, if you type END OF IF STATEMENT instead of the correct phrase END IF, if
you put a required comma or semicolon in the wrong place, or if you try to use the
wrong property with an object. As shown in Figure 13-12, when the program is being
compiled and a syntax error is reached, an error message is typically displayed.
Often this error message indicates the approximate location of the error in the
program code (such as by underlining the error with a blue wavy line as in Figure
13-12) to help the programmer locate and correct it.
Run Time and Logic Errors
Run time errors are errors that occur while the program is running and,
consequently, are noticed after all syntax errors are corrected and the program can
be executed. Sometimes run time errors occur because the program tries to do
something that isnt possible, such as dividing a numeric value by zero. With this
type of error, the program typically stops executing and an error message is
displayed. However, many run time errors are due to logic errors; that is, errors in
the logic of the program. Programs containing logic errors typically runthey just
produce incorrect results. For instance, logic errors occur when a formula is written
incorrectly, when a mistake is made with a decision condition (such as using the
wrong relational operator or initializing a counter variable to the wrong value), or
when the wrong variable name is used. After a logic error is identified, the
programmer corrects it and runs the program again to see if all errors have been
removed. This execute, check, and correct process is repeated until the program
is free of bugs. If a logic error is serious enough, it may involve going back to the
program design phasea costly mistake that emphasizes the importance of good
program design. Most logic errors should be located and corrected during the
program design stage if a good desk check procedure is used. However, when logic
errors become apparent during preliminary debugging, dummy print statements
print statements that are temporarily inserted into the codecan be used to help
locate the error. Dummy print statements can be inserted at various locations within
the programs code to show how a program is branching (such as printing the text
Inside loop, counter = followed by the current value of the Counter variable) and
to output the values of key variables at specific places in the program. Knowing the
values of key variables and where program control is branching can help the
programmer figure out what the logic error is and where it is located. For example,
running a program to add two numbers based on the logic in the incorrect flowchart
in Figure 13-9 would result in an incorrect sum, since only one number is input
before the loop terminates. As shown in Figure 13-13, dummy print statements used
to show the program control and the values of the counter and sum variables at
specific locations in the program reveal that only one number is being input when
the program runs; this information can help the programmer determine more
quickly that the counter is incorrectly being initialized to 1, instead of to 0.
Testing
At the end of the preliminary debugging process, the program will appear to be
correct. At this time, the original programmeror, preferably, someone elseruns
the program with extensive test data to try to find any additional errors remaining in

the program. Good test data should be the same type of data that will be used with
the finished program to subject the program to the conditions it will encounter when
it is implemented. Ideally, the test data would be actual data, but to protect the
privacy of personal information during testing, test data is usually created that has
the same structure as actual data but does not contain any personally identifiable
information. The test data should also check for nonstandard situations or possible
input errors to make sure the proper corresponding actions are included in the
program. For example, will the program issue a check if the amount is $0.00 or will
it allow a product quantity of less than 0? Although rigorous testing significantly
decreases the chance of an unnoticed error revealing itself after the program is
implemented, there is no foolproof guarantee that the completed program will be
bug free. However, proper debugging and testing is vital because an error that costs
only a few dollars to fix at this stage in the development process may cost many
thousands of dollars to correct after the program is implemented. Programs created
for mass distribution often have two stages of testing: an internal on-site test
(sometimes called an alpha test) and one or more rounds of outside tests (called
beta tests). For instance, companies creating new versions of commercial software
programs, such as when Microsoft develops a new version of Microsoft Office, enlist
a large number of beta testers to test the versions for bugs and compatibility
problems, as well as to provide suggestions for improvement, while the programs
are in development. Beta versions of freeware and open source software are also
often available to the public for testing. Beta testing allows the programs to be
tested by a wide variety of individuals using a wide variety of hardwarea much
more thorough test than just alpha testing for programs that are to be distributed
out of house.
Documentation: Completed Program Package
When the program debugging and testing phase is finished, a copy of the test data,
test results, finished program code, and other documentation generated during this
phase should be added to the program package. The test data is useful for future
program modifications, as well as to see under what conditions the program was
tested if a problem develops in the future. So far, virtually all the documents in the
collected program documentation could be referred to as developer documentation
tools that may be useful when a programmer needs to look at or modify the
program code in the future. To finish the program package, the necessary user
documentation should also be developed. User documentation normally consists of
a users manual containing instructions for running the program, a description of
software commands, and so forth. It can be integrated into the program itself (such
as via a Help feature); it can also be external user documentation that is used for
training and reference purposes, particularly for new systems.
Program Implementation and Maintenance
Once a program has finished the debugging and testing phase, it is ready to be
implemented
as part of the SDLC, as discussed in Chapter 12. Once the system containing
the program is up and running, the implementation process of the program

implementation and maintenance phase is complete. However, virtually every

program
requires ongoing maintenance. Program maintenance is the process of updating
software
so it continues to be useful. For instance, if new types of data are added to a
company
database, program maintenance is necessary so that existing programs can use the
new
data. Software revisions, new equipment announcements, new legislative
mandates, and
changes in the way business is conducted also commonly trigger program
maintenance.
Program maintenance is costly to organizations. It has been estimated that many
organizations spend well over one-halfsome estimates put it closer to 80%of
their
programming time maintaining existing application programs.