Software Engineering

Coding and Testing

Sukanya Basu

Computer Science and Engineering Department

Techno India University

July 7, 2021

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 1 / 51

Coding

• The input to the coding phase is the design document

• During coding phase
• modules identified in the design document are coded according to the module
specifications
• At the end of the design phase we have
• module structure (e.g. structure chart) of the system
• module specifications
• data structures and algorithms for each module
• Objective of coding phase
• transform design into code
• unit test the code

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 2 / 51

Coding Standards

• Good software development organizations require their programmers to

• adhere to some standard style of coding called coding standards
• Many software development organizations
• formulate their own coding standards that suits them most
• require their engineers to follow these standards rigorously
• Advantage of adhering to a standard style of coding
• it gives a uniform appearance to the codes written by different engineers
• it enhances code understanding
• encourages good programming practices

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 3 / 51

Coding Standards

• A coding standard
• sets out standard ways of doing several things
• the way variables are named
• code is laid out
• maximum number of source lines allowed per function, etc.
• Coding guidelines: Provide general suggestions regarding coding style to be
followed
• leave actual implementation of the guidelines to the discretion of the
individual engineers

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 4 / 51

Code inspection and code walk throughs

• After a module has been coded

• code inspection and code walk through are carried out
• ensures that coding standards are followed
• helps detect as many errors as possible before testing
• detected errors require less effort for correction
• much higher effort needed if errors were to be detected during integration or
system testing.

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 5 / 51

Coding Standards and Guidelines

• Good organizations often develop their own coding standards and guidelines
• depending on what best suits their organization
• We will discuss some representative coding standards and guidelines

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 6 / 51

Representative Coding Standards
• Rules for limiting the use of globals
• what types of data can be declared global and what can not
• Naming conventions for
• global variables
• local variables, and
• constant identifiers
• Contents of headers for different modules
• The headers of different modules should be standard for an organization
• The exact format for header information is usually specified
• Header data
• 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
Sukanya Basu (Techno India University) Software Engineering July 7, 2021 7 / 51
Representative Coding Standards

• Error return conventions and exception handling mechanisms

• the way error and exception conditions are handled should be standard within
an organization
• For example, when different functions encounter error conditions
• should either return a 0 or 1 consistently
• Do not use too clever and difficult to understand coding style
• Code should be easy to understand
• Clever coding can obscure meaning of the code
• hampers understanding
• makes later maintenance difficult

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 8 / 51

Representative Coding Guidelines

• Avoid obscure side effects

• Obscure side effects make it difficult to understand a piece of code
• For example
• if a global variable is changed obscurely in a called module
• it becomes difficult for anybody trying to understand the code
• Do not use an identifier (variable name) for multiple purposes
• Programmers often use the same identifier for multiple purposes
• For example, some programmers use a temporary loop variable also for storing
the final result

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 9 / 51

Representative Coding Guidelines

• Code should be well-documented

• Rules of thumb
• on the average there must be at least one comment line
• for every three source lines
• The length of any function should not exceed 10 source lines
• Lengthy functions
• usually very difficult to understand
• probably do too many different things
• Do not use goto statements
• Use of goto statements
• make a program unstructured
• make it very difficult to understand

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 10 / 51

Code Walk Through

• An informal code analysis technique

• undertaken after the coding of a module is complete
• A few members of the development team select some test cases
• simulate execution of the code by hand using these test cases
• Even though an informal technique
• several guidelines have evolved over the years
• making this naive but useful analysis technique more effective
• these guidelines are based on
• personal experience, common sense, and several subjective factors

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 11 / 51

Code Walk Through

• The guidelines should be considered as examples

• rather than accepted as rules to be applied dogmatically
• The team performing code walk through should not be either too big or too
small
• Ideally, it should consist of between three to seven members
• Discussion should focus on discovery of errors and not on how to fix the
discovered errors
• To foster cooperation
• avoid the feeling among engineers that they are being evaluated in the code
walk through meeting

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 12 / 51

Code Inspection

• In contrast to code walk throughs

