SOFTWARE

QUALITY
ENGINEERING
(SQE)
Chapter 23 Testing Conventional
1

Applications
 SOFTWARE
2
TESTING
FUNDAMENTAL
S
 The goal of testing is to find errors, and a good test is
one that has a high probability of finding errors.
 Software Testability is simply how easily a
computer program can be tested.
 Test Characteristics: Following are the attributes of
a “good” test
 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

3
 INTERNAL AND
4
EXTERNAL
VIEWS OF
TESTING
Black-box vs White-box Testing vs Grey Box
Testing
 Any engineered product can be tested in one of three ways:

1. Knowing the specified function that a product has been

designed to perform, tests can be conducted that
demonstrate each function is fully operational while at the
same time searching for errors in each function. This test
approach takes an external view and is called black-box
testing
2. Knowing the internal workings of a product, tests can be
conducted to ensure that “all gears mesh,” that is, internal
operations are performed according to specifications and
all internal components have been adequately exercised.
This test approach requires an internal view and is termed
as white-box testing.
3. Grey Box Testing: While white box testing assumes the
tester has complete knowledge, and black box testing
relies on the user’s perspective with no code insight,
Grey Box Testing is a compromise. It tests applications 5
and environments with partial knowledge of internal
 Black-box testing refers to tests that are conducted at the
software interface.
 A black-box test examines some fundamental aspect of a
system with little regard for the internal logical structure of the
software.

 White-box testing of software is predicated on close

examination of the procedural detail (code).
 Logical paths through the software and collaborations between
components are tested by exercising specific sets of conditions
and/or loops.

6
7
BLACK-BOX
TESTING
 Black Box Testing is a software testing method in which the
functionalities of software applications are tested without having
knowledge of internal code structure, implementation details and
internal paths.
 Black Box Testing mainly focuses on input and output of software
applications and it is entirely based on software requirements and
specifications.

 It is also known as Behavioral Testing.

 Black-box testing attempts to find errors in the following categories:

1. Incorrect or missing functions

2. Interface errors
3. Errors in data structures or external database access
4. Initialization and termination errors
8
 BLACK-BOX
9
TESTING
TECHNIQUES
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.
 Hence, instead of using each and every input value
we can now use any one value from the group/class
to test the outcome.
 In this way, we can maintain the test coverage while
we can reduce a lot of rework and most importantly
the time spent.

10
  Example of ECP
 As present in the below image, an “AGE” text field accepts only the
numbers from 18 to 60. There will be three set of classes or groups.
 Two invalid classes will be:
 a) Less than or equal to 17.
 b) Greater than or equal to 61.

 One valid class will be anything between 18 to 60

We have thus reduced the test cases

to only 3 test cases based on the
formed classes thereby covering all
the possibilities. So, testing with
anyone value from each set of the
class is sufficient to test the above
scenario.

11
 BLACK-BOX
12
TESTING
TECHNIQUES
2. Boundary Value Analysis (BVA)
 In this technique we focus on the values at
boundaries as it is found that many applications have
a high amount of issues on the boundaries.
 Boundary means the values near the limit where the
behavior of the system changes.
 In boundary value analysis both the valid inputs and
invalid inputs are being tested to verify the issues.

13
  Example of BVA

 From the above figure, 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.

14
 BLACK-BOX
15
TESTING
TECHNIQUES
3. Decision Table Testing (DTT)
 As the name itself suggests that, wherever there are
logical relationships like:
 If
{
(Condition = True)
then action1 ;
}
else action2; /*(condition = False)*/
 Then a tester will identify two outputs (action1 and
action2) for two conditions (True and False). So
based on the probable scenarios a Decision table is
carved to prepare a set of test cases.

16
  Example of DTT
 Take an example of XYZ bank that provides interest rate for
the Male senior citizen as 10% and for rest of the people 9%.

In this example condition, C1 and C2 has two values as true and

false. The number of total possible combinations would then be four
(2 ^ no. of conditions). This way we can derive test cases using
decision table.
17
 BLACK-BOX
18
TESTING
TECHNIQUES
4. State Transition Testing (STT)
 State Transition Testing is a black box testing
