SCS 3209

Software Engineering
Software Coding, testing and
debugging
Orwa, Dec 2024
 So far
• Software engineering
– What
– Why
• Software engineering models
– Variations
• Requirements elicitation
– Problem statement
– Process
– Outcome
• Software design
 Learning Outcomes

• By the end of this lecture, the learner should be able

to:

– Describe coding and coding standards

– Carry out code testing, reviews and code debugging
 Coding, testing and debugging

• What is:
– Coding standards?
– Coding?
– Code Testing?
– Code debugging?
 Introduction: Coding standards
• A coding standard
– is a set of programming styles and practices to which a group of
people adhere, in the belief that such adherence contributes the
overall effectiveness in producing high quality code that is
understandable and maintainable

• Most organizations have their own coding standards or

"style guide" for how code should be written for ease of
reading and maintenance.
 Why Coding Stds and Guidelines
• A coding standard lists several rules to be followed
during coding, such as the way variables are to be
named, the way the code is to be laid out, error
handling etc.
Why Coding Standards and Guidelines
• Despite code being written for compilers/
translators etc. to perform the functionality
desired,

• it is also written for human beings both present

and future authors of the software
 Why Coding Stds and Guidelines
• The purpose of adhering to a standard style of coding is:
– A coding standard gives a uniform appearance to the codes
written by different engineers.

– eases code understanding ( ease of reading)

– eases code maintenance

– encourages good programming practices

– Improves reliability
 Why Coding Stds and Guidelines
• Many bugs can be prevented by coding in a simple,
clear, and consistent style
• that follows idioms and patterns that experienced
programmers have developed.

• Increase the productivity of individual programmers

• are less likely to have easily identifiable bugs and will
actually spend less time developing and debugging their
code.
 Coding Standards
• Several hierarchies for standards
– Organizational Level Standards is a general coding
standard adopted by a specific organization and expected
to be used by all S/W engineers in the organization

– Language Specific Standards – each programming

language has its own set of standards .

– Project Level Standards – should supplement the other

two and purpose is to so enhance code reuse from one
project to another with minimal change.
Coding Standards
 Typical Issues in Coding Stds
• Naming of Routines, Variables, Tables etc
– one of the most influential aids to understanding the logical flow of an
application is how the various elements of the application are named.
– Desirable to have a name tell "what" rather than "how.“
– By avoiding names that expose the underlying implementation, which can
change, you preserve a layer of abstraction that simplifies the complexity
– Make names long enough to be meaningful but short enough to avoid being
wordy
 Typical Issues
• Comments
– Form part of the internal documentation
– comments that developers write within the source code at
development time
– challenges of software documentation is ensuring that the comments
are maintained and updated in parallel with the source code.
– Although properly commenting source code serves no purpose at run
time, it is invaluable to a developer who must maintain a particularly
intricate or cumbersome piece of software.
 Typical Issues
• Contents of module and subroutine headers e.g.
– Name of the module.
– Date on which the module was created.
– Author’s name.
– Modification history.
– Synopsis of the module.
– Different functions supported, along with their
input/output parameters.
– Global variables accessed/modified by the module.
 Typical Issues
• File Organization e.g. In very large projects
producing many files, e.g.
– What kind of Include file organization is appropriate for the
projects data hierarchy
– Directory structure
– Location of Make Files

• Revision and Version Control:

• configuration of archives, projects,
• revision numbering, and release guidelines.
 Typical Issues
• Specifications for Error Handling:

• The way error conditions are reported by different

functions in a program are handled should be standard

– specifications for detecting and handling of errors

– specifications for checking boundary conditions for
parameters passed to subroutines
Specifications for Error Handling
 Typical Issues
• Code Layout e.g. some standards may include
guidelines such as
– One statement per line
– Use of Indentation- A consistent use of indentation
makes code more readable and errors easier to detect.
– Use of Brackets, Begin...End, and Delimiting Control
Blocks
 Typical Issues: CASE Tools
• Some Code Cleaning tools available to assist in
writing e.g. Artistic Style- formatter for C, C++, C#,
and Java Source Code
 Code Review
Why Code review ?

• Serves to uncover coding errors once a module is

successfully compiled and the all the syntax errors have been
eliminated.

• Cost-effective strategies for reduction in coding errors and to

produce high quality code.
 Code Review

• Two types of Code reviews

– Formal Reviews and

– informal ( walkthroughs & peer reviews)

 Code Review
• Formal review are part of the SQA process and is a structured
process

• Informal review is an activity or process in which software developers

review each other’s code before releasing software to QA –
– identifies defects (bugs) as early as possible,
– encourages collaboration,
– helps developers create better products,
– and keeps code more maintainable

• Informal review is evidently a collaborative practice, involving critical

evaluation on the software products peers created before integrating
them into the system.
 Code Review
• Code is reviewed for the following:
– Clarity and Readability - as in accordance to the coding
standards.
– Requirements Met - code does what it is supposed to
do.
– Performance - code is coded to prevent performance
problems
– Algorithms and Error Situations - algorithm used is
sound, error conditions handled, all reasonable
conditions are handled
 Code Review
• Peer reviews:
– An informal small group of programmers and/or testers act as
reviewers.
– Participants should follow the 4 essential elements even
through the review is informal.

• Walkthroughs:
– A more formal process in which the author of the code formally
presents the code to a small group of programmers and/or
testers.
– The author reads the code line by line explaining what it does,
reviewers listen and ask questions.
– Participants should follow the 4 essential elements.
 Code Review
• Code Walk Through
– an informal code analysis technique and used mostly by
the development team => developer technique

– Used by the development team to improve on the quality

of product by focusing on finding defects

– Can be done by a minimum two developers ( the author

of the code and the reviewer)
 Code Review
• Typical Code Walk Through Process
– A few members of the development team are given the code
few days before the walk through meeting to read and
understand code.
– Each member selects some test cases and simulates
execution of the code by hand (i.e. trace execution through
each statement and function execution).
– The main objectives of the walk through are to discover the
algorithmic and logical errors in the code.
– The members note down their findings to discuss these in a
walk through meeting where the coder of the module is
present.
 Code Review
• A formal Review implies

– scheduled meetings, prepared participants, defined

agenda, specific format, documented output
 Formal Review
• Code Inspection is
– a process management tool (always formal)
– used to improve quality of the development
process
– collect defect data to analyze the quality of the
process
– written output is important
– major role in training junior staff and transferring
expertise
 Code review
Essential elements of a formal code review are :

• Identify problems:
– Find problems with the software such as missing items, mistakes,
etc.
• Follow rules:
– Amount of code to be reviewed, how much time will be spent, etc.
• Prepare:
– Each participant should prepare in order to contribute to the review.
• Write a report:
– Summarize the results of the review, make report available to the
development team.
 Code Review

Participants of the code inspection process

• Code presenter is not the author of the code.

• The other participants are the inspectors.

• There is a moderator to assure that the rules are

followed and the meeting runs smoothly.
 Code Review
Fagan inspection essentially consists of a five step process:
• Overview: the author presents an overview of the scope and
purpose of the work product.
• Preparation: reviewers analyze the work product with the goal
of understanding it thoroughly. This is done individually
• Inspection meeting: the inspection team assembles and the
reader paraphrases the work product.
– Reviewers raise issues that are subsequently recorded by
the scribe.
– Key is to identify problems and not solve the problems
 Code Review
• Rework: the author revises the work product based
on the agreed reviewed errors/problems

• Follow up: The moderator verifies the quality of

rework after author rectifies errors/problems and
decides if re-inspection is required.
 Code Review Checklist

• A list of possible items the team reviewing should look out

for.

• Most organizations will have developed a checklist based

on their experience, knowledge, expertise etc
 Code Review Checklist
• Typical issues that are found in a check list include:

– Data reference errors, e.g. Is an un-initialized variable

referenced?

– Data declaration errors, e.g. Are the variables assigned the