• code inspection aims mainly at discovery of commonly made errors
• During code inspection
• the code is examined for the presence of certain kinds of errors
• in contrast to the hand simulation of code execution done in code walk
throughs
• For instance, consider
• classical error of writing a procedure that modifies a formal parameter
• while the calling routine calls the procedure with a constant actual parameter
• It is more likely that such an error will be discovered
• by looking for this kind of mistakes in the code
• rather than by simply hand simulating execution of the procedure

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 13 / 51

Software Documentation

• When developing a software product we develop various kinds of documents

• In addition to executable files and the source code
• users’ manual,
• software requirements specification (SRS) document,
• design document,
• test document,
• installation manual, etc
• All these documents are a vital part of good software development practice
• Internal documentation
• documentation provided in the source code itself
• External documentation
• documentation other than those present in the source code

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 14 / 51

How Do You Test a Program?

• Input test data to the program

• Observe the output
• Check if the program behaved as expected
• If the program does not behave as expected
• Note the conditions under which it failed
• Later debug and correct

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 15 / 51

Overview of Testing Activities

• Test Suite Design

• Run test cases and observe results to detect failures
• Debug to locate errors
• Correct errors

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 16 / 51

Error, Faults, and Failures

• A failure is a manifestation of an error (aka defect or bug)

• Mere presence of an error may not lead to a failure
• A fault is an incorrect state entered during program execution
• A variable value is different from what it should be
• A fault may or may not lead to a failure

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 17 / 51

Test cases and Test suites

• Test a software using a set of carefully designed test cases

• The set of all test cases is called the test suite
• A test case is a triplet [I,S,O]
• I is the data to be input to the system
• S is the state of the system at which the data will be input
• O is the expected output of the system

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 18 / 51

Verification vs. Validation

• Verification is the process of determining

• Whether output of one phase of development conforms to its previous phase
• Validation is the process of determining
• Whether a fully developed system conforms to its SRS document
• Verification is concerned with phase containment of errors
• Whereas the aim of validation is that the final product be error free

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 19 / 51

Design of Test Cases

• Exhaustive testing of any non-trivial system is impractical

• Input data domain is extremely large
• Design an optimal test suite
• Of reasonable size and
• Uncovers as many errors as possible
• If test cases are selected randomly
• Many test cases would not contribute to the significance of the test suite
• Would not detect errors not already being detected by other test cases in the
suite
• Number of test cases in a randomly selected test suite
• Not an indication of effectiveness of testing

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 20 / 51

Design of Test Cases

• Testing a system using a large number of randomly selected test cases

• Does not mean that many errors in the system will be uncovered
• Consider foloowing example
• Find the maximum of two integers x and y
• The code has a simple programming error
If (x>y)
max = x;
else
max = x;
• Test suite {(x=3,y=2);(x=2,y=3)} can detect the error
• A larger test suite {(x=3,y=2);(x=4,y=3); (x=5,y=1)} does not detect the
error

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 21 / 51

Design of Test Cases

• Systematic approaches are required to design an optimal test suite

• Each test case in the suite should detect different errors
• There are essentially two main approaches to design test cases
• Black-box approach
• White-box (or glass-box) approach

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 22 / 51

Black-Box Testing
• Test cases are designed using only functional specification of the software
• Without any knowledge of the internal structure of the software
• For this reason, black-box testing is also known as functional testing

White-box Testing
• Designing white-box test cases
• Requires knowledge about the internal structure of software
• White-box testing is also called structural testing

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 23 / 51

Black-Box Testing

• There are essentially two main approaches to design black box test cases
• Equivalence class partitioning
• Boundary value analysis

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 24 / 51

Equivalence Class Partitioning

• Input values to a program are partitioned into equivalence classes

• Partitioning is done such that
• Program behaves in similar ways to every input value belonging to an
equivalence class
• Why Define Equivalence Classes?
• Test the code with just one representative value from each equivalence class
• As good as testing using any other values from the equivalence classes

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 25 / 51

Equivalence Class Partitioning

