Software

Testing

Dr. Naresh.E
Hardware Testing Vs Software Testing
Hardware Testing:
Will be taken very much care to implement and test the product
in the initial phase as the failure(after delivery) costs you more
and difficult to modify the hardware as per the customer needs.

Software Testing:
Over confident in the software engineers as they can meet
changing needs of the customer as and when required, increases
the opportunities for hiring software test engineers.

Hence, hardware Test engineers are very less compare to

software test engineer.

2
Why does software have bugs?
• Miscommunication or No communication
• Software Complexity
• Programming errors
• Time Pressures
• Changing requirements
• Poorly Documented Code

3
 Software Testing
Testing is the process of exercising a
program with the specific intent of finding
errors prior to delivery to the end user.
OR
[IEEE defn.]

Testing is the process of Verifying and/or

Validating an output against a set of
expectations and observing the variances.

4
 Who Tests the Software?

independent tester
Understands the system
Must learn about the system,
but, is inclined to test "gently"
but, will attempt to break it
and, is driven by "delivery"
and, is driven by quality.
Testability of a program is
tested here.

5
 Test Life Cycle
• Requirement Analysis – Setting test objectives and
requirements .
• Strategy and Planning – Determining risks and selecting
strategies.
• Design – Specifying test procedure, test scenarios and test cases
to be developed.
• Execution – Running and rerunning the tests.
• Reporting and Management – Tracking and updating the
progress of software tests.
• Analysis – Analyzing the test results and taking appropriate
corrective actions.

6
Activities of Test Engineers

7
Goal of Testing:
Design a series of tests that have a high
probability of finding errors prior to
delivery.

[ Maximum damage to the customer]

8
 What Testing Shows
- errors

- requirements conformance

- performance

- an indication
of quality
Testing can never
be used to show the
absence of errors,
only their presence.

9
 Basic Definitions
► Error – a conceptual mistake.
► Fault – the result of an error / Implemented error
Defect is a synonym of fault.
► Failure – occurs when a fault executes.
Observable behavior/failure.
► Test –exercising software with test cases.
► Test case – has an identity, associated with program
behavior, has a set of inputs, has a list of expected
outputs.
10
Errors, faults, failures

11
 Testing and debugging

Testing is the process of determining if a program

has any errors.

When testing reveals an error, the process used to

determine the cause of this error and to remove it,
is known as debugging.

12
 Principles of Testing
• Testing must find the largest number of errors in the least amount of time.

• Test case development should begin immediately after requirements

definition.

• Testing should begin in the small and progress to the large.

• Exhaustive testing is not possible.

• All tests must be traceable back to customer requirements.

• A good test is not redundant; every test serves a different purpose.

• Tests should be as simple as possible. A test should not attempt to uncover

multiple types of errors.

13
Characteristics that lead to testable software

•Operability: “the better it works , the more efficiently it can be

tested”

– The system has few bugs(bugs adds analysis and reporting

overhead to the test process)
– No bugs block execution of tests
– The product evolves in functional stages(allows simultaneous
development and testing)
• Observability: ”what you see is what you test”

– Distinct output is generated for each input

– System states and variables are visible or queriable
during execution. e.g.(transaction log)
– All factor affecting output are visible
– Incorrect output is easily identified
– Internal errors are automatically detected through self
testing mechanism
– Internal errors are automatically reported
– Source code is accessible
• Controllability : “The better we can control the software , the
more testing can be automated and optimized”

– All possible output can be generated through some

combination of input
– All code is executable through some combination of input
– Software and hardware states and variables can be
controlled directly by the test engineer
– Input and output formats are consistent and structured
– Test can be conveniently specified , automated and
reproduced
•Decomposability : “ By controlling the scope of testing , we
can more quickly isolate problems and perform smarter
retesting”.

– The software system is built from independent modules

– Software modules can be tested independently
• Simplicity : “The less there is to test more quickly we can
test it”

– Functional simplicity e.g. the feature set is the minimum

necessary to meet requirements
–Structural simplicity e.g. architecture is
modularized to limit the propagation of faults
– Code simplicity e.g. a coding standard is adopted for
ease of inspection and maintenance
• Stability : “the fewer the changes , the fewerthe disruptions
to testing”

