08-05-2024

SOFTWARE CODING AND TESTING

UNIT NO. : 04 MARKS : 14

INTRODUCTION - CODING
 The objective of coding phase is to transform the
design of a system into code in a high-level language,
and then to unit test this code.
 A good software development organizations require
their programmers to adhere to some well-defined and
standard style of coding which they call their coding
standard.
 The main advantages of adhering to a standard style of
coding are the following:
 A coding standard gives a uniform appearance to the codes
written by different engineers.
 It facilitates code understanding. 2

 It promotes good programming practices.

By: Mr. Jigar Patel

1
 08-05-2024

A coding standard lists several rules to be followed

during coding such as the way variables are to be
names, the way the code is to be laid out, the error

By: Mr. Jigar Patel

return conventions etc.
 Coding standards have to be mandatorily followed
by programmers, and compliance to coding standard
is verified before testing phase can start.
 In contrast, coding guidelines provide some general
suggestions regarding the coding style to be
followed but leave the actual implementation of
these guidelines to the direction of the individual3
developers.

CODING STANDARD AND GUIDELINES

 Good software development organizations usually
develop their own coding standards and guidelines
depending on what suits their organizations best and
based on the specific types of products they develop.
By: Mr. Jigar Patel

 Representative coding standards

 Rules for limiting the use of global : These rules list what
type of data can be declared global and what can not.
 Standard headers to precede the code of different modules
 Naming conventions for global variables, local variables and
constant identifiers:
 Global variable : GlobalData

 Local variable : localData

4
 Constant Name: CONSTDATA

2
 08-05-2024

 Representative Coding Guidelines

 Do not use a coding style that is too clever or

By: Mr. Jigar Patel

too difficult to understand.
 Do not use an identifier for multiple
purposes.
 The code should be well-documented.
 The length of any function should not exceed
10 source lines.
 Do not use GO TO statements.
5

CODE REVIEW
 Code review for a module is undertaken after the
module successfully compiles.
 That is , all the syntax errors have been eliminated
form the module.
By: Mr. Jigar Patel

 Eliminating an error from code involves three main

activities – testing, debugging and then correcting
the errors.
 Testing is carried out to detect if the system fails to
work satisfactory for certain types of inputs and
under certain circumstances.
 Once a failure is detected, debugging is carried out
to locate the error that is causing the failure. 6

 Finally, error correction is carried out to fix the bug.

3
 08-05-2024

 Types of code review technique

By: Mr. Jigar Patel

 CODE INSPECTION

 CODE WALKTHROUGH

CODE INSPECTION
 During code inspection, the code is examined for the
presence of some common programming errors.
By: Mr. Jigar Patel

 The principal aim of code inspection is to check for the

presence of some common types of errors that usually
creep into code due to programmer oversights and to
check whether coding standards have been adhered
to.
 Good software development companies collect
statistics regarding different types of errors commonly
committed by their engineers and identify the types of 8

errors most frequently committed.

4
 08-05-2024

 Following is a list of some classical

programming errors which can be checked
during code inspection:

By: Mr. Jigar Patel

 Use of uninitialized variables
 Jumps into loops
 Non-terminating loops
 Incompatible assignments
 Array indices out of bounds
 Improper storage allocation and deallocation.
 Mismatches between actual and formal parameter in
procedure calls.
 Improper modification of loop variables. 9

CODE WALKTHROUGH
 Code walkthrough is an informal code analysis
technique.
By: Mr. Jigar Patel

 In this technique, a module is taken up for review

after the module has been coded, successfully
compiled, and all syntax errors have been eliminated.
 A few members of the development team are given the
code a couple of days before the walkthrough meeting.
 Each member selects some test cases and simulates
execution of the code by hand.
 The main objective of code walkthrough is to
discover the algorithmic and logical errors in
10
the code.

5
 08-05-2024

 The members note down their findings of their

walkthrough and discuss those in a walkthrough

By: Mr. Jigar Patel

meeting where the coder of the module is present.
 Guidelines for Code Walkthrough techniques:

 The team performing code walkthrough should

not be either too big or too small. Ideally, it
should consists of between three to seven
members.
 Discussions should focus on discovery of errors
and avoid deliberations on how to fix the11
discovered errors.

SOFTWARE DOCUMENTATION
 When a software product is developed, in addition to
the executable files and the source code, several
kinds of documents such as users’ manual, SRS
document, design document, test document,
By: Mr. Jigar Patel

installation manual etc. are developed as part of the

software engineering process.
 Good documents are very useful and serve the