• How do you determine the equivalence classes?

• Examine the input data
• Few general guidelines for determining the equivalence classes can be given
• If the input data to the program is specified by a range of values
• e.g. numbers between 1 to 5000
• One valid and two invalid equivalence classes are defined
• The set of negative integers
• Set of integers in the range of 1 and 5000
• Integers larger than 5000
• The test suite must include
• Representatives from each of the three equivalence classes
• A possible test suite can be: {-5,500,6000}
• If input is an enumerated set of values
• e.g. {a,b,c}
• One equivalence class for valid input values
• Another equivalence class for invalid input values should be defined

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 26 / 51

Boundary Value Analysis

• Some typical programming errors occur

• At boundaries of equivalence classes
• Might be purely due to psychological factors
• Programmers often fail to see
• Special processing required at the boundaries of equivalence classes
• Programmers may improperly use < instead of <=
• Boundary value analysis
• Select test cases at the boundaries of different equivalence classes
• For a function that computes the square root of an integer in the range of 1
and 5000
• Test cases must include the values: {0,1,5000,5001}

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 27 / 51

Debugging

• Once errors are identified

• It is necessary identify the precise location of the errors and to fix them
• Each debugging approach has its own advantages and disadvantages
• Each is useful in appropriate circumstances

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 28 / 51

Brute-Force method

• This is the most common method of debugging

• Least efficient method
• Program is loaded with print statements
• Print the intermediate values
• Hope that some of printed values will help identify the error

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 29 / 51

Symbolic Debugger

• Brute force approach becomes more systematic

• With the use of a symbolic debugger
• Using a symbolic debugger
• Values of different variables can be easily checked and modified
• Single stepping to execute one instruction at a time
• Break points and watch points can be set to test the values of variables

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 30 / 51

Backtracking

• This is a fairly common approach

• Beginning at the statement where an error symptom has been observed
• Source code is traced backwards until the error is discovered
• Unfortunately, as the number of source lines to be traced back increases
• the number of potential backward paths increases
• becomes unmanageably large for complex programs

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 31 / 51

Cause-elimination method

• Determine a list of causes

• which could possibly have contributed to the error symptom
• tests are conducted to eliminate each
• A related technique of identifying error by examining error symptoms
• software fault tree analysis

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 32 / 51

Program Slicing

• This technique is similar to back tracking

• However, the search space is reduced by defining slices
• A slice is defined for a particular variable at a particular statement
• set of source lines preceding this statement which can influence the value of
the variable

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 33 / 51

Debugging Guidelines

• Debugging usually requires a thorough understanding of the program design

• Debugging may sometimes require full redesign of the system
• A common mistake novice programmers often make
• not fixing the error but the error symptoms
• Be aware of the possibility
• an error correction may introduce new errors
• After every round of error-fixing
• regression testing must be carried out

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 34 / 51

Program Analysis Tools

• An automated tool
• takes program source code as input
• produces reports regarding several important characteristics of the program
• such as size, complexity, adequacy of commenting, adherence to programming
standards, etc.
• Some program analysis tools
• Produce reports regarding the adequacy of the test cases
• There are essentially two categories of program analysis tools
• Static analysis tools
• Dynamic analysis tools

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 35 / 51

Static Analysis Tools

• Static analysis tools

• Assess properties of a program without executing it
• Analyze the source code
• Provide analytical conclusions
• Whether coding standards have been adhered to?
• Commenting is adequate?
• Programming errors such as
• uninitialized variables
• mismatch between actual and formal parameters
• variables declared but never used, etc.
• Code walk through and inspection can also be considered as static analysis
methods
• However, the term static program analysis is generally used for automated
analysis tools

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 36 / 51

Dynamic Analysis Tools

• Dynamic program analysis tools require the program to be executed

• its behavior recorded
• Produce reports such as adequacy of test cases

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 37 / 51

Testing

• The aim of testing is to identify all defects in a software product