technique in which changes made in input conditions
cause state changes or output changes in the
Application under Test(AUT).
 State transition testing helps to analyze behavior of
an application for different input conditions.
 Testers can provide positive and negative input test
values and record the system behavior.

19
  Elements of State Transition Diagram

 There are 3 main components of the State Transition

Model as below
 1) States that the software might get.
 2) Transition from one state to another.
 3) Events that origin a transition.

20
  How to Make a State Transition Diagram.
 Example:
 Let’s consider an ATM system function where if the
user enters the invalid password three times, the
account will be locked.
 In this system, if the user enters a valid password in
any of the first three attempts the user will be logged
in successfully. If the user enters the invalid password
in the first or second try, the user will be asked to re-
enter the password. And finally, if the user enters
incorrect password 3rd time, the account will be
blocked.

21
State Transition Diagram of the scenario discussed
in prev. slide

States: Start, 1st

Try, 2nd Try, 3rd Try,
Access Granted,
Account Block.

Transition: blue
and black arrows
are showing
transition.

Events: Incorrect
22
Pin, Correct PIN.
  State Transition Table of the same scenario

Events
States
Correct PIN Incorrect PIN
S1: Start - -
S2: 1st Try S5 S3
S3: 2nd Try S5 S4
S4: 3rd Try S5 S6
S5: Access Granted - -
S6: Account Blocked - -

23
 BLACK-BOX
24
TESTING
TECHNIQUES
5. Error Guessing Testing
 This is a classic example of experience based
testing.
 In this technique, the tester can use his/her
experience about 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.

25
  Examples of Error Guessing

 Few common mistakes that developers usually

forget to handle:
 Divide by zero.
 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.
26
 BLACK-BOX
27
TESTING
TECHNIQUES
6. Orthogonal Array Testing (OAT)
 The type of array in which all possible pair-wise combinations
between parameters occurs only once is called an Orthogonal
Array.
 Orthogonal Array Testing (OAT) is defined as a type of
software testing strategy that uses Orthogonal Arrays especially
when the system to be tested has huge data inputs.
 For example, when a train ticket has to be verified, the factors
(variables) such as - the number of passengers, ticket number,
seat numbers, and the train numbers has to be tested, which
becomes difficult when a tester verifies input one by one.
Hence, it will be more efficient when he combines more inputs
together and does testing. Here, we can use the Orthogonal
Array testing method.
 If we have 3 variables, each can have 3 values then the
possible number of tests using conventional method is
3^3 = 27, while the same using OAT, it boils down to 9
(3*3) test cases.
28
 Implementing OAT technique involves the below steps:

1. Identify the independent variables. These will be referred to

as “Factors”.
2. Identify the values which each variable will take. These will
be referred as “Levels”.
3. Compute size of the Orthogonal array i.e. (levels)^2 rows
and factors columns.
4. Search for a suitable OA.
5. Map the factors and levels with your requirement.
6. Develop the OAT table.
7. Translate them into the suitable test cases.
8. Look out for the left over or special test cases (if any).

29
  Example of OAT
 Let us consider you have to identify the test cases for a Web
Page that has 4 sections: Headlines, Details, References and
Comments, that can be displayed or not displayed or show
Error message. You are required to design the test condition to
test the interaction between different sections.
 In this case:

1. Number of factors are = 4 (Headlines, Details, References

and Comments)
2. Number of levels (possible values for the variables) = 3
( displayed, not displayed and error message)
3. Orthogonal Array would be 3*3 rows and 4 columns .
4. Search and find an appropriate array for 4 factors and 3
levels.

30
The array is L9 orthogonal, because all possible pair-wise
combinations between parameters occurs only once.
31
5. Now, map this array with our requirements as below:
1 will represent “Is Displayed” value
2 will represent “not displayed” value
3 will represent “error message value”
Factor A will represent “ Headlines” section
Factor B will represent “Details” section
Factor C will represent “References ”section
Factor D will represent “Comment” section.
Experiment no. will represent “Test Cases ID”

6. After mapping, the table will look like:

32
 TC_ID

7. Based on the table above, design your test cases. Also look out
for the special test cases / left over test cases.
33