following purposes.
 Good documents help enhance understandability of a
software product.
 Documents help the users to understand an effectively use
the system. 12

 Good documents help in effectively tackling the manpower

turnover problem.

6
 08-05-2024

 Different types of software documents can be

classified into the following:

By: Mr. Jigar Patel

 Internal Documentation:
These are provided in the source code itself.

 External Documentation:
These are the supporting documents that
usually accompany a software product. 13

INTERNAL DOCUMENTATION
 Internal documentation is provided in the source
code itself.
 Internal documentation can be provided in the code
in several forms.
By: Mr. Jigar Patel

 The important types of internal documentation are

the following:
 Comments embedded in the source code.
 Use of meaningful variable names,
 Module and function headers.
 Code structuring.
 Use of enumerated types.
14
 Use of CONSTANT identifiers.

7
 08-05-2024

EXTERNAL DOCUMENTATION
 External documentation is provided through various
types of supporting documents such as users’
manual, SRS document, design document, test
document etc.

By: Mr. Jigar Patel

 An important features of good external
documentation is consistency with the code.
 If the different documents are not consistent, a lot
of confusion is created for somebody trying to
understand the product.
 In other words, all the documents developed for
product should be up-to-date and every change
made to the code should be reflected in the relevant15
external documents.

TESTING
 The aim of program testing is to identify all defects in
a program.
 However, in practice, even after satisfactory
completion of the testing phase, it is not possible to
By: Mr. Jigar Patel

guarantee that a program is error free.

 Terminologies of Testing
 Error : An error is a mistake committed by the development
team during any of the development phases.
 Failure : A failure is the symptom of an error.
 Test Case: A test case is the triplet[I,S,O], where I is the data
input to the system, S is the state of the system at which the
data is input, and O is the expected output of the system.
16
 Test Suite : A test suite is the set of all cases with which a
given software product is tested.

8
 08-05-2024

 Validation Vs Verification
 Verification : Verification is the process of determining
whether the output of one phase of software development

By: Mr. Jigar Patel

confirms to that of its previous phase.
 Validation: Validation is the process of determining
whether a fully developed system confirms to its
requirement specification.
 Testing Activities:
 Test suite design
 Running test cases and checking the results to detect
failures
 Debugging 17

 Error correction

TESTING PROCESS
By: Mr. Jigar Patel

18

9
 08-05-2024

TESTING METHODS
 There are two main approaches to design test
cases:

By: Mr. Jigar Patel

 Black-box Approach (Functional Testing)

 In the black-box approach, test cases are

designed using only the functional
specification of the software.
 That is, test cases are designed solely based on
an analysis of the input/output behavior and
does not require any knowledge of the internal
structure of a program.
 For this reason, black-box testing is also
19
known as functional testing.

 White-box Approach (Structural testing)

 In the white-box approach, designing white-
By: Mr. Jigar Patel

box test cases requires a knowledge of the

internal structure of a program, and therefore
white-box testing is also called as structural
testing.
 In white-box approach, test cases are based on
an analysis of the code.

20

10
 08-05-2024

BLACK-BOX TESTING (FUNCTIONAL )

 In black-box testing, test cases are designed from
an examination of the input/output values only
and no knowledge of design or code is required.

By: Mr. Jigar Patel

 The following are the two main approaches
available to design black-box test cases.
 Equivalence Class Partitioning
 Boundary Value Analysis

21

EQUIVALENCE CLASS PARTITIONING

 In the equivalence class partitioning approach,
domain of input values to the program under
test is partitioned into a set of equivalence
By: Mr. Jigar Patel

classes.
 The partitioning is done such that for every
input data belonging to the same equivalence
class, the program behaves similarly.
 Equivalence classes for a program can be
designed by examining the input data and
output data.

22

11
 08-05-2024

 The following two general guidelines for designing the

equivalence classes.
1. If the input data values to a system can be specified
by a range of values, then one valid and two invalid
equivalence classes need to be defined. For example,

By: Mr. Jigar Patel

if the equivalence class is the set of integers in the
range 1 to 10, then the invalid equivalence classes
are [-∞,0],[11,+∞].
2. If the input data assumes values from a set of
discrete members of some domain, then one
equivalence class for the valid input values and
another equivalence for the invalid input values
should be defined. For example, if the valid
equivalence classes are {A,B,C}, then the invalid
class is U-{A,B,C}, where U is the universe of
possible input values. 23

 Example, for a software that computes the

