Software Testing

Unit -2
(Monika Singh)
 Functional-Testing
• Functional Testing is a type of Software Testing in which the system is tested against the
functional requirements and specifications. Functional testing ensures that the requirements
or specifications are properly satisfied by the application. This type of testing is particularly
concerned with the result of processing. It focuses on simulation of actual system usage but
does not develop any system structure assumptions.
• It is basically defined as a type of testing which verifies that each function of the software
application works in conformance with the requirement and specification. This testing is not
concerned about the source code of the application. Each functionality of the software
application is tested by providing appropriate test input, expecting the output and comparing
the actual output with the expected output. This testing focuses on checking of user
interface, APIs, database, security, client or server application and functionality of the
Application Under Test.
• Functional testing can be manual or automated.
Functional Testing Process:
Functional testing involves the following steps:
• Identify function that is to be performed.
• Create input data based on the specifications of function.
• Determine the output based on the specifications of function.
• Execute the test case.
• Compare the actual and expected output.
Major Functional Testing Techniques:
• Unit Testing
• Integration Testing
• Smoke Testing
• User Acceptance Testing
• Interface Testing
• Usability Testing
• System Testing
• Regression Testing
Functional Testing Tools:
• 1. Selenium
• 2. QTP
• 3. JUnit
• 4. SoapUI
• 5. Watir
Advantages of Functional Testing:
• It ensures to deliver a bug-free product.
• It ensures to deliver a high-quality product.
• No assumptions about the structure of the system.
• This testing is focused on the specifications as per the customer usage.
Disadvantages of Functional Testing:
• There are high chances of performing redundant testing.
• Logical errors can be missed out in the product.
• If the requirement is not complete then performing this testing becomes difficult.
 1. Boundary Value Testing
• Boundary Value Analysis (BVA) is a black box software testing technique where test
cases are designed using boundary values.
• BVA is based on the single fault assumption, also known as critical fault assumption
which states that failures are rarely the product of two or more simultaneous faults.
Hence while designing the test cases for BVA we keep all but one variable to the nominal
value and allowing the remaining variable to take the extreme value.
• Test Case Design for BVA:
While designing the test cases for BVA first we determine the number of input variables in
the problem. For each input variable, we then determine the range of values it can take.
Then we determine the extreme values and nominal value for each input variable.
• Under the single fault assumption, the total number of test cases in BVA for a problem
with n inputs is 4n+1.
• The 4n cases correspond to the test cases with the four extreme values of each variable
keeping the other n-1 variable at nominal value. The one additional case is where all
variables are held at a nominal value.
• Example 1:
1800<=year<=1900
1<=month<=12
1<=day<=31
Design a bondary value test case.
Solution: The total number of test cases: 4n+1 = (4*3)+1 = 13
where, number of variable, n=3 (year, month, day)
Nominal Value for year= = 1850
Nominal Value for month= = ≈ 6
Nominal Value for day= = ≈ 16
Test cases Day Month Year
T1 16 6 1800
T2 16 6 1900
T3 16 6 1801
T4 16 6 1899
Test case table: →
T5 16 6 1850
T6 16 1 1850
T7 16 12 1850
T8 16 2 1850
T9 16 11 1850
T10 1 6 1850
T11 2 6 1850
T12 30 6 1850
T13 16 6 1850
 2. Equivalence Class Testing
• Equivalence class testing (Equivalence class Partitioning) is a black-box testing technique
used in software testing as a major step in the Software development life cycle (SDLC).
• This testing technique is better than many of the testing techniques like boundary value
analysis, worst case testing, robust case testing and many more in terms of time
consumption and terms of precision of the test cases.
• Since testing is done to identify possible risks, equivalence class testing performs better
than the other techniques as the test cases generated using it are logically identified with
partitions in between to create different input and output classes.
• The input and the output domain is partitioned into mutually exclusive parts called
equivalence classes.
• Any one sample from a class is representative of the entire class.
• Steps to make test cases:
• Identify equivalence classes by taking each input condition and output condition and partitioning it
into valid and invalid classes.
• Generate test cases using equivalence classes.
• Example 1: If a variable lies between 1 and 100 then equivalence classes will be:
• all negative values, 0 → Invalid
• 1<=x<=100 → Valid
• all positive values>100 → Invalid
• Example 2:
1900<=year<=2025
1<=month<=12
1<=day<=31
Design equivalence class test cases.
Nominal Value for year= = 1962
Equivalence classes month day year
Nominal Value for month= = ≈ 6 with test cases
Nominal Value for day= = ≈ 16 O1: All valid input/date 6 16 1962
O2: Invalid date 2 31 1962
I1: 1<=month<=12 6 16 1962
Here, O: Output condition,
I2: month<1 0 16 1962
I: Input condition. I3: month>12 13 16 1962
I4: 1<=day<=31 6 16 1962
Test case table: → I5: day<1 6 -1 1962
I6: day>31 6 32 1962
I7: 1900<=year<=2025 6 16 1962
I8: year>2025 6 16 2026
I9: year<1900 6 16 1890
 3. Decision Table-based Testing
