Software Engineering

(CSE1005)
Software Testing
MODULE - 3
 Software Testing – Introduction
Software Testing
• Computer programs are designed and developed by human beings and hence are
prone to errors.

• Unchecked, they can lead to a lot of problems, including social implications.

• Testing the software becomes an essential part of the software development

lifecycle.

• Carrying out the testing activities for projects has to be practiced with
proper planning and must be implemented correctly.
 Testing
• One of the practical methods commonly used to detect the
presence of errors (failures) in a computer program is to test it
for a set of inputs.
The output
is correct?

I1, I2, I3, …, Our program

In, … Expected results
=?
Obtained results

- No code inspection - No code analysis

- No model checking - No bug fixing
- No debugging
“Inputs”
 Software
What is Testing?
Testing – Introduction
Many people understand many definitions of testing :

• Testing is the process of demonstrating that errors are not present.

• The purpose of testing is to show that a program performs its

intended functions correctly.

• Testing is the process of establishing confidence that a program does

what it is supposed to do.

Some experts said these definitions are incorrect.

 Software Testing – Introduction
Myer’s Definition on Software Testing

• The process of executing a program or a system with the intent of finding errors.

• Testing is an activity that requires skilled people.

• Sound testing process is essential for good testing.

• It is an era of software testing tools.

• Need for a skilled test manager to look after testing.

Dijkstra:

“Testing can show the presence of bugs but never their absence.”
 Software Testing – Introduction
▪ Definition 1:-Software testing can be stated as a process of validating and
verifying that a software program or application or product,

[Link] the business and technical requirements that guided its design and
development, and

2. Works as expected.

3. Can be implemented with the same characteristics.

▪ Definition 2:- It is a process used to identify the correctness, completeness and

quality of developed computer software. It includes a set of activities conducted
with the intent of finding errors in software so that they could be corrected
before the product is released to the end users.
 What is a Test?
• Test is a formal activity. It involves a strategy
and a systematic approach. The different stages
of tests supplement each other. Tests are always
specified and recorded.

• Test is a planned activity. The workflow and

the expected results are specified. Therefore
the duration of the activities can be estimated.
The point in time where tests are executed is
defined
• The test is the formal proof of software
quality
 Most Common Software Problems
• Incorrect calculation

• Incorrect data edits & ineffective data edits

• Incorrect matching and merging of data

• Data searches that yield incorrect results

• Incorrect processing of data relationship

•Incorrect coding/implementation of business rules

•Inadequate software performance

 Most Common Software Problems Cont’d
• Confusing or misleading data
• Software usability by end users & Obsolete Software
• Inconsistent processing
• Unreliable results or performance
• Inadequate support of business needs
• Incorrect or inadequate interfaces with other systems file
• Inadequate performance and security controls Incorrect
handling
 Need of Software Testing
• Executing a program with the intent of finding an error.

• To check if the system meets the requirements and be executed successfully in the

Intended environment.

• To check if the system is “ Fit for purpose”.

• 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 is not redundant.

• A good test should be “best of breed”.

• A good test should neither be too simple nor too complex.

 Quality Software Should be
• Bug Free • Can be web-enabled
• Delivered on time • Adaptable to various OS like Unix,
Linux, etc
• complete
• Can run on notepads, PCs, and
• Within budget
Mainframes as per customer
• Meet the requirement of
requirements.
the customer.
• Documented
• Easy to maintain and
upgrade whenever needed. • Consistency
KumaS
Dr. Selva• r S (e
Scoc
peu
- Vr
ITAe
P)d
 Theory and Reality
• Theory
• Need sufficient time
• Baselined & freezed requirement
• Automation testing
• Have trained tester: test process, business flow…

• Reality
• Time pressure to keep the delivery date
• Continuously updated requirements
• Don’t know when to stop: update & update requirement continuously(CRs)-> Tester Updates TC and
re-tests
• Manual testing
• Lack of dedicated software test environment; share, steal
• Inexperienced testers without appropriate training
 Why is testing important

• To find and correct defects

• To check whether the client/user needs are satisfied

• To avoid user detecting problems

• Also to provide a quality product

• Provide confidence in the system

• To provide sufficient information to allow an objective decision on
applicability to deploy
 Why is Testing Important – Example 1

In April 2015, the Bloomberg terminal in London crashed due to a software glitch that
affected more than 300,000 traders in financial markets. It forced the government to
postpone a 3bn pound debt sale.
 Why is Testing Important – Example 2

In May 2015, Airbus issued an alert for urgently checking its A400M aircraft when a report detected a
software bug that had caused a fatal crash earlier in Spain. Prior to this alert, a test flight in Seville has
caused the death of four air force crew members and two were left injured.
 Why is Testing Important – Example 3

For over 2 years Nissan recalled over a million cars, thanks to a software glitch in the airbag sensory
detectors. Practically, the affected cars were unable to assess whether an adult was seated in the
car’s passenger seat and consequently would not inflate the airbags in case of a crisis.
Dr. Selva Kumar S (Scope - VITAP)
 Why is Testing Important – Example 4

In July 2015, The New York Stock Exchange stopped trading due to an undisclosed ‘internal technical
issue’, where all open orders were cancelled and the traders were alerted and informed that they
would receive information later. While responding to the shutdown, NYSE announced that there was no
cyber breach within the system and it [Link]
elve
a Kdumoap
r Se(r
Sca
opteio
- VnITsAPa
) fter 4 hours.
 Why does software have bugs
• Miscommunication or no communication

• Time pressure(Time Scheduling)

• Changing requirements

• Software complexity

• Programming mistakes
 What are the benefits of Software Testing
• Cost-Effective: It is one of the important advantages of software testing. Testing any IT
project on time helps you to save your money for the long term. In case the bugs are
caught in the earlier stage of software testing, it costs less to fix.

• Security: It is the most vulnerable and sensitive benefit of software testing. People are
looking for trusted products. It helps in removing risks and problems earlier.

• Product quality: It is an essential requirement of any software product. Testing ensures a

quality product is delivered to customers.

• Customer Satisfaction: The main aim of any product is to give satisfaction to its
customers. UI/UX Testing ensures the best user experience.
 Skills required to become a Software
Tester
Passion
Verbal and Written Communication

Analytical skills Good Verbal and Written Communication

Software
Tester
Attitude
Time Management & Organization Skills

Productivity
Strategic Approach to
Software Testing

Dr. Selva Kumar S (Scope- VITAP University)

 Software Testing
• What is it?
• Software is tested to uncover errors that were made inadvertently as it was designed and constructed.

• Who does it?

• A strategy for software testing is developed by the project manager, software engineers, and testing specialists

• Why is it important?
• Testing often accounts for more project effort than any other software engineering action.

• What are the steps?

• Testing begins “in the small” and progresses “to the large.”

• What is the work product?

• A Test Specification document

• How do I ensure that I’ve done it right?

• By reviewing the Test Specification prior to the testing, you can access the completeness of test cases and testing
task.
A Strategic Approach to Software Testing
• Testing is a set of activities that can be planned in advance and
conducted systematically.
All testing strategies have the following characteristics
• Testing proceeds in an outward manner. It starts from testing the individual units,
progresses to integrating these units, and finally, moves to system testing.
• Testing techniques used during different phases of software development are
different.
• Testing is conducted by the software developer and by an ITG(independent test group).
• Testing and debugging should not be used synonymously. However, any testing strategy
must accommodate debugging itself.

Software testing must be planned carefully to avoid wasting development time and resources.
 Common Types of Software Testing
Strategies
• There are different types of software testing strategies, which are selected by the
testers depending upon the nature and size of the software.