square root of an input integer that can
assume values in the range of 0 to 5000.
By: Mr. Jigar Patel

Determine the equivalence class test suite.

 There are three equivalence classes- the set of

negative integers, the set of integers in the range
of 0 and 5000, and the set of integers larger than
5000.
 Therefore, the test cases must include
representatives for each of the three equivalence
classes.
 So, a possible test suite can be {-5,500,6000}. 24

12
 08-05-2024

BOUNDARY VALUE ANALYSIS

 A type of programming error that is frequently
committed by programmers is missing out on the
special consideration that should be given to the

By: Mr. Jigar Patel

values at the boundaries of different equivalence
classes of inputs.
 The reason behind programmers committing such
errors might purely be due to psychological factors.
 Programmers often fail to properly address the special
processing required by the input values that lie at the
boundary of the different equivalence classes.
 For example, programmers may improperly use <
25
instead of <= etc.

 Boundary value analysis-based test suite design

involves designing test cases using the values at
the boundaries of different equivalence classes.
By: Mr. Jigar Patel

 For an equivalence class that is a range of values,

the boundary values need to be included in the
test suite.
 For example, if an equivalence class contain the
integers in the range 1 to 10, then the boundary
value test suite is {0,1,10,11}.

26

13
 08-05-2024

WHITE-BOX TESTING (STRUCTURAL)

 White-box testing is an important type of unit
testing.

By: Mr. Jigar Patel

 A large number of white-box testing strategies
exist.
 Each testing strategy essentially designs test case
based on analysis of some aspect of source code and
is based on some heuristic.
 A white-box testing strategy can either be
coverage-based or fault-based.
 Fault-based testing
 A fault-based testing strategy targets to detect certain 27
types of faults.

 Coverage-based testing
 A coverage-based testing strategy attempts to
By: Mr. Jigar Patel

execute certain elements of a program.

 Popular examples of coverage-base testing
strategies are statement coverage, branch
coverage and path coverage-based testing.

28

14
 08-05-2024

 Statement Coverage:
 The statement coverage-based strategy aims to
design test cases so as to execute every statement
in a program at least once.

By: Mr. Jigar Patel

 It is obvious that without executing a statement, it
is difficult to determine whether it leads to a
failure due to some illegal memory access, wrong
result computation due to improper arithmetic
operation, etc.

29

 Example: Design statement coverage-based test suite

for the following Euclid’s GCD computation program.
int computeGCD(int x,int y)
By: Mr. Jigar Patel

{
while(x!=y)
{
if(x>y) then
x=x-y;
else
y=y-x;

}
30
}

15
 08-05-2024

 To design the test cases for the statement

coverage, the conditional expression of the while
statement needs to be made true and the

By: Mr. Jigar Patel

conditional expression of the if statement needs
to be made both true and false.
 By choosing the test set { (x=3, y=3) , (x=4, y=3) ,
(x=3, y=4) } all statements of the program would
be executed at least once.

31

 Branch Coverage:
 Branch coverage-based testing requires test cases to
be designed so as to make each branch condition in
By: Mr. Jigar Patel

the program to assume true and false values in turn.

 Branch testing is also known as edge testing, since in
this testing scheme, each edge of a program’s control
flow is traversed at least once.
 For previous example, the test cases for branch
coverage can be {(x=3, y=3) , (x=3, y=2) , (x=4, y=3) ,
(x=3, y=4) }.
 Branch coverage-based testing is a stronger testing
than statement coverage-based testing.
32

16
 08-05-2024

 Path Coverage:
 Path coverage-based testing strategy requires designing
test cases such that all linearly independent paths in the
program are executed at least once.

By: Mr. Jigar Patel

 A linearly independent path can be defined in terms of the
control flow graph(CFG) of a program.
 A control flow graph describes how the control flows
through the program.
 In order to draw the flow graph of a program, we need to
first number all the statements of a program.
 The different numbered statements serve as nodes of the
control flow graph.
 There exists an edge from one node to another, if the
execution of the statement representing the first node can
33

result in the transfer of control to the other node.

 Example:
 Sequence:
1. a=5;
By: Mr. Jigar Patel

2. b = a*2 -1

 Selection:
1. if(a>b)
2. c=3;
3. else c=5;
4. c=c*c;

34

17
 08-05-2024

 Iteration:
1. while(a>b) {

By: Mr. Jigar Patel

2. b=b-1;
3. b=b*a;}
4. c=a+b;

35

ALPHA TESTING
 Alpha testing involves both the white box and black box
testing.
 Alpha testing is performed by testers who are usually
By: Mr. Jigar Patel

internal employees of the organization.

 Alpha testing is performed at the developer’s site.
 Reliability and security testing are not checked in alpha
testing.
 Alpha testing ensures the quality of the product before
forwarding to beta testing.
 Alpha testing requires a testing environment or a lab.
 Alpha testing may require a long execution cycle.
 Developers can immediately address the critical issues or
fixes in alpha testing. 36

 Multiple test cycles are organized in alpha testing.

18
 08-05-2024

BETA TESTING
 Beta testing commonly uses black-box testing.
 Beta testing is performed by clients who are not part of the
organization.

By: Mr. Jigar Patel

 Beta testing is performed at the end-user of the product.
 Reliability, security and robustness are checked during
beta testing.
 Beta testing also concentrates on the quality of the
product but collects users input on the product and
ensures that the product is ready for real time users.
 Beta testing doesn’t require a testing environment or lab.
 Beta testing requires only a few weeks of execution.
 Most of the issues or feedback collected from the beta
testing will be implemented in future versions of the
product.
37
 Only one or two test cycles are there in beta testing.

UNIT TESTING
 Unit testing is undertaken after a module has
been coded and successfully reviewed.
 Unit testing (or module testing) is the testing of
By: Mr. Jigar Patel

different units (or modules) of a system in

separately.
 When developer is coding the software it may
happen that the dependent modules are not
completed for testing, in such cases developers
use stubs and drivers to simulate the called
(stub) and caller (driver) units.
 Unit testing requires stubs and drivers, stub
represent the called unit and driver represent the
calling unit. 38

19
 08-05-2024

 In unit testing, each module of the software is tested

separately.
 In unit testing tester knows the internal design of the

By: Mr. Jigar Patel

software.
 Unit testing is performed first of all testing processes.

 Unit testing is white box testing.

 Unit testing is performed by the developer.

 Detection of defects in unit testing is easy.

 It tests parts of the project without waiting for others

to be completed.
39

 Unit testing is less costly.

 Unit testing is responsible to observe only the
By: Mr. Jigar Patel

functionality of the individual units.

 Module specification is done initially.

 The proper working of your code with the external

dependencies is not ensured by unit testing.
 Maintenance is cost effective.

 Fast execution as compared to integration testing.

 Unit testing results in in-depth exposure to the code.

40

20
 08-05-2024

INTEGRATION TESTING
 Integration testing is the second level of the
software testing process comes after unit testing.

By: Mr. Jigar Patel

 In this testing, units or individual components of
the software are tested in a group.
 The focus of the integration testing level is to
expose defects at the time of interaction between
integrated components or units.

41

 In integration testing, all modules of the software

are tested combined.
By: Mr. Jigar Patel

 Integration testing doesn’t know the internal

design of the software.
 Integration testing is performed after unit testing
and before system testing.
 Integration testing is black box testing.

 Integration testing is performed by the tester.

 Detection of defects in integration testing is

difficult.
 It tests only after the completion of all parts. 42

21
 08-05-2024

 Integration testing is more costly.

 Error detection takes place when modules are
integrated to create an overall system.

By: Mr. Jigar Patel

 Interface specification is done initially.
 The proper working of your code with the
external dependencies is ensured by integration
testing.
 Maintenance is expensive.
 Its speed is slow because of the integration of
modules.
 Integration testing results in the integration
structure’s detailed visibility. 43

TESTING DOCUMENTATION
 Test documentation refers to the collection of
documents created during the software testing
process.
By: Mr. Jigar Patel

 It is also called as summary report.

 The purpose of test documentation is to provide a

record of the testing process and results,
including the tests that were performed, the
expected and actual results and any issues or
defects that were identified.
 It specify how many test suits are successful and
how many are unsuccessful.
44

22
 08-05-2024

 Types of Test Documentation

 Test scenario

By: Mr. Jigar Patel

 Test Plan
 Test case
 Test data
 Test execution report
 Defect report
 Test log
 Traceability matrix

45

ADVANTAGE
 It promote systematic approach in software
testing.
By: Mr. Jigar Patel

 Improves the quality of the product.

 It help to improve transparency with the client.

 Helps in setup of testing environment.

 It provides feedback on preventive tasks.

46

23
 08-05-2024

DISADVANTAGE
 Poor documentation directly affect the quality of
the software product.

By: Mr. Jigar Patel

 Creating and maintaining test documentation
can be expensive.
 It can be misinterpreted if it is not clear.

47

24