• Decision tables are used in various engineering fields to represent complex logical
relationships.
• This testing is a very effective tool in testing the software and its requirements
management.
• The output may be dependent on many input conditions and decision tables give a tabular
view of various combinations of input conditions and these conditions are in the form of
True(T) and False(F). Also, it provides a set of conditions and its corresponding actions
required in the testing.
• Parts of Decision Tables :
• In software testing, the decision table has 4 parts
which are divided into portions and are given
below :
• Condition Stubs : The conditions are listed in this
first upper left part of the decision table that is used
to determine a particular action or set of actions.
• Action Stubs : All the possible actions are given in
the first lower left portion (i.e, below condition stub)
of the decision table.
• Condition Entries : In the condition entry, the
values are inputted in the upper right portion of the
decision table. In the condition entries part of the
table, there are multiple rows and columns which
are known as Rule.
• Action Entries : In the action entry, every entry has
some associated action or set of actions in the lower
right portion of the decision table and these values
are called outputs.
Types of Decision Tables :
• The decision tables are categorized into two types and these are given below:
• Limited Entry : In the limited entry decision tables, the condition entries are restricted
to binary values.
• Extended Entry : In the extended entry decision table, the condition entries have more
than two values. The decision tables use multiple conditions where a condition may have
many possibilities instead of only ‘true’ and ‘false’ are known as extended entry decision
tables.

Applicability of Decision Tables :

• The order of rule evaluation has no effect on the resulting action.
• The decision tables can be applied easily at the unit level only.
• Once a rule is satisfied and the action selected, n another rule needs to be examined.
• The restrictions do not eliminate many applications.
• Example: Design the test cases for Triangle problem.
Limited Entry Decision Table

C1: x,y,z are sides of triangle N Y Y Y Y Y Y Y Y

C2: x=y - Y Y Y Y N N N N
C3: x=z - Y Y N N Y Y N N
C4: y=z - Y N Y N Y N Y N
A1: Not a triangle 
A2: Scalene 
A3: Isosceles   
A4: Equilateral 
A5: Impossible   
• Extended Entry Decision Table

C1: x<y+z? F T T T T T T T T T T
C2: y<x+z? - F T T T T T T T T T
C3: z<x+y? - - F T T T T T T T T
C4: x=y? - - - T T T T F F F F
C5: x=z? - - - T T F F T T F F
C6: y=z? - - - T F T F T F T F
A1: Not a triangle   
A2: Scalene 
A3: Isosceles   
A4: Equilateral 
A5: Impossible   
• Test cases:

Test Case x y z Expected

output
1 4 1 2 Not a triangle
2 1 4 2 Not a triangle
3 1 2 4 Not a triangle
4 5 5 5 Equilateral
5 - - - Impossible
6 - - - Impossible
7 2 2 3 Isosceles
8 - - - Impossible
9 2 3 2 Isosceles
10 3 2 2 Isosceles
11 3 4 5 Scalene
 4. Cause & Effect Graphing Method
• It is a technique to systematically select a high-yield set of test cases.
• In case of boundary value and decision table test cases, there maybe some kind of
incompleteness in test cases, they consider only one scanerio at a time, not the
combinations. So there are chances that some test cases remain untouched.
• Benefit: It point out the incompleteness and ambiguities in specifications.
How to derive test cases?
• Step1: Identify the cause and effect from the specifications and assign unique numbers to
each of them.
• CAUSE: Any distinct input condition or an equivalence class of input condition.
• EFFECT: An output condition or system transformation. (The effect that any input has on the state
of sytem)
• Step2: Draw a boolean graph linking cause and effects. (Cause and effect graph)
• Step3: Specify constraints on graph describing combinations of cause and effects
that are impossible.
• Step4: Convert the graph into limited entry decision table by tracing state conditions
in the graph.

• CAUSE & EFFECT Graph Notations:

1. Identity Function: if c is 1, then e is 1. Else e is 0.
• NOT Function: if c is 1, then e is 0. Else e is 1.

• OR Function: if c1 or c2 or c3 is 1, then e is 1. Else e is 0.

• AND Function: if both c1 and c2 and c3 is 1, then e is 1. Else e is 0.

• To represent some impossible combinations of causes or impossible combinations of
effects, constraints are used. The following constraints are used in cause-effect
graphs:
• Exclusive constraint or E-constraint: This constraint exists between causes. It
states that either c1 or c2 can be 1, i.e., c1 and c2 cannot be 1 simultaneously.

• Inclusive constraint or I-constraint: This constraint exists between causes. It states

that atleast one of c1, c2 and c3 must always be 1, i.e., c1, c2 and c3 cannot be 0
simultaneously.
• One and Only One constraint or O-constraint: This constraint exists between causes.
It states that one and only one of c1 and c2 must be 1.

• Requires constraint or R-constraint: This constraint exists between causes. It states

that for c1 to be 1, c2 must be 1. It is impossible for c1 to be 1 and c2 to be 0.

• Mask constraint or M-constraint: This constraint exists between effects. It states that
if effect e1 is 1, the effect e2 is forced to be 0.
• Example: The character in a column 1 must be A or B. The character in column 2 must
be a digit. If these two hold then file update is made. If the chracter in column 1
incorrect, message x is issued. If character in column 2 is not a digit, message y is issued.
Step-01:
Identify and describe the input conditions (causes) and actions (effect).
The causes represented by letter “C” are as follows-
C1 : The character in column 1 is ‘A’
C2 : The character in column 1 is ‘B’
C3 : The character in column 2 is a number
The effects represented by letter “e” are as follows-
e1 : File update is made
e2 : Message x is printed
e3 : Message y is printed
• Step02:
Step03: