The document provides a detailed overview of software coding and testing, including coding standards, code review processes, and the importance of software documentation. It outlines various testing methodologies such as unit testing, black box testing, and white box testing, along with guidelines for effective code reviews like walkthroughs and inspections. Additionally, it emphasizes the significance of test documentation in summarizing testing phases and outcomes.

1. Software
Coding and Testing
by:
Dr. Bharat V. Chawda
Computer Engineering Department,
BBIT, VVNagar, Gujarat, India
1

2. Overview
 Introduction
 Code Review
 Software Documentation
 Testing
 Test Documentation
(As per GTU Curriculum – Diploma in Computer/IT Engineering)
Based on Books:
1. Fundamentals of Software Engineering – by Rajib Mall
2. Software Engineering: A Practitioner’s Approach – by Roger Pressman
2

3. Introduction: Coding
 When?
 After:
 Design phase is complete, and
 Design docs are successfully reviewed
 Objective
 Design of System  Code in high-level lang
 Unit test this code
 Coding Standards
 Coding Guidelines
3

4. Code Review
 When?
 After: Module successfully compiles
 All the syntax errors have been eliminated
 Code review v/s Testing
 CR: Cost-effective strategy for error elimination
 CR: Direct detects errors
 T: Detects failures only: diff i/p, circumstances
 Testing: Requires efforts: Debugging – locate
errors; Error Correction – fix the bug
 CR: Two Types
 Code Walkthrough, Code Inspection
4

5. Code Walkthrough
 Informal code analysis technique
 When to review?
 After: Module is Coded, Compiled, and Syntax Errors
are eliminated
 How?
 Few members of dev team are assigned this task
 Each member selects some test cases
 Simulate execution of code by hand
 (Trace execution through different Statements and
Instructions of the code)
 Note down findings; Discuss with coder in WT meeting
5

6. Code Walkthrough (cont)
 Objective
 Discover the algorithmic and logical errors in
the code
 Guidelines
 Team size: Not too big, not too small: 3-7
member
 Focus on discovery of errors, not on how to fix
them
 Managers should not attend WT meeting – To
avoid feeling: engineers are being evaluated
6

7. Code Inspection
 Code is examined for the presence of some
common/classical programming
errors
 Use of uninitialized variables
 Incompatible assignments
 Non terminating loops; Jumps into loops;
Improper modification of loop variables
 Mismatch in arguments in procedure (fun) calls
 Array indices out of bounds
 Improper storage allocation and de-allocation
 Use of incorrect logical operators; Precedence
 Comparison of equality of floating point values 7

8. Code Inspection (cont)
 Objective:
 Check for the common types of errors
 Check whether coding standard have been
adhered to
 SW companies can maintain list of
commonly committed error  check list for
code inspection
8

9. Software Documentation
 SW Product
 Executable files + Source Code + Documents
 Documents: Users’ manual, SRS doc, Design
doc, Test doc, Installation manual, etc
 Why required?
 Enhances understandability of SW product;
Reduces effort & time required 4 maintenance
 Help users to und & effectively use the system
 Help in effectively tackling manpower turnover
 Help manager to effectively track progress
9

10. SW: Internal Documentation
 Code comprehension features: provided in
the source code itself
 Comments embedded in the source code
 Use of meaningful variable names
 Module and function headers
 Code indentation
 Code structuring (modules + functions)
 Use of constant identifiers
 Use of enumerated types
 Use of user-defined data types
10

11. SW: External Documentation
 Contains various types of supportive docs
 Users’ manual
 SRS doc
 Design doc
 Test doc
 Installation manual…
 Features: Good external documentation
 Consistency
 Understandability
11

12. Gunning’s Fog Index
 Metric to measure the readability of a document
 Fog(D) = [0.4 * words/sentences] +
[% of words having >=3 syllables]
 Example: “The Gunning’s fog index is based on
the premise that use of short sentences and
simple words makes a document easy to
understand”
 Fog(D) = [0.4 * 23 / 1] + [4 / 23 * 100]
