Software Testing_A_mmmmmmmmmmmmmmmmmmmmm

• Transform the design into code in a high-level language, and
then unit test this code
• Good s/w development organization insist well-defined and
standard style of coding- Coding standard
• The main advantages of coding standards
• Uniform appearance to the codes written by different
engineers
• Facilitates code understanding and reuse
• Ease of maintenance
Coding and Testing

Coding Standards
• Coding standards are a set of guidelines, best
practices, programming styles and
conventions that developers adhere to when
writing source code for a project.

Coding Practices
• Code readability is a universal subject in the world of computer
programming.
1. Commenting & Documentation
– Name of the module
– Date of module creation
– Author of the module
– Modification history
– Synopsis of the module about what the module does
– Different functions supported in the module along with their input
output parameters
2. Consistent Indentation
function foo() {
if ($maybe) {
do_it_now();
again();
} else {
abort_mission();
}
finalize();
}

Coding Practices
3. Avoid Obvious Comments
4. Code Grouping
5. Consistent Naming Scheme
6. DRY Principle
– DRY stands for Don't Repeat Yourself. Also known as DIE:
Duplication is Evil.
// get list of forums
$forums = array();
$r = mysql_query("SELECT id, name, description FROM forums");
while ($d = mysql_fetch_assoc($r)) {
$forums []= $d;
}
// load the templates
load_template('header');
load_template('forum_list',$forums);
load_template('footer');