Analytic testing strategy

Philosophical testing strategy Model-based testing strategy

Software
Testing
Strategies

Dynamic testing strategy Methodical testing strategy

Process-oriented testing strategy

 Types of Software Testing Strategies
• Analytic testing strategy: This uses formal and informal techniques to access and
prioritize risks that arise during software testing. It takes a complete overview of
requirements, design, and implementation of objects to determine the motive of
testing. In addition, it gathers complete information about the software, targets to
be achieved, and the data required for testing the software.

• Model-based testing strategy: This strategy tests the functionality of the software
according to the real-world scenario (like software functioning in an organization). It
recognizes the domain of data and selects suitable test cases according to the
probability of errors in that domain.
 Types of Software Testing Strategies
• Methodical testing strategy: It tests the functions and status of
software according to the checklist, which is based on user
requirements. This strategy is also used to test the functionality,
reliability, usability, and performance of the software.

• Process-oriented testing strategy: It tests the software according to

already existing standards such as the IEEE standards. In addition, it
checks the functionality of the software by using automated testing
tools.
 Types of Software Testing Strategies
• Dynamic testing strategy: This tests the software after having a collective
decision of the testing team. Along with testing, this strategy provides
information about the software such as test cases used for testing the
errors present in it.

• Philosophical testing strategy: It tests the software assuming that any

component of the software can stop functioning anytime. It takes help from
software developers, users and systems analysts to test the software.
 Verification and Validation
Verification Validation
 Verification and Validation
• Verification and validation include a wide array of SQA activities:

• Technical reviews
• Algorithm analysis
• Quality and configuration audits
• Development testing
• Performance monitoring
• Usability testing
• Simulation
• Qualification testing
• Feasibility study
• Acceptance testing
• Documentation review
• Installation testing
• Database review
 Who Tests the Software

Independent Tester
Developer
• Understands the system • Must learn about the system,
but, will test "gently" but, but, will attempt to break it
is driven by "delivery" but, and, is driven by quality
Testing Strategy
Testing Strategy Cont’d
 Strategic Issues
• State testing objectives explicitly.

• Understand the users of the software and develop a profile for each user
category.

• Develop a testing plan that emphasizes “rapid cycle testing.”

• Build “robust” software that is designed to test itself.

• Use effective formal technical reviews as a filter prior to testing.

• Conduct formal technical reviews to assess the test strategy and test cases
themselves.

• Develop a continuous improvement approach for the testing process

 [Link] Testing
• Unit Testing is a type of software testing where individual units
or components of a software are tested.

• The purpose is to validate that each unit of the software code

performs as expected.

• Unit Testing is done during the development (coding phase) of

an application by the developers.

Unit Tests can also be performed by a White Box Tester.

 Unit Testing Cont’d
• Why perform Unit Testing?
• Unit tests help to fix bugs early in the development cycle and save
costs.
• It helps the developers to understand the testing code base and
enables them to make changes quickly.

• Good unit tests serve as project documentation.

• Unit tests help with code reuse. Migrate both your code and your
tests to your new project. Tweak the code until the tests run again.
Unit Testing Cont’d
Results

Module to be
Tested

Unit Test Cases

U_id001
U_id002
U_id003
U_id004
U_id005
U_id006
U_id007
Unit Testing Cont’d
Module to be
Tested Interface
local data structures
boundary conditions
Independent paths
Unit Test Cases
Error handling paths
U_id001
U_id002
U_id003
U_id004
U_id005
U_id006
U_id007
 Unit Test Environment
Driver
Interface
local data structures
boundary conditions
Module Independent paths
Unit Test Cases
Error handling paths
U_id001
U_id002
Sub- Sub- U_id003
Module Module
U_id004
U_id005
U_id006
U_id007
 Module Testing
• Module testing is primarily focused on testing software modules
or sub-program instead of testing the entire software
application at once.
 Difference between Module Testing vs Unit
Testing
No. Unit testing Module testing

Unit tests are a set of tests that Module tests are a set of tests
are written by a developer at the which are written by a tester after
1.
time of the software development coding has completed by a developer
process. for the particular module.

Unit Testing involves the testing Module testing involves the

2.
of units in isolation. combination of the units test.
 Advantages and Disadvantages of Unit
Testing
Advantages to Unit Testing
• The earlier a problem is identified, the fewer compound errors occur.

• Costs of fixing a problem early can quickly outweigh the cost of fixing
it later.

• Debugging processes are made easier.

• Developers can quickly make changes to the code base.

• Developers can also re-use code, migrating it to new projects

 Advantages and Disadvantages of Unit
Testing
Disadvantages
• Tests will not uncover every bug.
• Unit tests only test sets of data and its functionality—it will not catch
errors in integration.
• More lines of test code may need to be written to test one line of
code—creating a potential time investment.
• Unit testing may have a steep learning curve, for example, having to
learn how to use specific automated software tools.
 [Link] Testing Strategies

• Integration testing is a level of software testing where individual

units/components are combined and tested as a group.

• The purpose of this level of testing is to expose faults in the

interaction between integrated units. Test drivers and test stubs are
used to assist in Integration Testing.
 Why Integration Test
• Integrating disparate modules into a working application.

• Ensuring that changing requirements are incorporated into the

application.

• Eliminating common issues missed during unit testing.

• Eliminating other common problems.

Common Approaches to Integration
Testing
 Big Bang Integration Testing
• In Big Bang integration testing all components or modules are
integrated simultaneously, after which everything is tested as a
whole.

• In this approach individual modules are not integrated until and

unless all the modules are ready.

• In Big Bang integration testing all the modules are integrated

without performing any integration testing and then it’s executed
to know whether all the integrated modules are working fine or not.
Big Bang Integration Testing Cont’d
• Big Bang Integration Testing is
an approach in which all software
components (modules) are
combined at once and make a
complicated system.

• This form of integration

testing works well for smaller
systems.
 Big Bang Integration Testing Cont’d
Big Bang Testing Advantages

• The whole system is tested

• Requires minor planning

• Consists of completed and checked modules

• There is no demand for urgent build fixings

• Suitable for small systems

 Big Bang Integration Testing Cont’d
Big Bang Testing Drawbacks
• It is hard to separate modules when the bug is detected.

• Ineffective for large systems.

• High risk to miss some crucial issues while testing the whole system.

• Failures occur more frequently because of the simultaneous check of

numerous modules.

• A single mistake can influence the results of the whole integration

testing.
 Incremental Testing Approach
• This form of integration testing is performed on logically related
modules combined in a unit.

• All modules are added one by one in the testing unit until testers
cover the entire system.

• Incremental testing often uses stubs and drivers as some modules

are still in their development phase.

• Stubs and drivers are the dummy programs that don’t implement the
logic but helps in establishing communication.
 Incremental Testing Approach
[Link]-down Testing
• The testing is done from top to bottom as per the
architectural structure or control flow.

• Here, only the top module is unit tested in isolation, after

which, the lower modules are integrated one by one.

• This process is repeated until all the modules are

integrated and tested.

• The main module is used as a test driver and stubs are

substituted for all components directly subordinated to
the main control
 Incremental Testing Approach
Top-down Testing Advantages

• Easy fault localization

• Quick prototype design

• Prioritizing critical modules

• Easy and quick to find design flaws and fixed

Top-down Testing Drawbacks

• The only disadvantage of this approach is the lack of testing for lower-level modules
that are under development.
 Incremental Testing Approach
2. Bottom-up Testing
• This approach tests the lowest module
first in the architectural structure.

• The other modules are incrementally

added one by one for testing moving
upwards in the architectural structure.

• The control of flow in testing moves

from bottom to upwards.
 Incremental Testing Approach
Bottom-up Testing Advantages

• Easy to test and develop the product

• Efficient approach for integration testing

• Easy to create test conditions

Bottom-up Testing Drawbacks

• Test engineers cannot observe system-level functions from a partly integrated

system.
 Incremental Testing Approach
3. Sandwich approach (Hybrid Integration Testing)

• The sandwich approach involves testing the bottom and top

modules in the architectural structure of the software.

• In this approach, the middle layer (layer2) is the target

that the tester has to reach. The whole software system
is converted into three layers to begin the testing.

• First is the middle layer, the second is the layer above, and
the third is the layer below. The goal of a tester is to
reach the middle layer by testing both layers
simultaneously.
 Incremental Testing Approach
Sandwich Testing Advantages

• Sandwich Testing approach is used in very large projects having sub projects.

• It allows parallel testing

• Sandwich testing is the time-saving approach.

• Sandwich testing performs more coverage with same stubs

Sandwich Disadvantages
• Sandwich Testing is very costly.

• Sandwich Testing can not be used for such systems which have a lot of interdependence
between different modules.

• In sandwich testing the need of stubs and drivers is very high

Stubs and Drivers in Software Testing

Stub -It is called by the

Module under Test.

Driver -It is called by the

Module under Test.
 Difference between Stubs and Drivers
STUBS DRIVERS

Stubs used in Top Down Integration Drivers used in Bottom Up Integration

Testing Testing

Stubs are used when sub programs are Drivers are used when main programs are
under development under development

Top most module is tested first Lowest module is tested first

It can simulate the behavior of lower level It can simulate the behavior of upper
modules that are not integrated level modules that are not integrated

Stubs are called programs Drivers are the calling programs

[Link] Testing
 Regression Testing
• Regression testing is a process of making sure that a
program retains its core functionality when new updates are
introduced to its code.

• The purpose of regression testing is to confirm that a

recent program or code change has not adversely affected
existing features.
 Regression Testing Cont’d
Regression Testing is Required
When there is a

• Change in requirements and code is modified according to the requirement.

• The new feature is added to the software.

• Defect fixing.

• Performance issue fix.

Regression testing may be conducted manually, by re-executing a subset of all test cases or
using automated capture/playback tools
 Regression Testing Cont’d
Types of Regression Testing

Unit Regression Partial Regression

Complete Regression
 Regression Testing Cont’d
Regression Testing Techniques
 Regression Testing Cont’d
Advantages
• It improves the quality of the Product.

• This ensures that any bug fixes or enhancements that are done do not impact the existing
functionality of the Product.

• Automation tools can be used for this testing.

• This will ensure that issues that are already fixed do not occur again.

Disadvantages
• This has to be done for a small change in the code as well because even a small change in
the code can create issues in the existing functionality.

• If in case automation is not used in the Project for this testing, it will be a time-
consuming and tedious task to execute the test cases again and again.
 Regression Testing Cont’d
The difference between Retesting and Regression Testing
 Smoke Testing
Smoke Testing
• Smoke Testing is a type of software testing which is usually performed on
initial software builds to make sure that the critical functionalities of the
program are working absolutely fine.

SMOKE TESTING, also known

as “Build Verification Testing”,
 Smoke Testing
• The smoke tests qualify the build for further formal
testing.

• The main aim of smoke testing is to detect early major

issues. Smoke tests are designed to demonstrate system
stability and conformance to requirements.

• The build includes all data files, libraries, reusable modules,

and engineered components that are required to implement
one or more product functions.
 Sanity Testing
• Sanity testing is a subset of regression testing.
• After receiving the software build, sanity testing is performed
to ensure that the code changes introduced are working as
expected.

• This testing is a checkpoint to determine if testing for the

build can proceed or not.
 Object-Oriented Testing
• Whenever large-scale systems are designed, object-oriented
testing is done rather than the conventional testing strategies
as the concepts of object-oriented programming are way
different from that of conventional ones.

• The whole object-oriented testing revolves around the

fundamental entity known as “class”.
 Object-Oriented Testing
Unit Testing in the OO Context
• Class testing for OO software is the equivalent of unit testing for
conventional software.

• Unlike unit testing of conventional software, which tends to focus on

the algorithmic detail of a module and the data that flow across the
module interface, class testing for OO software is driven by the
operations encapsulated by the class and the state behavior of the
class.
 Object-Oriented Testing
Integration Testing in the OO Context
Thread-based testing
• Thread testing is a software testing technique that is used to test applications that are
client server-based.

• A thread is the flow of control in a process. It is the smallest task of the system that can
be run.

• Each thread is integrated and tested individually.

Use-based testing

• A technique that helps to identify test cases that cover the entire system, on a
transaction-by-transaction basis, from start to finish.
 How to test Web Application
• Functionality testing

• Usability testing

• Interface testing

• Compatibility testing

• Performance testing

• Security testing
 Test Strategies for WebApps
• The content model for the WebApp is reviewed to uncover errors.

• The interface model is reviewed to ensure that all use cases can be
accommodated.

• The design model for the WebApp is reviewed to uncover navigation

errors.

• The user interface is tested to uncover errors in presentation and/or

navigation mechanics.

• Each functional component is unit tested.

 Test Strategies for WebApps
• Navigation throughout the architecture is tested.
• The WebApp is implemented ina variety of different
environmental configurations and is tested for compatibility with
each configuration.

• Security tests are conducted.

• Performance tests are conducted.
• The WebApp is tested by a controlled and monitored population of
end users.
 [Link] Testing
• Validation-Test Criteria
• The function or performance characteristic conforms to specification and is accepted.

• A deviation from the specification is uncovered and a deficiency List is created

• Configuration Review (Audit)

• The intent of the review is to ensure that all elements of the software configuration
have been properly developed, are cataloged, and have the necessary detail to bolster
the support activities.

• Alpha and Beta Testing

 Validation Testing Cont’d
• Alpha Testing
• Alpha Testing is a type of acceptance testing; performed to identify all
possible issues and bugs before releasing the final product to the end
users.
• Beta Testing
• Beta Testing is performed by “real users” of the software application in
“real environment” and it can be considered a form of external User
Acceptance Testing.

• Alpha Testing is performed by the Testers within the organization whereas Beta Testing is
performed by the end users.
 [Link] Testing
Recovery Testing

Security Testing

Deployment Testing
System Testing

Stress Testing

Performance Testing
 System Testing
• Recovery testing is a system test that forces the software to fail in a variety
of ways and verifies that recovery is properly performed.

• Security testing attempts to verify that protection mechanisms built into a

system will, in fact, protect it from improper penetration.

• Stress testing executes a system in a manner that demands resources in

abnormal quantity, frequency, or volume (e.g. special tests may be designed
that generate ten interrupts per second, when one or two is the average rate).
Test Strategies for Conventional
Software
 Test Strategies for Conventional Software
The conventional applications, the software is tested from
two different perspectives:
• Internal program logic is exercised using “white box” test-case design
techniques.

• Software requirements are exercised using “black box” test-case design

techniques.

• Use cases assist in the design of tests to uncover errors at the software validation level.
 Software Testing Fundamentals
• Testability- Software testability is simply how easily [a computer program]
can be tested.

Operability
Understandability
Observability

Stability. Testability

Controllability

Simplicity Decomposability
 Software Testing Fundamentals Cont’d
Testability:
Operability - The better it works, the more efficiently it can be tested.

Observability - What you see is what you test.