= 26
 Indicates the no. of years of formal education
required to comfortably understand document
12

13. Testing: Introduction
 Testing:
 Aim: Identify all defects in a program
 Error / Defect / Bug / Fault:
 Mistake committed by development team
during any of the development phases.
 Failure:
 Manifestation of an error
 Symptom of an error
 Test case: Triplet [I, S, O]: I/P, State, O/P
 Test suite: Set of all test cases…
13

14. Testing: Levels/Stages
 Unit Testing
 Integration Testing
 System Testing
14

15. Unit Testing
 When?
 After: Module has been coded and reviewed
 How?
 Design test cases
 Develop Environment
 Do testing
 Environment
 Driver + Module + Stub
(Stub: Dummy procedures with simplified behavior)
(Driver: Non-local data str + Code to call fun of module)
15
Driver
Stub
Module under Test
Global
Data

16. Black Box Testing
16
int find_max(int x, int y)
{
int max;
if (x>y)
max = x;
else
max = y;
return max;
}
x
y
max
find_max

17. Black Box Testing
 Concept
 Based on functional specification of SW
 Based on functional behavior: Inputs/Outputs
 Also known as: Functional Testing
 No knowledge of design & code is required
 Two main approaches
 Equivalence Class Partitioning
 Boundary Value Analysis
17

18. Black Box Testing: Example
 SW: Computes square root of integer
values in the range of 0 and 5000.
 Test Cases: Equivalence Class Partitioning
 {-5, 500, 6000}
 Test Cases: Boundary Value Analysis
 {-1, 0, 5000, 5001}
18

19. White Box Testing
19
int find_max(int x, int y)
{
int max;
if (x>y)
max = x;
else
max = y;
return max;
}
x
y
max
find_max

20. White Box Testing
 Concept
 Based on analysis of code
 Based on structure of the implementation
 Also known as: Structural Testing
 Knowledge of design & code is required
 Two Types
 Fault based: Targets: detect certain types of F
 Coverage based: Targets: execute (cover)
certain elements of a program
20

21. White Box T: Coverage based
 Strategies
 Statement Coverage
 Each statement should be executed at least once
 Branch Coverage
 Each branch : traversed at least once
 Condition Coverage
 Each condition : True at least once and false at least
once
 Path Coverage
 Each linearly independent path : executed at least
once
21

22. White Box T: Example
int test (int x, int y)
{ int z;
z = -1;
if (x>0 && y>0)
z = x;
return z;
}
22
Statement Coverage:
{(x=1,y=1)}
Branch Coverage:
{(1,1), (0,0)}
Condition Coverage:
{(0,0), (0,1), (1,0), (1,1)}

23. White Box T: Path Coverage
 Concept
 All linearly independent paths in the program
are executed at least once
 CFG: Control Flow Graph
 Directed graph – consisting of a set of Nodes
(N) and Edges (E) where
 Nodes (N): corresponds to a unique program
statement
 Edges (E): Transfer of control From one node
to another node
23

24. White Box T: Path Coverage
 Example:
int gcd (int x, int y)
{
while (x!=y)
{
if (x>y)
x=x-y;
else
y=y-x;
}
return x;
}
24

25. White Box T: Path Coverage
 Example:
int gcd (int x, int y)
{
1. while (x!=y)
{
2. if (x>y)
3. x=x-y;
else
4. y=y-x;
5. }
6. return x;
}
25
1
2
3 4
5
6
 CFG:

26. Cyclomatic Complexity Metric
 V(G) = E – N + 2
 V(G) = Total number of Non-overlapping
Bounded Areas + 1
 V(G) = Total number of Non-overlapping
Areas
 V(G) = Decision Points + 1
 V(G) = Predicate Nodes + 1
26
Cyclomatic Complexity of previous example of GCD: 3

27. Test Documentation
 When: Towards end of testing
 Represents: Test summary report
 Specifies:
 Total number of tests: applied to a sub-system
 How many tests were successful
 How many tests were unsuccessful; and at
which extent (degree): totally or partially
27

28. Thank-U…!!!
28