Coding Practices
7. Avoid Deep Nesting
8. Limit Line Length
9. File and Folder Organization
10. Consistent Temporary Names
11. Capitalize SQL Special Words
12. Separation of Code and Data
13. Alternate Syntax Inside Templates
14. Object Oriented vs. Procedural
15. Read Open Source Code
// bad
$my_email->set_from('test@email.com')->add_to('programming@gmail.com')->set_subject('Methods Chained')->set_body('Some long mess
// good
$my_email
->set_from('test@email.com')
->add_to('programming@gmail.com')
->set_subject('Methods Chained')
->set_body('Some long message')
->send();

Coding Practices- Refactoring
• Code refactoring is the process of restructuring
existing computer code—changing the factoring—
without changing its external behavior.

Refactoring
• The purposes of refactoring according to M. Fowler
are stated in the following:
– Refactoring Improves the Design of Software
– Refactoring Makes Software Easier to Understand
– Refactoring Helps Finding Bugs
– Refactoring Helps Programming Faster

Coding Standards
Advantages of Coding Guidelines:
• Coding guidelines increase the efficiency of the software
and reduces the development time.
• Coding guidelines help in detecting errors in the early
phases, so it helps to reduce the extra cost incurred by
the software project.
• If coding guidelines are maintained properly, then the
software code increases readability and understandability
thus it reduces the complexity of the code.
• It reduces the hidden cost for developing the software.

• Testing: executing the program with a set of test inputs and observing the behavior of
the program.
• Executing a program with the intent of finding an error.
• Program testing helps to identify defects in the program
• It is not possible to guarantee that after testing the software will be error-free.
• To check if the system meets the requirements and be executed successfully in
the Intended environment.
• The possible inputs to the system may be very large and it is not possible to test the
system with all possible inputs
• The unexpected results during testing will be noted and considered later for
debugging and error correction.
• To check if the system is “ Fit for purpose”.
• To check if the system does what it is expected to do.
Software Testing

Objective of Software Testing
• A good test case is one that has a probability
of finding an as yet undiscovered error.
• A successful test is one that uncovers a yet
undiscovered error.
• A good test should neither be too simple nor
too complex.
• A good test is not redundant.
• A good test should be “best of breed”.

V-model
(Verification & Validation Model)
Verification
Validation

VERIFICATION & VALIDATION
• Verification - typically involves reviews and meeting to evaluate
documents, plans, code, requirements, and specifications.
• This can be done with checklists, issues lists, walkthroughs, and
inspection meeting.
– Verification answers the question: Am I building the product right?
• Validation - typically involves actual testing and takes place after
verifications are completed.
• Validation answers the question: Am I building the right product?
• Testing= Verification + Validation.

Types of Testing
• Unit (Module) testing
– testing of a single module in an isolated environment
• Integration testing
– testing parts of the system by combining the modules
– To find the interface errors
• System testing
– testing of the system as a whole after the integration phase
• Acceptance testing
– testing the system as a whole to find out if it satisfies the requirements
specifications

Pros and Cons of the V-Model
Pros:
• This is a highly-disciplined model and Phases are completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
Cons:
• Not a good model for complex and object-oriented projects.
• Not suitable for the projects where requirements are at a moderate to high risk
of changing.
• Once an application is in the testing stage, it is difficult to go back and change a
functionality.
• No working software is produced until late during the life cycle.
• High risk and uncertainty.

Software Testing
Static Testing:
• Static Testing, a software testing technique in which the software is tested
without executing the code.
• It has two parts.
– Review - Typically used to find and eliminate errors or ambiguities in
documents such as requirements, design, test cases, etc.
– Static analysis - The code written by developers are analyzed (usually
by tools) for structural defects that may lead to defects.
Dynamic Testing:
• Involves interaction with the program while it runs.
• Dynamic testing involves testing the software for the input values and output
values are analyzed. Dynamic testing is the Validation part of Verification and
Validation.

•Mistake :
- Any programmer action that later shows up as an incorrect result during
program execution
- Eg:- variable not declared, division by zero, etc.
• Error:
- The result of a mistake committed by the developer
• Failure:
- Failure of a program denotes an incorrect behavior during execution
- Eg:- Expecting a result 100 but obtaining 0
- Program terminating (without a result) for a given input but user expecting
a result
Testing- Concepts& Terminologies

•Test case
- A triplet [I, S, R]
- I: data input
- S: the state of the program
- R: expected result
- Positive test cases: whether the software correctly performs a required
functionality
- Negative test case: test whether the software carries out something, that is
not required of the system
- Example: Correct user name and password for login (positive test case)
- Wrong credentials (negative test case)
- Set of all test cases are known as test suit

Test case
Test Case # Test Case
Description
Test Data Expected
Result
Actual Result Pass/Fail
1
Check
response
when valid
email and
password is
entered
Email: xyz@e
mail.com
Password:
lNf9^Oti7^2h
Login should
be successful
Login was
successful
Pass
• A test case is a specification of the inputs, execution conditions,
testing procedure, and expected results that define a single test to
be executed to achieve a particular software testing objective.
• Test suite is collection of test cases.

•Test script
- A short program for automated execution of test cases
• Testability
- Can be adequately tested to determine its conformance to the requirement
- Less complex programs is more testable
- Several matrices are available to find the complexity of a program
- Cyclomatic complexity
• Failure mode
- All failures with similar observable symptoms

•Test suit design
- design a set of test cases using which the program can be tested
• Running test cases and checking the results to detect failures
- Each test cases is run and observe the result
- Compare the observed result with expected result
- A mismatch indicates failure, those test cases should be noted down for
further debugging
• Locate error
- Failure symptoms are analyzed to locate the error
• Error correction
- After the error is located the code should be appropriately changed to
correct the error
Testing Activities

• A randomly selected test cases cannot guarantee that all (or even most) of the errors
will be detected during testing
• Consider the following code:
if(x>y)
max=x ;
else
max=x;
• Consider the test suite {(x=3, y=2);(x=2, y=3)} can detect the error
• But {(x=3, y=2);(x=4, y=3); (x=5, y=1} can not detect the error
• Large test suite would always detect more errors- Not correct
• This also shows that test suit should be designed carefully
Why Test Case Design?

• Objective:
- Minimal test suite (reasonable size)- reduce the testing time
- As many errors should be detected
•Approaches
- Black-box approach:
- White-box (glass-box) approach
Why Test Case Design?

• Black-box approach:
- Test cases will be designed using functional specification
- Also known as functional testing
- Input and output will be analyzed
- Does not need any knowledge about the internal structure of the program
•White-box (glass-box) approach
- Thorough knowledge of the internal structure of the program is required
- Also known as structural testing
- Not based on input/out, but based on the analysis of code
Approaches for Test Case Design

Basic Testing Strategies
Black-box testing White-box testing
• Tests that validate business
requirements (what the
system is supposed to do)
• Tests that validate internal
program logic (control flow ,
data structures, data flow)
• Test cases are derived from
the requirements specification
of the Coding and Unit
Testing (CUT).
• No knowledge of internal
program structure is used.
• Test cases are derived by
examination of the internal
structure of the Coding and
Unit Testing (CUT).
• Also known as -- functional,
data-driven, or Input/Output
Testing.
• Also known as -- structural or
logic-driven testing

Basic Testing Strategies
• Black box testing (Specification Based)
– Equivalence Class Partitioning
– Boundary Value Analysis
– Decision Table
– Cause-effect graphing
• White box testing (Program Based)
– Control Flow Based
– Data Flow based
– Mutation Testing

• Two main approaches available for black-box test cases
o Equivalence class partitioning
o Boundary value analysis
• Equivalence class partitioning
• The domain of input values is partitioned into a set of equivalence classes
• For every input from one selected equivalence class, the program behaves
similarly
 Guideline 1:
• If the input data values to a system can be specified by range, then one valid
and two invalid equivalence classes need to be defined
Example: Valid equivalence class: [1,10]
Invalid equivalence classes: [-, 0], [11, ]
Black-box Testing

•Guideline 2:
• If the input data values are a set of discrete members of some
domain, then one equivalence class for valid input and one
equivalence class for invalid input
• Example: if valid equivalence class is {A, B, C}, then invalid
equivalence class will be U-{A,B,C}
•
Black-box Testing- Equivalence class partitioning

• For a software that computes the square root of an input integer
that can assume values in the range of 0 and 5000, Determine
the equivalence classes and the black-box test cases
• Equivalence classes are:
• The set of all negative integers
• All integers greater than 5000
• Integers in the range of 0 to 5000
• Test case: {-10,450,6000}
Black-box Testing- Equivalence class
partitioning

• Design equivalence class test cases for a program that reads two
integer pairs (m1,c1) and (m2,c2) defining two straight lines of
the from y=mx+c.
• The program computes the intersection point of the two straight
lines and displays the point of intersection.
• Equivalence classes are:
• Parallel lines (m1=m2, c1 ≠ c2)
• Intersecting lines (m1≠m2)
• Coincident lines (m1=m2, c1=c2)
• Test case: {(2,2) (2,5), (5,5) (7,7), (10,10) (10,10)}
Black-box Testing- Equivalence class
partitioning

Example
• Example: input condition 0 <= x <= 100
– valid equivalence class : 0 <= x <= 100 (50)
– invalid equivalence classes : x < 0  -1, x > 100
101
• 3 test cases

Software Testing_A_mmmmmmmmmmmmmmmmmmmmm

Equivalence Class Partitioning
• Also identify output equivalence classes, and write
test cases to generate the output equivalence
classes.
Example:
• O1= Not a triangle, when any of the sides is
greater than the sum of the other
• O2 = Equilateral Triangle
• O 3= Isosceles Triangle
• O 4= Scalene Triangle

• Designing test cases using the values at the boundaries of
different equivalence classes
• Example: if an equivalence class contains the integers in the
range of 1 to 10, then the boundary value test case is {0,1,10,11}
• For a software that computes the square root of an input integer
that can assume values in the range of 0 and 5000. Determine
the boundary value based test cases.
• Boundary value-base test case: {0,-1,5000,5001}
Black-box Testing- Boundary Value Analysis

Boundary Value Analysis
• The basis of Boundary Value Analysis (BVA) is testing the
boundaries at partitions.
• Design test cases that exercise values that lie at the boundaries of
an input equivalence class.
• Example: input condition 0 <= x <= max
Test for values
: 0,1, x, max-1, max ( valid inputs)
: -1, max+1 (invalid inputs)

BVA:Example-1
• The boundary value analysis test cases for our program with two inputs variables
(x and y) that may have any value from 100 to 300 are:
• (200,100),(200,101), (200,200), (200,299), (200,300), (100,200), (101,200),
(299,200) and (300,200).
• Thus, for a program of n variables, boundary value analysis yield 4n + 1 test cases.

Robust BVA: 6n+1 test cases
-1, 0 , 1, mid, max-1, max, max+1

• Examine the input and output values of the program
• Identify equivalence classes
• Picking one representative value for each equivalence class
• In boundary value-based test cases, values at the boundaries of
the equivalence classes will be considered
Black-box Testing- Summary

• Important type of unit testing
• Test case design based on the analysis of source code
• Coverage based testing is the most common approach for white-
box testing
• Attempts to executes (cover) certain elements of the
program
• Popular coverage based testing approaches:
• Statement coverage
• Branch coverage
• Multiple condition coverage
• Path coverage
• The set of specific program elements that a testing strategy
targets to execute is called the testing criterion of the strategy
White-box Testing

• Aims to design test cases that will lead to execute every
statements in a program at least once
• The principal idea- unless a statement in the program is
executed, there is no way to determine whether an error exists
in that statement
• Weakness: executing all statements once and observing results
does not guarantee that it will behave properly for all the input
values.
White-box Testing- Statement coverage

• Design statement coverage based test suite for the following code
int compute(x,y)
{
while (x!=y){
if(x>y)
x=x-y;
else
y=y-x;
return x;
}
• To execute all the statements in the above program, the while
condition should be true (x!=y)=> (x=3, y=4)
• The if condition should be true and false=> (x=4,y=3) (x=3,y=4)
• We can consider the test set {(x=3, y=4) , (x=4, y=3) }

• The statement coverage in the source code can be computed as
follows:
• Nexe : Total number of statements executed
• Nexe : Total number of statements in the source code
100

tot
exe
N
N
Statement of coverage=

Find the statement of coverage for a test case (a=3, b=9)
printsum (int a, int b) {
int result = a+ b;
if (result> 0)
printf ("Positive") ;
else
printf ("Negative");
}
• Total number of statements executed – 3
• Total number of statements- 5
• Statement of coverage for the test case (a=3, b=9) is 3/5*100=60.00%

Describes how the control flows through the program (execution
flow)
• A control flow graph describes the sequence in which different
instructions of a program get executed
• Steps
• Number all the statements
• Each statement will be a node in the Control Flow Graph (CFG)
• Edge shows that control will go the next node
• Statement coverage based testing ensures that every node is
visiting at least once
White-box Testing-Control flow graph (CFG)

CFG-Formal definition
• A CFG is a directed graph consisting of a set of nodes and edges
(N,E) such that nN corresponds to a unique program
statement and edge eE exist between two nodes if control can
transfer from one node to the other.

Start Node: 1
Terminal node: 6

• A test suit satisfies branch coverage, if it makes each branch
condition in the program to assume true or false values in turn.
• Each branch in the CFG must be taken at least once while test
suite is executed
• Make sure that no branch leads to abnormal behavior of the
application.
• It is also known as edge testing
White-box Testing-Branch Coverage

1. input a, b
2. c=a+b
3. if(c<10)
4. print(“Hello”)
5. print(“The program
execution finished”)
1
2
3
4
5
• In branch coverage testing all edges
should be traversed
• Consider the test case {(a=5, b=6)}
•100% branch coverage is not there

1. input a, b
2. c=a+b
3. if(c<10)
4. print(“Hello”)
5. print(“The program
execution finished”)
1
2
3
4
5
Test suite
{(a=3, b=4),(a=5, b=10)}

• A test suite achieves path coverage if
it executes each linearly
independent paths (basis paths) in a
CFG at least once.
• In CFG, a path is a sequence of
nodes and edges from the start node
to the terminal node
• A program may have multiple
terminal nodes when multiple exit or
return statements
White-box Testing-Path Coverage

• Infinite number of paths may be there in
CFG, when there is loop
• Example:
• 12314
• 1231234
• 1231231234
• If we consider all the paths, then test
case size will become too large

• Infinite number of paths may be
there in CFG, when there is loop
• Example:
• 123516
• 124516
• 1235124516
• etc.

• Path coverage testing does not try to cover all the paths, but
cover only a subset of paths (basis paths)
• If each path in the set introduces at least one new edge that is
not included in any other path in the set.
• Note that if a path has one new node compared to all other
linearly independent paths, then this path also should be
included in the set of linearly independent paths
• For simple programs, finding linearly independent paths are
straight forward
• Complex programs it is not easy

• Practical way to approximately count the number of linearly
independent paths (Upper bound)- McCabe’s Cyclomatic
Complexity
• From a graph, cyclomatic complexity (C) can be computed as
follows:
• N- number of nodes
• E- number of edges
McCabe’s Cyclomatic Complexity (Method-1)
C=E-N+2

• N= 6
• E=7
• C=7-6+2
=3
McCabe’s Cyclomatic Complexity

• Another way of computing the
cyclomatic complexity is based on
visual inspection
C= Total number of non-overlapping
bounded areas+1
• Any region enclosed by nodes and
edges can be considered as a
bounded region
1
2

• From planar graph it is easy to find bounded region
• Most of the structured programs generates planar graph
• GOTO statements may lead to non-planar graphs
1
2
5
4
1
2
4
3
3 3
Planar Non-planar

•The cyclomatic complexity of a program can be
computed by considering the number of decision and
loop statements in a program
• where N is the number of decision and loop
statements
C=N+1

• Finding test cases for path coverage testing is not
easy
• A tester cannot manually find test cases that will
cover all the basis paths in the CFG (assume 20
nodes and 25 edges)
• So a random test cases generation approach will be
used
Steps in Path Coverage Testing

1. Draw CFG
2. Determine cyclomatic complexity
3. Repeat
3.1 Test using randomly designed test cases
3.2 Perform dynamic analysis to check the path
coverage achieved
3.3 until 90 percentage of the path coverage is
achieved
Steps in Path Coverage Testing

• Consider a flow graph given and
calculate the cyclomatic
complexity by all three methods.
1. V(G) = e – n + 2 = 13 – 10 + 2 = 5
2. V(G) = Total number of non-
overlapping bounded areas + 1
= 4 + 1 = 5
3. V(G) = number of regions +1 =
4+1= 5

• Estimation of structural complexity of the program
• S/w development organizations may limit the cyclomatic
complexity of the functions
• Estimation of Testing effort
• Low cyclomatic number indicates that testing effort is less
• Estimation of program reliability
• Number of errors are highly dependent of cyclomatic
complexity
Uses of Cyclomatic Complexity

Data Flow Testing
• Data Flow Testing is a type of structural testing.
• Used to find the test paths of a program according to
the locations of definitions and uses of variables in
the program.
• Data flow testing is used to analyze the flow of data
in the program.
DEF(S) = {X | statement S contains the definition of X}
USE(S) = {X | statement S contains the use of X}

Data Flow Testing
1. read x, y;
2. if(x>y)
3. a = x+1
else
4. a = y-1
5. print a;
VARIABLE
DEFINED AT
NODE
USED AT
NODE
x 1 2, 3
y 1 2, 4
a 3, 4 5
du pairs-X- (1,2), (1,3)
du pairs-y- (1,2), (1,4)
du pairs-a- (3,5), (4,5)

Debugging Process
• Definition: Systematic process of spotting and fixing the number of
bugs, or defects, in a piece of software so that the software is
behaving as expected.
• Debugging is harder for complex systems in particular when various
subsystems are tightly coupled as changes in one system or interface
may cause bugs to emerge in another.
• Debugging is a developer activity and effective debugging is very
important before testing begins to increase the quality of the system.
• Debugging will not give confidence that the system meets its
requirements completely but testing gives confidence

Debugging Process
• Debugging occurs as a consequence of successful testing
• The debugging process begins with the execution of a test case
• Results are assessed and the difference between expected and
actual performance is encountered
• This difference is a symptom of an underlying cause that lies
hidden
• The debugging process attempts to match symptom with cause,
thereby leading to error correction

Why is Debugging so Difficult?
• The symptom and the cause may be geographically remote
• The symptom may disappear (temporarily) when another error is corrected
• The symptom may actually be caused by nonerrors (e.g., round-off accuracies)
• The symptom may be caused by human error that is not easily traced.
• The symptom may be a result of timing problems, rather than processing
problems
• It may be difficult to accurately reproduce input conditions, such as
asynchronous real-time information
• The symptom may be intermittent such as in embedded systems involving
both hardware and software
• The symptom may be due to causes that are distributed across a number of
tasks running on different processes

Debugging Strategies
• Objective of debugging is to find and correct the cause of a software error
• Bugs are found by a combination of systematic evaluation, intuition, and
luck
• Debugging methods and tools are not a substitute for careful evaluation
based on a complete design model and clear source code
• There are three main debugging strategies
– Brute force
– Backtracking
– Cause elimination
– Program slicing

Strategy #1: Brute Force
• Most commonly used and least efficient method
• The program loaded with print statement to print the intermediate values
will help to identify the error.
• Involves the use of memory dumps, run-time traces, and output
statements
• Leads many times to wasted effort and time
1. int i;
2. int sum = 0;
3. int product = 1;
4. int w = 7;
5. for(i = 1; i < N; ++i) {
6. sum = sum + i + w;
7. product = product * i;
8. }
9. Printf(“%d”, sum);
10.Printf(“%d”, product);
1. int i;
2. int sum = 0;
3. int product = 1;
4. int w = 7;
5. for(i = 1; i < N; ++i) {
6. sum = sum + i + w;
7. printf(“%d”, sum);
9. printf(“%d”, product);
10. }
11.printf(“%d”, sum);
12.printf(“%d”, product);

Strategy #2: Backtracking
• Can be used successfully in small programs
• The method starts at the location where a symptom has been uncovered
• The source code is then traced backward (manually) until the location of
the cause is found
• In large programs, the number of potential backward paths may become
unmanageably large

Strategy #3: Cause Elimination
• Involves the use of induction or deduction and introduces the
concept of binary partitioning
– Induction (specific to general): Prove that a specific starting
value is true; then prove the general case is true
– Deduction (general to specific): Show that a specific conclusion
follows from a set of general premises
• 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 cause
• If initial tests indicate that a particular cause hypothesis shows
promise, data are refined in an attempt to isolate the bug

Strategy #4: Program Slicing
• Program slicing is the computation of the set of program
statements, the program slice, that may affect the values at
some point of interest, referred to as a slicing criterion.
• Program slicing can be used in debugging to locate source of
errors more easily.
1. int i;
2. int sum = 0;
3. int product = 1;
4. int w = 7;
5. for(i = 1; i < N; ++i)
{
6. sum = sum + i + w;
8. }
9. write(sum);
10.write(product);
The static executable slice for criteria
(write(sum), sum) is the new
program shown below.
1. int i;
2. int sum = 0;
3. int w = 7;
4. for(i = 1; i < N; ++i)
{
5. sum = sum + i + w;
6.
7. }
8. write(sum);

• Testing Versus Debugging: Purpose of testing is to show that a program
has bugs.
• The purpose of debugging is to find the error or misconception that led to
the program's failure and to design and implement the program changes
that correct the error.
Testing Debugging
• Testing starts with known conditions, uses
predefined procedures and has predictable
outcomes.
• Debugging starts from possibly unknown
initial conditions and the end can not be
predicted except statistically.
• Testing can and should be planned,
designed and scheduled.
• Procedure and duration of debugging
cannot be so constrained.
• Testing is a demonstration of error or
apparent correctness. • Debugging is a deductive process.
• Testing proves a programmer's failure. • Debugging is the programmer's vindication
(Justification).
• Testing, as executes, should strive to be
predictable, dull, constrained, rigid and
inhuman.
• Debugging demands intuitive leaps,
experimentation and freedom.
• Much testing can be done without design
knowledge.
• Debugging is impossible without detailed
design knowledge.
• Testing can often be done by an outsider. • Debugging must be done by an insider.

Software Maintenance
• Software is released to end-users, and
– within days, bug reports filter back to the software engineering
organization.
– within weeks, one class of users indicates that the software must
be changed so that it can accommodate the special needs of their
environment.
– within months, another corporate group who wanted nothing to
do with the software when it was released, now recognizes that it
may provide them with unexpected benefit.
• They’ll need a few enhancements to make it work in their
world.
• All of this work is software maintenance

Software Maintenance
• Corrective maintenance is concerned with fixing errors that are observed
when the software is in use.
• Adaptive maintenance is concerned with the change in the software that
takes place to make the software adaptable to new environment such as to
run the software on a new operating system.
• Perfective maintenance is concerned with the change in the software that
occurs while adding new functionalities in the software.
• Preventive maintenance involves implementing changes to prevent the
occurrence of errors.

Maintainable Software
• Maintainable software exhibits effective modularity
• It makes use of design patterns that allow ease of understanding.
• It has been constructed using well-defined coding standards and
conventions, leading to source code that is self-documenting and
understandable.
• It has to undergone a variety of quality assurance techniques
that have uncovered potential maintenance problems before the
software is released.
• It has been created by software engineers who recognize that they
may not be around when changes must be made.
– Therefore, the design and implementation of the software must
“assist” the person who is making the change

Reengineering
• Restructuring or rewriting part or all of a system without
changing its functionality.
• Applicable when some (but not all) subsystems of a larger system
require frequent maintenance.
• Reengineering involves putting in the effort to make it easier to
maintain.
• The reengineered system may also be restructured and should be re-
documented.

Reengineering
Business
processes
IT
systems Software
applications
Reengineering

Business Process Reengineering
• Business process reengineering (BPR) extends far beyond the scope of
information technologies and software engineering.
Business Processes
• A business process is “a set of logically related tasks performed to
achieve a defined business outcome”
• The business business systems  business processes  business
subprocesses.
• BPR can be applied at any level of the hierarchy, but as the scope of
BPR the risks associated with BPR grow dramatically.

Business Process Reengineering Model

Business Process Reengineering
• Business definition. Business goals are identified within the context
of four key drivers: cost reduction, time reduction, quality
improvement, and personnel development and empowerment.
• Process identification. Processes that are critical to achieve the goals
defined in the business definition are identified.
• Process evaluation. The existing process is thoroughly analyzed and
measured.
• Process specification and design. Based on information obtained
during the first three BPR activities, use-cases are prepared for each
process that is to be redesigned.
• Prototyping. A redesigned business process must be prototyped
before it is fully integrated into the business.
• Refinement and instantiation. Based on feedback from the
prototype, the business process is refined and then instantiated within a
business system.

Software Reengineering
• Reengineering is a rebuilding activity.
• Reengineering takes time, it costs significant amounts of money, and it
absorbs resources that might be otherwise occupied on immediate
concerns
• To better understand it, consider an analogous activity: the rebuilding
of a house.

Software Reengineering Process Model
Forward
engineering
Data
restructuring
code
restructuring
reverse
engineering
document
restructuring
inventory
analysis

Inventory Analysis
• Build a table that contains all applications
• Establish a list of criteria, e.g.,
– name of the application
– year it was originally created
– number of substantive changes made to it
– total effort applied to make these changes
– date of last substantive change
– effort applied to make the last change
– system(s) in which it resides
– applications to which it interfaces, ...
• Analyze and prioritize to select candidates for reengineering

Document Restructuring
• Weak documentation is the trademark of many legacy systems.
• But what do we do about it? What are our options?
• Options …
– Creating documentation is far too time consuming. If the system
works, we’ll live with what we have. In some cases, this is the
correct approach. It is not possible to re-create documentation for
hundreds of computer programs.
– Documentation must be updated, but we have limited resources.
We’ll use a “document when touched” approach. It may not be
necessary to fully redocument an application.
– The system is business critical and must be fully redocumented.
Even in this case, an intelligent approach is to pare documentation
to an essential minimum.

Code Restructuring
• Source code is analyzed using a restructuring tool.
• Poorly design code segments are redesigned
• Violations of structured programming constructs are noted and code
is then restructured (this can be done automatically)
• The resultant restructured code is reviewed and tested to ensure that
no anomalies have been introduced
• Internal code documentation is updated.

Data Restructuring
• Unlike code restructuring, which occurs at a relatively low level of
abstraction, data structuring is a full-scale reengineering activity
• In most cases, data restructuring begins with a reverse engineering
activity.
– Current data architecture is dissected and necessary data
models are defined.
– Data objects and attributes are identified, and existing data
structures are reviewed for quality.
– When data structure is weak (e.g., flat files are currently
implemented, when a relational approach would greatly
simplify processing), the data are reengineered.
• Because data architecture has a strong influence on program
architecture and the algorithms that populate it, changes to the data
will invariably result in either architectural or code-level changes.

Forward Engineering
1. Redesign of the software architecture (program and/or data
structure), using modern design concepts, can greatly facilitate
future maintenance.
2. Because a prototype of the software already exists, development
productivity should be much higher than average.
3. The user now has experience with the software. Therefore, new
requirements and the direction of change can be ascertained with
greater ease.
4. CASE tools for reengineering will automate some parts of the job.
5. A complete software configuration (documents, programs and data)
will exist upon completion of preventive maintenance.
6. The cost to maintain one line of source code may be 20 to 40 times
the cost of initial development of that line.

Forward engineering and Reverse
Engineering

Economics of Reengineering-I
• A cost/benefit analysis model for reengineering has been proposed by
Sneed [Sne95]. Nine parameters are defined:
1. P1 = current annual maintenance cost for an application.
2. P2 = current annual operation cost for an application.
3. P3 = current annual business value of an application.
4. P4 = predicted annual maintenance cost after reengineering.
5. P5 = predicted annual operations cost after reengineering.
6. P6 = predicted annual business value after reengineering.
7. P7 = estimated reengineering costs.
8. P8 = estimated reengineering calendar time.
9. P9 = reengineering risk factor (P9 = 1.0 is nominal).
10. L = expected life of the system.

Economics of Reengineering-II
• The cost associated with continuing maintenance of a candidate
application (i.e., reengineering is not performed) can be defined as
Cmaint = [P3 - (P1 + P2)] x L
• The costs associated with reengineering are defined using the
following relationship:
Creeng = [P6 - (P4 + P5) x (L - P8) - (P7 x P9)]
`
• Using the costs presented in equations above, the overall benefit of
reengineering can be computed as
cost benefit = Creeng - Cmaint

• Systematic examination of source code
• To find mistakes (logical and arithmetic errors)
- Logical error: program operates incorrectly but will not terminate
abnormally
- Arithmetic errors: When computer cannot handle problems (eg:-
division by zero)
• To improve the quality of the software
• Malware discovery- helps to find time bomb, Trojan horse etc.
• Code review is different from testing
• Testing – executable code
Code Review

1. Code walkthrough
2. Code inspection
3. Clean room testing
Code Review- Methods

• Informal
• Code will be shared to the team members
• Each member will selects some random test cases and trace the
code through hand simulation
• Logical errors can be identified efficiently
• The findings will be discussed in the walkthrough meeting
• Guidelines (even though it is a informal technique):
• Team should not be too large or too small (3-7)
• Main objective is discovery of errors avoid discussions on how to fix it
• Managers will not participate to ensure smooth discussion
Code Walkthrough

Code Inspection
• A formal, rigorous, in-depth code review process
• Best industry practice to improve the quality of the software
• Helps to find the problems at the earliest
• Helps verify that work product meets its requirement
• Ensure that the coding has been carried out based on the
predefined standards
• Helps to build technical knowledge skill among the team
members by reviewing the code developed other people
• Programmer may get feed back on choices of algorithms

Code Inspection- Roles
1. Author or owner:
• The programmer or designer responsible for producing the
program or document.
• Responsible for fixing defects discovered during the inspection
process.
2. Inspector:
• Finds errors, omissions and inconsistencies in programs and
documents.

Code Inspection- Roles
3. Reader:
• Presents the code or document at an inspection meeting.
4. Chairman or moderator:
• Manages the process and facilitates the inspection.
• Reports process results to the chief moderator.
5. Scribe:
• Records the results of the inspection meeting.
6. Chief moderator:
• Responsible for inspection process improvements, checklist
updating, standards development, etc.
• Not necessarily involved in all inspections.

Clean Room Testing
• Introduced by IBM
• Relies heavily on walkthroughs and code inspection
• Programmers are not allowed to test any of their code by
executing code
• Only syntax testing is allowed by using compiler
• Advantage:
- Produces code that is more reliable and maintainable
• Disadvantage:
- Time consuming – even to detect to simple errors
- Some errors can be easily detected during execution

Graph Matrices
• A graph matrix is a square matrix with one row and one
column for every node in the graph.
• The size of the matrix (i.e., the number of rows and columns)
is equal to the number of nodes in the flow graph.
• Some examples of graphs and associated matrices are shown
in fig.

Loop Testing-Simple Loop
• The following set of tests can be applied to simple
loops, where n is the maximum number of allowable
passes through the loop.
1. Skip the loop entirely. -0
2. Only one pass through the loop. 1
3. Two passes through the loop. 2
4. m passes through the loop where m <n. 50
5. n - 1, n, n+ 1 passes through the loop. 99,100,101

Loop Testing-Nested Loop
• The following set of tests can be applied to simple loops, where n is
the maximum number of allowable passes through the loop.
1. Start at the innermost loop. Set all other loops to minimum values.
2. Conduct simple loop tests for the innermost loop while holding the
outer loops at their minimum iteration parameter (e.g., loop
counter) values. Add other tests for out-of-range or excluded
values.
3. Work outward, conducting tests for the next loop, but keeping all
other outer loops at minimum values and other nested loops to
“typical” values.
4. Continue until all loops have been tested.

Loop Testing
• Concatenated loops. Concatenated loops can
be tested using the approach defined for simple
loops, if each of the loops is independent of the
other.
• Unstructured loops. Whenever possible, this
class of loops should be redesigned to reflect
the use of the structured programming
constructs.

Software Supportability
• “The capability of supporting a software system over its whole
product life.
– This implies satisfying any necessary needs or requirements, but
also the provision of equipment, support infrastructure,
additional software, facilities, manpower, or any other resource
required to maintain the software operational and capable of
satisfying its function.” [SSO08]
• The software should contain facilities to assist support personnel
when a defect is encountered in the operational environment (and
make no mistake, defects will be encountered).
• Support personnel should have access to a database that contains
records of all defects that have already been encountered—their
characteristics, cause, and cure.

Software Testing_A_mmmmmmmmmmmmmmmmmmmmm

Recommended

More Related Content

Similar to Software Testing_A_mmmmmmmmmmmmmmmmmmmmm (20)

Recently uploaded (20)

Software Testing_A_mmmmmmmmmmmmmmmmmmmmm