Controllability - The better we can control the software, the more the testing can be automated
and optimized.
Decomposability - By controlling the scope of testing, we can more quickly isolate problems and
perform smarter retesting.

Simplicity - The less there is to test, the more quickly we can test it.

Stability - The fewer the changes, the fewer disruptions to testing.

Understandability - The more information we have, the smarter we will test.

Software Testing Fundamentals
Test Characteristics
• A good test has a high probability of finding an error.
• A good test is not redundant.
• A good test should be “best of breed”
• A good test should be neither too simple nor too complex.
 White-box Testing
• White-box testing sometimes called glass-box or structural testing

• White box testing is a testing technique, that examines the program structure and
derives test data from the program logic/code.

White Box Testing Techniques

• Path Coverage - This technique corresponds to testing all possible paths
which means that each statement and branch is covered.

• Statement Coverage - This technique is aimed at exercising all programming

statements with minimal tests.

• Branch Coverage (Control Structure )- This technique is running a series of

tests to ensure that all branches are tested at least once.
 [Link] Path Testing
• The basis path method enables the test-case designer to derive a logical
complexity measure of a procedural design and use this measure as a guide
for defining a basis set of execution paths.

• Test cases derived to exercise the basis set are guaranteed to execute
every statement in the program at least one time during testing.

Basis Path Testing Steps: • Construct the Control Flow Graph

• Compute the Cyclomatic Complexity of the Graph
• Identify the Independent Paths
• Design Test cases from Independent Paths
 [Link] Graph Notation

• Control flow depicts a program as a graph that consists of Nodes and Edges.

• In the graph, Nodes represent processing tasks while

edges represent control flow between the nodes.

Flow grah notation for a program

 Flow Graph Notation Cont’d
Control Flow Chart

First, we compute the cyclomatic

complexity:
Number of simple decisions + 1

or

Number of enclosed areas + 1

In this case, V(G) = 4

 Cyclomatic Complexity in Software Testing

• To understand Cyclomatic Complexity, lets first understand

What is Software Metric?

A software metric is defined as a quantitative measure of an attribute a software

system possesses with respect to Cost, Quality, Size, and Schedule.

Example

Measure - No. of Errors

Metrics - No. of Errors found per person
 Cyclomatic Complexity in Software Testing
Cont’d
• Cyclomatic Complexity in Software Testing is a testing metric used for
measuring the complexity of a software program.

• Cyclomatic complexity can be calculated by using control flow graphs or

with respect to functions, modules, methods or classes within a software
program.

This metric was developed by Thomas J.

McCabe in 1976
 How to Calculate Cyclomatic Complexity
Mathematical representation:
• Mathematically, it is a set of independent paths through the graph diagram.

•The Code complexity of the program can be defined using the formula:

Complexity is computed in one of three ways

1. The number of regions of the flow graph corresponds to the cyclomatic complexity.

2.V(G) = E - N + 2
3. V (G) = P + 1
Where,
Where,
E – Number of edges
P = Number of predicate nodes (node that contains condition)
N – Number of Nodes
 How to Calculate Cyclomatic Complexity
Control Flow Chart
Example
Cyclomatic Complexity
A = 10
IF B > C THEN
The graph shows seven
A=B
shapes(nodes), seven lines(edges),
ELSE hence cyclomatic complexity is 7-
A=C 7+2 = 2.

ENDIF

Print A

Print B

Print C
 How to Calculate Cyclomatic Complexity
Example Flow graph
i = 0;
n=4; //N-Number of nodes Cyclomatic Complexity
present in the graph

while (i<n-1) do V(G) = 9 – 7 + 2 = 4

j = i + 1; V(G) = 3 + 1 = 4 (Condition nodes are
while (j<n) do 1,2 and 3 nodes).

if A[i]<A[j] then Basis Set – A set of possible execution paths

swap(A[i], A[j]); of a program
Path1- 1, 7
end do;
j=j+1; Path2- 1, 2, 6, 1, 7
Path3- 1, 2, 3, 4, 5, 2, 6, 1, 7
end do;
Path4- 1, 2, 3, 5, 2, 6, 1, 7
 How to Calculate Cyclomatic Complexity

Control Flow Chart Control Flow graph

Cyclomatic Complexity

1. The flow graph has four regions.

2. V(G) 11 edges -9 nodes +2 = 4.

3. V(G) 3 predicate nodes + 1 = 4.

 Properties of Cyclomatic complexity
Following are the properties of Cyclomatic complexity

• V (G) is the maximum number of independent paths in the graph.

• V (G) >=1.

• G will have one path if V (G) = 1.

• Minimize complexity to 10

How this metric is useful for software testing

• It checks each linearly independent path through the program, which means the
number of test cases, will be equivalent to the cyclomatic complexity of the program.
 How Cyclomatic complexity metric is useful for
software testing
This metric is useful because of the properties of Cyclomatic complexity (M) –

1.M can be the number of test cases to achieve branch coverage (Upper Bound)

2.M can be the number of paths through the graphs. (Lower Bound)

Example

If (Condition 1) The Cyclomatic Complexity for this program will be 8-7+2=3.

Statement 1
Else • As complexity has been calculated as 3, three test cases are
Statement 2 necessary to complete path coverage.
If (Condition 2)
Statement 3
Else

Statement 4
The complexity number and corresponding meaning of v (G)
Complexity Number Meaning

1-10 Structured and well written code

High Testability
Cost and Effort is less

10-20 Complex Code

Medium Testability
Cost and effort is Medium

20-40 Very complex Code

Low Testability
Cost and Effort are high

>40 Not at all testable

Very high Cost and Effort
 Uses of Cyclomatic Complexity

Cyclomatic Complexity can prove to be very helpful in

• Helps developers and testers to determine independent path executions

• Developers can assure that all the paths have been tested atleast once

• Helps us to focus more on the uncovered paths

• Improve code coverage in Software Engineering

• Evaluate the risk associated with the application or program

• Using these metrics early in the cycle reduces more risk of the program
 Independent Program Paths
• An independent path is any path through the program that introduces at
least one new set of processing statements or a new condition.

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

Not independent path

Finally, after obtaining the independent paths, test cases can be designed where
Design Test Cases
each test case represents one or more independent paths.
 Graph Matrices
• The procedure for deriving the flow graph and even determining a set of
basis paths is amenable to mechanization.
• A data structure, called a graph matrix, can be quite useful for developing
a software tool that assists in basis path testing.

• The graph matrix is nothing more

than a tabular representation of a
flow graph.

• The graph matrix can become a

powerful tool for evaluating program
control structure during testing
 [Link] Structure Testing
• Control structure testing is a group of white-box testing methods.

• Control structure testing is used to increase the coverage area by

testing various control structures present in the program.

Control Structure Testing

Condition Testing Data Flow Testing Loop Testing

 Condition Testing
• Condition testing is a test case design method, which ensures that the
logical condition and decision statements are free from errors.

• The errors present in logical conditions can be incorrect Boolean

operators, missing parenthesis in a Booleans expression, errors in
relational operators, arithmetic expressions, and so on

Methods for Condition Testing

• Branch testing
 Data Flow Testing
• The data flow test method chooses the test path of a program based on
the locations of the definitions and uses all the variables in the
program.
• Data flow testing uses the control flow graph to detect illogical things
that can interrupt the flow of data.
• Anomalies in the flow of data are detected at the time of associations
between values and variables due to:

•If the variables are used without initialization.

•If the initialized variables are not used at least once.

 Loop Testing
• The loop testing completely focuses on the validity of the loop
constructs.

Loop Testing

Concatenated Unstructured
Simple loop Nested loop
loop loop
 Why do Loop Testing
• Testing can fix the loop repetition issues.

• Loops testing can reveal performance/capacity bottlenecks.

• By testing loops, the uninitialized variables in the loop can
be determined.

• It helps to identify loop initialization problems.

Types of loop Tested
 Loop Testing: Simple Loops

Minimum conditions—Simple Loops

• Skip the entire loop

• Make 1 pass through the loop

• Make 2 passes through the loop

• Make a passes through the loop where a<b, n is the maximum number
of passes through the loop

• Make b, b-1; b+1 passes through the loop where “b” is the maximum
number of allowable passes through the loop.
 Loop Testing: Nested Loops

• Adjust all the other loops to their minimum value and start
with the deepest loop.

• Start a simple loop test on the innermost loop and keep the
outside loops at their minimum iteration parameter value.

• Conduct the test for the following loop and make your way
outwards.

• Keep testing till reached the outermost loop.

 Concatenated and Unstructured
Loop
Concatenated Loop
• In the concatenated loops, if two loops are tested as independent of
each other then they both are tested using simple loops or else test
them as nested loops.

Unstructured Loop

• The unstructured loop is the combination of nested loops and

concatenated loops. It is basically a collection of loops that are in no
order.
Black-box Testing
 Black-box Testing
• Black Box Testing is also known as behavioral, opaque-box, closed-box,
specification-based or eye-to-eye testing.

• The main focus of Black Box Testing is on the functionality of the

system as a whole. The term ‘Behavioral Testing’ is also used for Black
Box Testing
 Black-box Testing

• This testing occurs throughout the Software Development and Testing Life
Cycle i.e in Unit, Integration, System, Acceptance, and Regression Testing
stages. This can be either Functional or Non-Functional.
Types of Black Box Testing

Functional Testing Non - Functional Testing

• Smoke Testing • Usability Testing

• Sanity Testing • Load Testing
• Integration Testing • Performance Testing
• System Testing • Compatibility Testing
• Regression Testing • Stress Testing
• User Acceptance Testing • Scalability Testing
 Black Box Testing Techniques

Equivalence Partitioning

Boundary Value Analysis

Decision Table Testing

Black Box Testing Techniques

State Transition Testing

Error Guessing

Graph-Based Testing Methods

Comparison Testing
 Black Box Testing Techniques Cont’d

1. Equivalence Partitioning
• This technique is also known as Equivalence Class Partitioning (ECP).
• In this technique, input values to the system or application are
divided into different classes or groups based on its similarity in the
outcome.

• This reduced the test cases to only 3 test

cases based on the formed classes thereby
covering all the possibilities.
 Black Box Testing Techniques Cont’d
[Link] Value Analysis
• Boundary testing is the process of testing between extreme ends or boundaries between
partitions of the input values.

• Boundary refers to values near the limit where the behavior of the system changes.

• In boundary value analysis, both valid and invalid inputs are being tested to verify the
issues. If we want to test a field where values from 1 to 100 should be
accepted,
then we choose the boundary values:
• 1-1,
• 1,
• 1+1,
• 100-1,
• 100,
• and 100+1.
Instead of using all the values from 1 to 100, we just use 0, 1, 2, 99, 100,
and 101.
 Black Box Testing Techniques Cont’d
3. Decision Table Testing

• A Decision Table is a tabular representation of inputs versus

• rules/cases/test conditions. It is a very effective tool
used for both complex software testing.

• A decision table helps to check all possible combinations of

conditions for testing and testers can also identify missed
conditions easily.
 Black Box Testing Techniques Cont’d

3. Decision Table Testing Cont’d

Example
• The condition is simple if the user provides the correct
username and password the user will be redirected to the
homepage.
• If any of the input is wrong, an error message will be
displayed.
 Black Box Testing Techniques Cont’d

4. State Transition Testing

• State Transition Testing is a technique that is used to test the

different states of the system under test.

• The state of the system changes depending upon the conditions or

events.

• The events trigger states which become scenarios and a tester needs to
test them.
 Black Box Testing Techniques Cont’d

4. State Transition Testing Cont’d

• A systematic state transition diagram gives

a clear view of the state changes but it is
effective for simpler applications.

• More complex projects may lead to more

complex transition diagrams thereby making
them less effective.
 Black Box Testing Techniques Cont’d
5. Error Guessing
• This is a classic example of Experience-Based Testing.

• The tester can use his/her experience with the application behavior and
functionalities to guess the error-prone areas.

• Many defects can be found using error guessing where most of the
developers usually make mistakes.
•Divide by zero.
Examples •Handling null values in text fields.
•Accepting the Submit button without any value.
•File upload without attachment.
File upload with less than or more than the limit size.
 Black Box Testing Techniques Cont’d
6. Graph-Based Testing Methods

• Each and every application is a build-up of some objects.

• All such objects are identified and the graph is prepared.

• From this object graph, each object relationship is identified and test
cases are written accordingly to discover the errors.

• It is a helpful technique to understand the software’s functional

performance, as it visualizes the flow of inputs and outputs in a lively
fashion.
 Black Box Testing Techniques Cont’d
6. Graph-Based Testing Methods

The graph could represent

• Control flow through a program

• Data flow between variables

• An activity diagram, showing the workflow when a user interacts with the system

• A state diagram, showing the states of a system and transitions between them
 Black Box Testing Techniques Cont’d
Graph-Based Testing Methods -Major Steps

• Step 1: Build a graph model

– What information is to be captured, and how to represent that
information?
• Step 2: Identify test requirements (TR)
– A test requirement is a structural entity in the graph model that
must be covered during testing

• Step 3: Select test paths to cover those requirements

• Step 4: Derive test data so that the test paths can be executed
Black Box Testing Techniques Cont’d

Graph notation

Sample Example
 Comparison Testing
• Comparison testing identifies the strengths and weaknesses of
a software product against other software products that
already exist in the market and are readily used by the target
audience.

• A comparison test will help you understand whether or not your

software project will be a marketable one after its commercial
release.
 When Comparison Testing is Performed
• Early stage of the software development process.
• Changes in business requirements or design of software products can be captured in
the early stages.

• Mid-stage of the software development process

• User Interface elements and behaviour of each functionality of software product can
be compared and improved in this stage of the software development process.

• End of the software development process

• Quality, processing speed, and support of hardware and software to run products can
be evaluated alongside the critical business objectives in the last stage.
 Orthogonal Array Testing
• The orthogonal Array Testing technique is a statistical approach for
testing pair-wise interactions.

• Most of the defects which I have observed are caused due to

interaction and integration.

• This interaction or integration can be within different objects,

elements, options on a screen of the application, or configuration
settings in a file.

• So, OAT is useful to test a large number of possible input combinations.

• It uses a very less number of Test cases.

 Orthogonal Array Testing

Terminologies in Orthogonal Array Testing

LRuns (Levels Factors)

• Runs It is the number of rows that represents the number of test conditions to be
performed.

• Factors It is the number of columns that represent in the number of variables to be tested

• Levels It represents the number of values for a Factor

 Orthogonal Array Testing Cont’d
• The orthogonal array testing method is particularly useful in finding region faults—an
error category associated with faulty logic within a software component.
Example 1

A Web page has three distinct sections (Top, Left, Right)

that can be individually shown or hidden from a user

No of Factors = 3 (Top, Left, Right)

No of Levels (Visibility) = 2 (Hidden or Shown)

Array Type = L4(23) The orthogonal array we can test

For traditional testing, we need to write 8 Test cases
Difference Between White Box Testing and Black
Box Testing
 White Box Testing
Black Box Testing

• It is a testing method without having knowledge • It is a testing method having knowledge about
about the actual code or internal structure of the actual code and internal structure of the
the application. application.

• This is a higher level testing such as functional • This type of testing is performed at a lower
testing. level of testing such as Unit Testing,
Integration Testing.

• It concentrates on the functionality of the • It concentrates on the actual code – program

system under test. and its syntax's.

• Black box testing requires Requirement • White Box testing requires Design documents
specification to test. with data flow diagrams, flowcharts etc.

• Black box testing is done by the testers. • White box testing is done by Developers or
tester with programming knowledge.
 Model-based Testing
• The model-based testing technique uses UML state diagrams
The MBT technique requires five steps

1. Analyze an existing behavioral model for the software or create one.

2. Traverse the behavioral model and specify the inputs that will force the software to
make the transition from state to state.

3. Review the behavioral model and note the expected outputs as the software makes the
transition from state to state.

4. Execute the test cases.

5. Compare actual and expected results and take corrective action as required
 The Art of Debugging

Debugging: A Diagnostic Process

 The Debugging Process
• Debugging is the process that results in the removal of the error.

• Debugging occurs as a consequence of successful testing.

 Origin of “debugging”

The “first computer bug” –Grace Hopper,

working on one of the first electronic
computers (Harvard Mark II, 1945)
–Machine failed and operator found a moth
caught in a relay –Taped into log book with
note: “First actual case of bug found”
The Debugging Process Cont’d
The debugging process will usually have one of two outcomes:
• The cause will be found and corrected or

• The cause will not be found. In the latter case, the person
performing debugging may suspect a cause, design a test case
to help validate that suspicion and work toward error
correction in an iterative fashion.

“if debugging is defined as the art of taking bugs out of a program,

programming must be the art of putting them in –Dijkstra
The Debugging Process Cont’d
• Debugging and testing are
complementary processes.

• The purpose of testing is to

identify what happens when
there is a mistake in a program's
source code.

• The purpose of debugging is to

locate and fix the mistake.
 Debugging Effort

Time required to
Time required to diagnose
correct the error and
the symptom and determine
conduct regression
the cause
tests
 Why is debugging difficult?
• Debugging is one of the more frustrating parts of
programming. It has elements of problem-solving or brain
teasers, coupled with the annoying recognition that you have
made a mistake.

• Cause and effect may be hard to connect (remote in time/space)

• Symptoms may seem random (the result of 2 bugs interacting)

• Complex interactions

• Psychological issues: frustration, pressure, guilt

 Symptoms & Causes
• 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

• The symptom may be caused by human error symptom

that is not easily traced.
cause
• The symptom may be intermittent

• The symptom may be a result of timing problems

 Debugging Strategies
• The brute force category of debugging is
Brute force probably the most common and least
efficient method

backtracking • Backtracking is a fairly common debugging

approach
Debugging
Strategies
induction
• Induction or deduction and introduces the
concept of binary partitioning

deduction
 Correcting the Error
Once a bug has
been found, it must
be corrected
• Three simple questions that you should ask before making the
“correction” that removes the cause of a bug.

Is the cause of the bug reproduced in another part of the program?

What “next bug” might be introduced by the fix I’m about to make?

What could we have done to prevent this bug in the first place?
 Verification and Validation

Verification & Validation Activities (V&V):

V&V activities can be best understood with the help of phases of SDLC activities:
Requirements Gathering: It is an essential part of any project and project management.
Understanding fully what a project will deliver is critical to its success.
Requirement Speciation or Objectives: Software Requirements Specification (SRS) is
a description of a software system to be developed, laying out functional and non-functional
requirements, and may include a set of use cases that describe interactions the users will
have with the software. Software requirements specification establishes the basis for an
agreement between customers and contractors or suppliers on what the software product
is to do as well as what it is not expected to do.

Page
143
High Level Design (HLD) or Functional Design: A functional design assures that each modular part of a device has only one responsibility and performs
that responsibility with the minimum of side effects on other parts. Functionally designed modules tend to have low coupling. High-level design (HLD)
explains the architecture that would be used for developing a software product. The architecture diagram provides an overview of an entire system,
identifying the main components that would be developed for the product and their interfaces. The HLD uses possibly nontechnical to mildly technical
terms that should be understandable to the administrators of the system.

Low-Level Design (LLD): It is a component-level design process that follows a step-by- step refinement process. This process can be used for designing
data structures, required software architecture, source code and ultimately, performance algorithms. Overall, the data organization may be defined
during requirement analysis and then refined during data design work. Post-build, each component is specified in detail. The LLD phase is the stage
where the actual software components are designed.
Coding: The goal of the coding phase is to translate the design of the system into code in a given programming language. The coding phase affects both
testing and maintenance profoundly. A well written code reduces the testing and maintenance effort. Since the testing and maintenance cost of software
are much higher than the coding cost, the goal of coding should be to reduce the testing and maintenance effort. Hence, during coding the focus should be
on developing programs that are easy to write. Simplicity and clarity should be strived for, during the coding phase.

Verification: Verification is done at the starting of the development process. It includes reviews and meetings, walkthroughs, inspection, etc. to evaluate
documents, plans, code, requirements and specifications.
It answers the questions like:
--Am I building the product right?
--It is a Low level activity
-- Am I accessing the data right (in the right place; in the right way).
According to the Capability Maturity Model (CMMI-SW v1.1) we can also define verification as “the process of evaluating software to determine whether
the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD- 610]”.
Advantages of Software Verification:
--Verification helps in lowering down the count of the defect in the later stages of development.
--Verifying the product at the starting phase of the development will help in understanding the product in a better way.

--It reduces the chances of failures in the software application or product.

--it helps in building the product as per the customer specifications and needs.

Page
144
The goals of verification are:
--Everything must be verified.
--Results of the verification may not be binary.
--Even implicit qualities must be verified.
Verification of Requirements:
In this type of verification, all the requirements gathered from the users viewpoint are verified. For this purpose, an acceptance criterion is prepared. An acceptance
criterion defines the goals and requirements of the proposed system and acceptance limits for each of the goals and requirements.
The tester’s works in parallel by performing the following two tasks:
[Link] tester reviews the acceptance criteria in terms of its completeness, clarity and testability.
[Link] tester prepares the Acceptance Test Plan which is referred at the time of Acceptance Testing.

Verification of Objectives: After gathering of objectives specific objectives are prepared considering every specification. These objectives are prepared in a document
called SRS. In this activity the tester performs two parallel activities:
[Link] tester verifies all the objectives mentioned in SRS.
[Link] tester also prepares the System Test Plan which is based on SRS.

How to verify Requirements and Objectives:

An SRS is verifiable if, and only if, every requirement stated therein is verifiable. A requirement is verifiable if, and only if, there exists some finite cost-effective process
with which a person or machine can check that the software product meets the requirement. In
general any ambiguous requirement is not verifiable. Non verifiable requirements include statements such as “works well", “good human interface", and “shall usually
happen". These requirements cannot be verified because it is impossible to define the terms “good", “well",
or “usually". Anexample of a verifiable statement is “Output of the program shall be produced within 20 s of event x 60% of the time; and shall be produced
within 30 s of
event x 100% of the time". This statement can be verified because it uses concrete terms and measurable quantities. If a method cannot be devised to determine
whether the
software meets a particular requirement, then that requirement should be removed or
revised. Following are the points against which every requirement in SRS should be verified.
Correctness: An SRS is correct if, and only if, every requirement stated therein is one
that the software shall meet. However, generally speaking there is no tool or procedure to ensure correctness. That’s why the SRS should be compared to superior
documents (including the System Requirements Specification, if exists) during a review process in order to filter out possible contradictions and inconsistencies.
Reviews should also be used to get a feedback from the customer side on whether the SRS correctly reflects the actual needs. This process can be made easier and less
error-prone by traceability.

Unambiguity: An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic
of the final
product be described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term should be included in a
glossary where its meaning is made more specific.
Completeness: An SRS is complete if, and only if, it includes the following elements:
--All significant requirements imposed by a system specification should be acknowledged and treated.
--Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
However, completeness is very hard to achieve, especially when talking about business systems where the requirements always change
and new requirements raise.

Consistency: Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system
requirements specification, then it is a violation of correctness. An SRS is internally consistent if, and only if, no subset of individual
requirements described in it conflict. The three types of likely conflicts in an SRS are as follows:

--The specified characteristics of real-world objects may conflict. For example, the format of an output report may be described in one
requirement as tabular but in another as textual or one requirement may state that all lights shall be green while another may state that
all lights shall be blue.

--There may be logical or temporal conflict between two specified actions. For example, one requirement may specify that the program
will add two inputs and another may specify that the program will multiply them or one requirement may state that “A" must always
follow “B", while another may require that “A and B" occur simultaneously.

--Two or more requirements may describe the same real-world object but use different terms for that object. For example, a program’s
request for a user input may be called a “prompt" in one requirement and a “cue" in another. The use of standard terminology and
definitions promotes consistency.

Modifiability or Updation: An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can
be made easily, completely, and consistently while retaining the structure and [Link] generally requires an SRS to
[Link] a coherent and easy-to-use organization with a table of contents, an index, and explicit cross-referencing;
[Link] be redundant (i.e., the same requirement should not appear in more than one place in the SRS);
[Link] each requirement separately,rather than intermixed with other requirements.
Traceability: An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in
future development or enhancement documentation. The following two types of traceability are recommended:
[Link] traceability (i.e., to previous stages of development). This depends upon each requirement explicitly referencing its
source in earlier documents.
[Link] traceability (i.e., to all documents spawned by the SRS). This depends upon each requirement in the SRS having a unique
name or reference number.
Verification of High Level Design:
Like the verification of requirements, the tester is responsible for two parallel activities in this place as well:
[Link] tester verifies the high level design. Since the system has been decomposed in a number of sub-system or
components, the tester should verify the functionality of these components and their interfaces. Every requirement in
SRS should map the design.
[Link] tester also prepares a Function Test Plan which is based on the SRS. This plan will be referenced at the time of
Function Testing.

How to verify High Level Design:

Verification of Data Design
--Check whether sizes of data structure have been estimated appropriately.
--Check the provisions of overflow in a data structure.
--Check the consistency of data formats with the requirements.
--Check whether data usage is consistent with its declaration.
--Check the relationships among data objects in data dictionary.
--Check the consistency of databases and data warehouses with requirements in SRS.
Verification of Architectural Design
--Check whether all exceptions handling conditions have been taken care.
--Verify the process of transform mapping and transaction mapping used for transition from the requirement model
to architectural design.
--Check that every functional requirement in SRS has been take care in this design
--Check the functionality of each module according to the requirements specified.
--Check the inter-dependence and interface between the modules.
--Coupling and Module Cohesion.

Verification of User-Interface Design

--Check all the interfaces between modules according to architecture design.
--Check all the interfaces between software and other non-human producer and consumer of information.
--Check all the interfaces between human and computer.
--Check all the above interfaces for their consistency.
--Check that the response time for all the interfaces are within required ranges.
--Help Facility error messages and warnings.

Verification of Low Level Design (LLD):

In LLD, a detailed design of modules and data are prepared such that an operational software is ready. The details of
each module or units is prepared in their separate SRS and SDD (Software Design Documentation). Testers also
perform the following parallel activities in this phase:
--The tester verifies the LLD. The details and logic of each module is verified such that the high-level and low-level
abstractions are consistent.
--The tester also prepares the Unit Test Plan which will be referred at the time of Unit Testing.
How to verify Low Level Design(LLD)
--Verify the SRS of each module.
--Verify the SDD of each module.
In LLD, data structures, interfaces and algorithms are represented by design notations; so verify the consistency of every item with their
design notations.
How to verify Code:
Coding is the process of converting LLD specifications into a specific language. This is the last phase when we get tthe operational software
with the source code. Since LLD is converted into source code using some language, there is a possibility of deviation from the LLD. Therefore,
the code must also be verified. The points against which the code must be verified are:
--Check that every design specification in HLD and LLD has been coded using traceability matrix.
--Examine the code against a language specification checklist.
--Verify every statement, control structure, loop, and logic.
--Mixed mode operations
--Misunderstood or incorrect arithmetic precedence
--Incorrect symbolic representation of an expression.
--Improper or non-existent loop termination.
--Different data types
-Incorrect initialization
--Failure to exit.
Validation:
Validation is a set of activities that ensures the software under consideration has been built right and is traceable to customer requirements.
The reason for doing validation are:
--Developing tests that will determine whether the product satisfies the users’ requirements, as stated in the requirement specification.
--Developing tests that will determine whether the product’s actual behaviour matches the desired behaviour, as described in the functional
design specification.
--The bugs, which are still existing in the software after coding need to be uncovered.
--Last chance to discover the bugs otherwise these bugs will move to the final product released to the customer.
--Validation enhances the quality of software.
Validation Activities:
The Validation activities are divided into Validation Test Plan and Validation Test Execution which are described as follows:

Validation Test Plan: It starts as soon as the first output of SDLC i.e the SRS is prepared. In every phase, the tester performs two parallel
activities - Verification and Validation. For preparing a validation test plan, testers must follow the following points:
--Testers must understand the current SDLC phase.
--Testers must study the relevant documents in the corresponding SDLC phase.
--On the basis of the understanding of SDLC phase and related documents, testers must prepare the related test plans which are used at the
time of validation testing.
 The following test plans have been recognized which the testers have already prepared with the incremental progress of SDLC phases:

Acceptance Test Plan: The test plan document describes a series of operations to perform on the software. Whenever there is a visible change in the state of the
software (new window, change in the display, etc.) the test plan document asks the testers to observe the changes, and verify that they are as expected, with the
expected behaviour described precisely in the test plan.

System Test Plan: This plan i s prepared to verify the objectives specified in the SRS. The plan is used at the time of System Testing.

Function Test Plan: The functional test plan is not testing the underlying implementation of the application components. It is testing the application from the
customer's viewpoint. The functional test is concerned with how the application is meeting business requirements.
Integration Test Plan: Integration test planning is carried out during the design stage. An integration test plan is a collection of integration tests that focus
on functionality.
Unit Test Plan: This document describes the Test Plan in other words how the tests will be carried out. This will typically include the list of things to be Tested,
Roles and Responsibilities, prerequisites to begin Testing, Test Environment, Assumptions, what to do after a test is successfully carried out, what to do if test
fails, Glossary and so on.
Validation Test Execution:

Unit Validation Testing:

A unit is the smallest testable part of an application like functions, classes, procedures, interfaces. Unit testing is a method by which individual units of source
code are tested to determine if they are fit for use.
--Unit tests are basically written and executed by software developers to make sure that code meets its design and requirements and behaves as expected.
--The goal of unit testing is to segregate each part of the program and test that the individual parts are working correctly.
--This means that for any function or procedure when a set of inputs are given then it should return the proper values. It should handle the failures gracefully
during the course of execution when any invalid input is given.
--A unit test provides a written contract that the piece of code must assure. Hence it has several benefits.
Integration Testing
: Integration testing tests integration or interfaces between
components, interactions to different parts of the system such as an operating system, file system and hardware or interfaces between systems
.
--Also after integrating two different components together we do the integration testing. As displayed in the image below when two different module
‘Module A’ and ‘Module B’ are integrated then the integration testing is done.
In system testing the behaviour of whole system/product is tested as defined by the scope of the development project or product.
--It may include tests based on risks and/or requirement specifications, business process, use cases, or other high level descriptions of system behaviour,
interactions with the operating systems, and system resources.
Functional Testing: Functional testing verifies that each function of the software application
operates in conformance with the requirement specification. This testing mainly involves black
box testing and it is not concerned about the source code of the application. Each and every
functionality of the system is tested by providing appropriate input, verifying the output and
comparing the actual results with the expected results. This testing involves checking of User
Interface, APIs, Database, security, client/ server applications and functionality of the Application
under Test. The testing can be done either manually or using automation

System Testing: System testing is most often the final test to verify that the system to be
delivered meets the specification and its purpose. System testing is carried out by specialists
testers or independent testers. System testing should investigate both functional and non-
functional requirements of the testing.

Acceptance testing: After the system test has corrected all or most defects, the system will be
delivered to the user or customer for acceptance testing. Acceptance testing is basically done by
the user or customer although other stakeholders may be involved as well. The goal of
acceptance testing is to establish confidence in the system. Acceptance testing is most often
focused on a validation type testing.

Dynamic Testing I
Black Box testing techniques: Boundary Value Analysis, Equivalence class Testing, State Table
based testing, Decision table based testing, Cause-Effect Graphing based testing, Error guessing

:Boundary Value Checking:

Test cases are designed by holding one variable at its extreme value and other variables
at their nominal values in the input domain. The variable at its extreme value can be
selected at:
--Minimum value (Min)
--Value just above the minimum value(Min+)
--Maximum value (Max)
--Value just below the maximum value (Max-)
Cause Effect Graphing Based Testing:

Cause and effect graph is a dynamic test case writing technique. Here causes are the input conditions and effects are the
results of those input conditions. Cause-Effect Graphing is a technique which starts with set of requirements and
determines the minimum possible test cases for maximum test coverage The goal is to reduce the total number of test
cases still achieving the desired application quality.
Disadvantage: It takes time to model all your requirements into this cause-effect graph before writing test cases.

The following process is used to derive the tes cases:

Division of specification: The specification is divided into workable pieces, as cause-effect graphing becomes complex when
used on large specifications.
Identification of causes and effects: A cause is a distinct input condition identified in the problem.

Transformation of specification into a cause-effect graph: Based on the analysis of the specification it is transformed into a
Boolean graph linking the causes and effects. This is the cause-effect graph.

Conversion into decision table: The cause-effect graph obtained is converted into a limited entry decision table by
verifying state conditions in the graph.

Deriving test cases: The columns in the decision table are converted into tst cases.

Basic Notations of Cause-Effect Graph:

Error Guessing:
Error Guessing is the preferred method when all the other methods
fail. It is a very practical case wherein the tester uses his intuition
and makes a guess about where the bug can be. The tester does not
have to use any particular testing technique. The basic idea is to
make a list of possible errors in error prone situations and then
develop the test cases. Thus there is no general procedure for this
technique as it is largely an intuitive and ad-hoc process.
 Software Testing

•Black box Testing

•White box testing

Software Testing

white-box black-box
methods methods

Methods

Strategies
White-Box Testing
Why Cover?
Basis Path Testing
First, we compute the cyclomatic
complexity:

number of simple decisions + 1

or

number of enclosed areas + 1

In this case, V(G) = 4

Cyclomatic Complexity
Basis Path Testing
Basis Path Testing Notes
Deriving Test Cases
◼ Summarizing:
◼ Using the design or code as a foundation, draw a
corresponding flow graph.
◼ Determine the cyclomatic complexity of the resultant
flow graph.
◼ Determine a basis set of linearly independent paths.
◼ Prepare test cases that will force execution of each
path in the basis set.
Graph Matrices
◼ A graph matrix is a square matrix whose size
(i.e., number of rows and columns) is equal to
the number of nodes on a flow graph
◼ Each row and column corresponds to an
identified node, and matrix entries correspond
to connections (an edge) between nodes.
◼ By adding a link weight to each matrix entry,
the graph matrix can become a powerful tool
for evaluating program control structure during
testing
Control Structure Testing
◼ Condition testing — a test case design method
that exercises the logical conditions contained
in a program module
◼ Data flow testing — selects test paths of a
program according to the locations of
definitions and uses of variables in the program
Data Flow Testing
◼ The data flow testing method selects test paths of a
program according to the locations of definitions and
uses of variables in the program.
◼ Assume that each statement in a program is assigned a
unique statement number and that each function does not
modify its parameters or global variables. For a statement
with S as its statement number
• DEF(S) = {X | statement S contains a definition of X}
• USE(S) = {X | statement S contains a use of X}
◼ A definition-use (DU) chain of variable X is of the form [X, S,
S'], where S and S' are statement numbers, X is in DEF(S)
and USE(S'), and the definition of X in statement S is live
at statement S'
Loop Testing
Loop Testing: Simple Loops
Loop Testing: Nested Loops
Black-Box Testing
Black-Box Testing
◼ How is functional validity tested?
◼ How is system behavior and performance tested?
◼ What classes of input will make good test cases?
◼ Is the system particularly sensitive to certain input
values?
◼ How are the boundaries of a data class isolated?
◼ What data rates and data volume can the system
tolerate?
◼ What effect will specific combinations of data have on
system operation?
Graph-Based Methods
object Directed link object
#1 (link weight) #2

Node weight
Undirected link
(value
)
Parallel links
object
#
3

(a)

new menu select generates document

file (generation time  1.0 sec) window

allows editing
of Attributes:
is represented as
contains
document background color: white
tex text color: default color
t or preferences

(b)
Equivalence Partitioning
Sample Equivalence Classes
Boundary Value Analysis
Comparison Testing
◼ Used only in situations in which the reliability of
software is absolutely critical (e.g., human-
rated systems)
◼ Separate software engineering teams develop
independent versions of an application using the
same specification
◼ Each version can be tested with the same test data
to ensure that all provide identical output
◼ Then all versions are executed in parallel with real-
time comparison of results to ensure consistency
Orthogonal Array Testing
◼ Used when the number of input parameters is
small and the values that each of the
parameters may take are clearly bounded

Z Z

Y Y
X X
One input item at a time L9 orthogonal array
Model-Based Testing
◼ Analyze an existing behavioral model for the software or create one.
◼ Recall that a behavioral model indicates how software will respond to external events or
stimuli.
◼ Traverse the behavioral model and specify the inputs that will force the software to make the
transition from state to state.
◼ The inputs will trigger events that will cause the transition to occur.
◼ Review the behavioral model and note the expected outputs as the software makes the
transition from state to state.
◼ Execute the test cases.
◼ Compare actual and expected results and take corrective action as required.
Software Testing Patterns
◼ Testing patterns are described in much the same way as
design patterns (Chapter 12).
◼ Example:
• Pattern name: ScenarioTesting
• Abstract: Once unit and integration tests have been conducted, there is a need to determine
whether the software will perform in a manner that satisfies users. The ScenarioTesting
pattern describes a technique for exercising the software from the user’s point of view. A
failure at this level indicates that the software has failed to meet a user visible requirement.
[Kan01]