– Changes to software are infrequent

– Changes to software are controlled
– Changes to software do not invalidate existing tests
– The software recover well from failures
• Understandability : “The more information wehave , the
smarter we will test”

– Design is well understood

– Dependencies between internal , external and shared
components are well understood.
– Changes to design are communicated
– Technical documentation is instantly accessible
– Technical documentation is well organized
– Technical documentation is specified and detailed
– Technical documentation is accurate
 Software development activities and testing levels
– the “V Model”.
Construction Phases

Destruction Phases
Static Activities Dynamic Activities

21
 Relationship – program behaviors

Program Behaviors

Specified Programmed
(expected) (observed)
Behavior Behavior Fault
Fault
of
of
Commission
Omission

Correct portion

22
Test Cases, Specs, and Programmed Behaviors

U
S P
S = Specified behaviors
2 P = Programmed behaviors
T = Tested behaviors
5 6 U = All possible behaviors

1
4 3 We want to make
region 1 as large
as possible.
7
T

23
Functional Test cases

Specified Programmed

Test
Cases

24
Functional Test cases after applying Functional
testing techniques

Specified Programmed

Test
Cases

25
Structural Test cases

Specified Programmed

Test
Cases

26
Structural Test cases after applying structural
testing techniques

Specified Programmed

Test
Cases

27
 Need for designing test cases
• Almost every non-trivial system has an extremely
large input data domain thereby making exhaustive
testing impractical
• If randomly selected then test case may loose
significance since it may expose an already
detected error by some other test case
• Number of test cases do not determine the
effectiveness
• Each test case should detect different errors

28
Test Case format

29
Defect Life Cycle

30
Defect Report

31
 Examples

• Triangle Problem
• NextDate function
• CurrencyConvertor Problem
• SATM Problem
• Commission Problem

32
 Triangle Problem
The Triangle Program accepts three integers as input; these are taken to be
sides of a triangle.

The output of the program is the type of triangle determined by the three
sides: Equilateral, Isosceles, Scalene, or NotATriangle.

Sometimes this problem is extended to include right triangles as a fifth type;

we will use this extension in some of the exercises.

a < b + c,
b < a + c, and
c < a + b.
If any one of these fails to be true, then integers a, b, and c do not constitute
sides of a triangle.

33
 NextDate function

NextDate is a function of three variables: month, day, and year.

It returns the date of the day after the input date.

The month, day, and year variables have numerical values:

with 1 ≤ month ≤ 12,
1 ≤ day ≤ 31, and
1812 ≤ year ≤ 2012.

34
Currency Convertor Problem

35
Simple ATM (SATM) Problem

36
 Commission Problem
Rifle salespersons in the Arizona Territory sold rifle locks, stocks, and barrels made by a
gunsmith in Missouri. Locks cost $45.00, stocks cost $30.00, and barrels cost $25.00.

Salespersons had to sell at least one complete rifle per month, and production limits are
such that the most one salesperson could sell in a month is 70 locks, 80 stocks, and 90
barrels. Each rifle salesperson sent a telegram to the Missouri company with the total
order for each town (s)he visits; salespersons visit at least one town per month, but
travel difficulties made ten towns the upper limit.

At the end of each month, the company computed commissions as follows: 10% on sales
up to $1000, 15% on the next $800, and 20% on any sales in excess of $1800.

The company had four salespersons. The telegrams from each salesperson were sorted
into piles (by person) and at the end of each month a datafile is prepared, containing the
salesperson’s name, followed by one line for each telegram order, showing the number
of locks, stocks, and barrels in that order. At the end of the sales data lines, there is an
entry of “-1” in the position where the number of locks would be to signal the end of
input for that salesperson. The program produces a monthly sales report that gives the
salesperson’s name, the total number of locks, stocks, and barrels sold, the salesperson’s
total dollar sales, and finally his/her commission.
37
 References
• Paul C Jorgensen, Software Testing, A
craftsman approach, 3rd edition.
• Adithya P Mathur, Foundations of Software
Testing, 2nd edition.
• Rex Black, Software Testing, Vol – I and II.