• However, in practice even after thorough testing
• one cannot guarantee that the software is error-free
• The input data domain of most software products is very large
• It is not practical to test the software exhaustively with each input data value
• Testing does however expose many errors
• Testing provides a practical way of reducing defects in a system
• Increases the users’ confidence in a developed system

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 38 / 51

Testing

• Testing is an important development phase

• requires the maximum effort among all development phases
• In a typical development organization
• maximum number of software engineers can be found to be engaged in testing
activities
• Many engineers have the wrong impression
• testing is a secondary activity
• it is intellectually not as stimulating as the other development activities, etc.
• Testing a software product is in fact
• as much challenging as initial development activities such as specification,
design, and coding
• Also, testing involves a lot of creative thinking

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 39 / 51

Testing

• Software products are tested at three levels

• Unit testing
• Integration testing
• System testing

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 40 / 51

Unit testing

• During unit testing, modules are tested in isolation

• If all modules were to be tested together
• it may not be easy to determine which module has the error
• Unit testing reduces debugging effort several folds
• Programmers carry out unit testing immediately after they complete the
coding of a module

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 41 / 51

Integration testing
• After different modules of a system have been coded and unit tested
• modules are integrated in steps according to an integration plan
• partially integrated system is tested at each integration step

System testing
• System testing involves
• validating a fully developed system against its requirements

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 42 / 51

Integration Testing

• Develop the integration plan by examining the structure chart

• big bang approach
• top-down approach
• bottom-up approach
• mixed approach

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 43 / 51

Big Bang Integration Testing

• Big bang approach is the simplest integration testing approach

• all the modules are simply put together and tested
• this technique is used only for very small systems
• Main problems with this approach
• If an error is found
• It is very difficult to localize the error
• The error may potentially belong to any of the modules being integrated
• Debugging errors found during big bang integration testing are very expensive
to fix

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 44 / 51

Integration Testing

Bottom-up Integration Testing

• Integrate and test the bottom level modules first
• A disadvantage of bottom-up testing
• when the system is made up of a large number of small subsystems
• This extreme case corresponds to the big bang approach

Top-down integration testing

• Top-down integration testing starts with the main routine
• and one or two subordinate routines in the system
• After the top-level ‘skeleton’ has been tested
• immediate subordinate modules of the ‘skeleton’ are combined with it and
tested

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 45 / 51

Integration Testing

• Mixed Integration Testing

• Mixed (or sandwiched) integration testing
• uses both top-down and bottom-up testing approaches
• most common approach

• In top-down approach
• testing waits till all top-level modules are coded and unit tested
• In bottom-up approach
• testing can start only after bottom level modules are ready

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 46 / 51

System Testing

• There are three main kinds of system testing

• Alpha Testing
• Beta Testing
• Acceptance Testing

• Alpha Testing
• System testing is carried out by the test team within the developing
organization
• Beta Testing
• System testing performed by a select group of friendly customers

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 47 / 51

Acceptance Testing
• System testing performed by the customer himself
• to determine whether the system should be accepted or rejected

Stress Testing
• Stress testing (aka endurance testing)
• impose abnormal input to stress the capabilities of the software
• input data volume, input data rate, processing time, utilization of memory,
etc. are tested beyond the designed capacity

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 48 / 51

How Many Errors are Still Remaining?

• Seed the code with some known errors

• artificial errors are introduced into the program
• Check how many of the seeded errors are detected during testing
• Error Seeding

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 49 / 51

Error Seeding

• Let
• N be the total number of errors in the system
• n of these errors be found by testing
• S be the total number of seeded errors
• s of the seeded errors be found during testing
• n/N = s/S
• N = S n/s
• Remaining defects:
N - n = n ((S - s)/ s)

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 50 / 51

Error Seeding

• Example
• 100 errors were introduced
• 90 of these errors were found during testing
• 50 other errors were also found
• Remaining errors= 50 (100-90)/90 = 6

• The kind of seeded errors should match closely with existing errors
• However, it is difficult to predict the types of errors that exist
• Categories of remaining errors
• can be estimated by analyzing historical data from similar projects.

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 51 / 51