correct length, type, storage class?

– Computation errors , e.g Do any calculations that use variables

have different data types?
 Code Review Checklist
• Comparison errors e.g. Are the comparisons correct? E.g. <
instead of <=

• Control flow errors,, e.g. Do the loops terminate as

expected?

• Subroutine parameter errors , e.g. If constants are passed

to the subroutine as arguments are they accidentally changed
in the subroutine?

• Input/Output errors , e.g. If the file or peripheral is not ready,

is that error condition handled?
 Code Testing: Basic Definitions
• Test case: specifies
– Inputs + pre-test state of the software
– Expected results (outputs an state)

• Black-box testing: ignores the internal logic of the software,

and looks at what happens at the interface (e.g., given this
inputs, was the produced output correct?)

• White-box testing: uses knowledge of the internal structure

of the software
– E.g., write tests to “cover” internal paths

36
 Code Testing
• The lowest level of testing is the Unit testing and is done by the
developer/ programmers (not by testers).

• Requires knowledge of the internal program design and code => use
of White-box testing techniques

• Also referred to as dynamic unit test as opposed to code review

which is static- no code is executed.

• Tests done on particular functions or code modules or component in

isolation from the more complete software.
 Code Testing
• Objectives of Unit Test is to
– To test internal logic
– To verify internal design
– To test path & conditions coverage
– To test exception conditions & error handling

• => use of white-box techniques

• This is the kind of testing that you as a developer use to
test your own code.
 • During a Unit Test, The environment of a
unit is emulated and tested in isolation
• The caller unit is known as test driver
– A test driver is a program that invokes the unit
under test (UUT)
– It provides input data to unit under test and
report the test result
Code Testing

• The emulation of the units called by the

UUT are called stubs
– It is a dummy program
• The test driver and the stubs are together
called scaffolding
• The low-level design document provides
guidance for selection of input test data

39
 Code Testing

Dynamic unit test environment

40
 Code Testing
• Good testing requires testing good cases
– Reduces debugging time and ensures better product

• How to Generate test cases?

– Based on the techniques adopted. White Box techniques are:
– Control flow/ Coverage testing
– Basic path testing
– Loop testing
– Data flow testing
 White-box Testing Approaches

• Sample of approaches for White-box testing

include:
– Control-flow-based testing
– Loop testing
– Data-flow-based testing

42
 Control-flow-based Testing
• A traditional form of white-box testing
• Step 1: From the source, create a graph describing the flow
of control
– Called the control flow graph
– The graph is created (extracted from the source code) manually
or automatically
• Step 2: Design test cases to cover certain elements of this
graph
– Nodes, edges, paths

43
 Example of a Control Flow Graph (CFG)

s:=0; 1
d:=0;

2
while (x<y) {
x:=x+3; 3
y:=y+2;
if (x+y < 100)
s:=s+x+y; 4
else
d:=d+x-y; 5 6
} 7

44
 Elements of a CFG
• Three kinds of nodes:
– Statement nodes: represent single-entry-single-exit sequences of
statements
– Predicate nodes: represent conditions for branching
– Auxiliary nodes: (optional) for easier understanding (e.g., “join
points” for IF, etc.)
• Edges: represents possible flow of control

• It is relatively easy to map standard constructs from

programming languages to elements of CFGs

45
 IF-THEN, IF-THEN-ELSE, SWITCH
if (c) if (c) switch (c)
then then case 1:
// join point else case 2:
// join point // join point

…
…..
… …

46
 Example
switch (position)
case CASHIER
if (empl_yrs > 5)
bonus := 1;
else
.
bonus := 0.7; .
case MANAGER .
bonus := 1.5;
.
if (retiring_soon)
bonus := 1.2 * bonus
case …
endswitch

47
 Mapping for Loops

while (c) {

}
…

Note: other loops (e.g., FOR, DO-WHILE,…) are mapped similarly.

Figure out how this is done.

48
 Code Debugging
• Debugging is the process of determining the cause of
a failure

