SOFTWARE TESTING

1
 Software Testing
• Set of activities conducted with intent of
finding errors in software
Goals of software testing:
• To find bugs and remove them as early as
possible
• Check if system does what it is expected to do

2
• Error : discrepancy between computed,
observed, or measured value
• Fault : incorrect step/ process /data definition
in a computer program which causes program
to perform in unintended manner.
• Failure: inability of a system / component to
perform its required functions within specified
performance requirements

3
Common causes of failure or defects in system:
• Missing requirements
• Incorrect programming/ design specifications
• Faulty implementation
• Compatibility issues

4
 V & V(Verification and Validation)
Verification:
• Set of activities to check whether software correctly
implements functions or algorithms
• Are we building the product right?
Validation:
• Confirming that software meets customer’s requirements
• Set of activities to ensure software that has been built is
traceable to customer requirements
• Are we building the right product?

5
 Issues to be addressed for successful
testing
1. State testing objective
2. Understand users of software and develop
profile for each user category
3. Develop testing plan for rapid cycle testing
4. Use Formal Technical Reviews
5. Develop continous improvement approach

6
 Software Testing Strategy for
Conventional Software Architecture
System Testing
Validation Testing
Integration Testing
Unit Testing

Code
Design

Requirements
System Engineering

7
 Testing Strategy
There are various levels of Testing for Conventional Software
1.Unit testing
• Testing each unit(component) i.e. particular function or code
modules

– Concentrates on each component/function of the software as

implemented in the source code
2.Integration testing
• Testing combined parts of application to determine their functional
correctness( i.e. to check that communication between units is proper
or not)

– Focuses on the design and construction of the software architecture

8
3. Validation testing
– Requirements are validated against the constructed software

4. System testing
– The software and other system elements are tested as a whole

9
 System Engineering
• Defines role of software and leads to software
requirement analysis where information
domain, function, behavior, constraints,
validation criteria for software are established.

10
Types of Integration Testing

»Big Bang testing

»Top Down Integration testing

»Bottom Up Integration testing

 1. Big Bang Integration
• Non-incremental strategy
– Unit test each module in isolation, Integrate as a
whole
– software elements, hardware elements, or both
are combined into a component or overall system,
test
rather than in stages main
test
A
main test
B test
test main, A, B, C
A B C C D, E, F
test
D
D E F test
E
test
F
 2. Top-down Integration
• Incremental strategy
1. Start by including highest level
modules in test set. test
• All other modules replaced by main
stubs or mock objects.
2. Integrate (i.e. replace stub by real
module) modules called by called by test
modules in test set. main, A,
3. Repeat until all modules in test set. B,C

main
test
main, A, B, C
D, E, F
A B C

D E F
 Top-down Integration
• Advantages
– Fault localization easier
– Few or no drivers needed
-Major design flaws found first

• Disadvantages
– Need lot of stubs / mock objects
 3. Bottom-up Integration
• Incremental strategy
– Test low-level modules
– Modules calling them until highest level module

test
D test
main D,E,A

test test
A B C test
E main, A, B,
B
C
D, E, F
D E F
test test
F C,F
 Bottom-up Integration
• Advantages
– Fault localization easier (than big-bang)
– No need for stubs / fewer mock objects
– Logic modules tested thoroughly
– Testing can be in parallel with implementation
• Disadvantages
– Need drivers
– High-level modules tested in the last (and least)
 Stub and Driver
Stub means a Dummy model of a particular module.
Suppose we have to test the interface between 2 modules A and B and we have
developed only module A while Module B is yet in development stage.
So in such case we can not test module A but, if we prepare a dummy module,
having similar features like B then using that we can test module A.
Our main aim in this is to test Module A & not Module B so that we can save time
otherwise we have to wait till the module B is actually developed.

Hence this dummy module B is called as Stub.

Now module B cannot send/receive data from module A directly/automatically so,

in such case we have to transfer data from one module to another module by
some external features. This external feature used is called Driver.
 Sandwich testing
• Combination of Top-down and bottom-up
integration

18
 Regression Testing
• To determine whether a change in one part of the software
affects other parts of the software

• To ensure that a change/ bug fix or addition of new module

did not introduce new faults.
[It is different from Re-testing, because in retesting, we test
certain part of application again, not concerning how it affects
other parts of software.]
 Smoke Testing
• Software components are integrated into
“Build”
• Build contains Data files, libraries and
reusable components
• Build is integrated with other builds, and
entire product is smoke tested daily.

20
 3. Validation Testing:

i. Validation Test Criteria

ii. Configuration Review
iii. Alpha and Beta Testing

21
 Validation Testing

• Test whether software works in manner

that is expected by customer.
• Expectations are defined in SRS(Software
Requirement Specification)

22
(i) It Contains Validation Test Criteria:
i.e. Test Plan, Test procedure
To ensure correct documentation, all
functional requirements, behavioral
characteristics, compatibility,
maintainability, error recovery.. E.t.c e.t.c

After validation testing, if any deviation/

error exists, then a “Deficiency list” is
created

23
 (ii) Configuration Review(Audit)
• To ensure all elements of software
configuration are properly designed and have
necessary details

24
 (iii) Alpha and Beta Testing
• Series of Acceptance Tests conducted to
enable customers to validate requirements.
• Alpha and Beta Testing are parts of
acceptance testing.
Alpha Testing: conducted at developer’s site
by end users in a controlled environment

25
 Beta Testing
• Conducted at end-users site.
• Developer is not present
• Software is released to a group of people and
they report the problems(if any) and suggest
feedback.

26
 4. System Testing
a) Recovery Testing
b) Security Testing
c) Stress Testing
d) Performance Testing

27
• System Testing: To verify system elements
are properly integrated and perform
allocated functions
a.) Recovery Testing: forcing software to fail
in different ways and verify whether it
recovers or not
b.) Security Testing: Testing the software’s
overall security (i.e. secure data, protect
system from attack/ hacking/ protecting
passwords…)

28
c.) Stress Testing
Executes system in a manner that demands
resources in abnormal quantity/ frequency/
volume.
e.g. giving more than desired interrupts

d.) Performance Testing

To test run-time performance of
software(performance requirements), e.g.
measure resource utilization
29