• It is a time consuming and error-prone process

• Debugging involves a combination of systematic

evaluation, intuition and a little bit of luck
 Code Debugging
• The purpose is to isolate and determine its
specific cause, given a symptom of a problem
already identified during testing and correcting the
root cause

• Typical causes of bugs (errors, faults, defects) in

code include Typos, Syntax Errors, and Logic
Errors
 Code Debugging
• Three approaches to debugging
– Brute force
– Cause elimination
• Induction
• Deduction
– Backtracking
 Code Debugging
• Brute force category of debugging is probably the most
common and least efficient method for isolating the cause of
a software error.
• Applied when all else fails.
• Typically using a "let the computer find the error" philosophy,
e.g. memory dumps are taken, run-time traces are invoked,
and the program is loaded with WRITE statements etc.
• From information that is produced , hopefully a clue can be
found that can lead to the cause of an error.
• Although the mass of information produced may ultimately
lead to success, it more frequently leads to wasted effort and
time.
• Thought must be expended first!
 Code Debugging
• Backtracking is a fairly common debugging
approach that can be used successfully in small
programs.
• Beginning at the site where a symptom has been
uncovered, the source code is traced backward
(manually) until the site of the cause is found.
• Unfortunately, as the number of source lines
increases, the number of potential backward paths
may become unmanageably large.
 Code Debugging
• Cause elimination- manifested by induction or deduction and
introduces the concept of binary partitioning.
• Data related to the error occurrence are organized to isolate
potential causes.
• A "cause hypothesis" is devised and the aforementioned
data are used to prove or disprove the hypothesis.
• Alternatively, a list of all possible causes is developed and
tests are conducted to eliminate each.
• If initial tests indicate that a particular cause hypothesis
shows promise, data are refined in an attempt to isolate the
bug.
 Code Debugging
Step-By-Step Debugging The Scientific Method

1.Gather data through repeatable experiments

2.Form a hypothesis that accounts for the relevant data
3.Design an experiment to prove or disprove hypothesis
4.Prove or disprove hypothesis
5.Repeat As needed
 Code Debugging
Typical Debugging Process

1. Finding the defect

2. Stabilize the error
– Find test cases that produce the error
– Reproducing errors is key to finding the problem
3. Locate the source of the error
– Gather data that produces the defect (user input and/or various
conditions that lead to producing the error)
– Analyze the data that has been gathered, and form a hypothesis,
either by testing the program or by examining the code
– Prove or disprove the hypothesis
 Code Debugging
Typical Debugging Process

4. Fix the defect

5. Test the fix

6. Look for similar errors

 Code Debugging - Tips
• Finding and understanding the defect is 90% of the work.
Actually fixing it is the easy part

• First, stabilize the error. Make the defect occur at a

predictable fashion.

• Second, try to narrow down what block of code, variable,

or combination of variables cause the error.
 Code Debugging - Tips
• Fixing The Error

• Understand the problem and the program before

changing the code
• Relax and don’t rush
• Save the original source code
• Fix the problem, not the symptom
• Make one change at a time
• Test the fix thoroughly
• Look for similar defects
 Code Debugging - Tips
• The debugging approaches can be supplemented
with debugging tools.
• Debugger - program to run your program and
program to run your program and analyze its run
analyze its run-time behavior time behavior
• Debuggers can be part of your IDE or separate
programs)
• Three key concepts:
• Breakpoints
• Stepping
• Inspecting variables
 Code Debugging - Tips
• Use /apply a wide variety of debugging compilers,
dynamic debugging aids ("tracers"), automatic test case
generators, memory dumps, and cross-reference maps.

• Caution: tools are not a substitute for careful evaluation

based on a complete software design document and
clear source code.
 References
• Sommervile, Ian (2007), Software Engineering,
8th Edition , Prentice Hall, e-book
• Mc Connell ,Steve, Code Complete a
PRACTICAL Handbook of Software
Construction
• Pressman, Roger S. ,Software Engineering A
practitioners Approach, 5th Edition
• Internet