Software Testing

Module - 2
Dynamic Testing:
Blackbox Testing Technique

Dr. Renjith P N
School of Computer Science & Engineering,
Vellore Institute of Technology, Chennai Campus
[email protected]
+91-9840330858
 Blackbox
Looping Testing
▪ Blackbox Testing
▪ Types of Blackbox Testing
▪ Boundary Value Analysis
▪ Equivalent Partitioning
▪ State Table based Testing
▪ Decision Table based Testing
▪ Cause Effect Graph based Testing
▪ Orthogonal Array Testing
▪ Error Guessing
▪ Requirement Based Testing
▪ Functional Testing Tools
▪ Non Functional Requirement Testing tool
CLIENT, USER & DESIGNER
• Client : Person or group or company that wants a design conceived.
• User : Who will employ/operate/use whatever is being designed.
• Designer : Whose job is to solve the client’s problem in a way that
meets the user’s needs.

Client

User Designer

3
Software Testing

Software testing is a crucial process in the development

and maintenance of software applications.

It involves the execution of a software system or

component to evaluate its functionality and ensure that it
meets specified requirements.

Dr. Renjith P N Module – 2 – Blackbox Testing 4

Software Testing

The process of evaluating a software application or system to

identify any deviation between the expected and actual results,
and to ensure that it functions correctly.

Dr. Renjith P N Module – 2 – Blackbox Testing 5

Software Testing

The systematic process of ensuring that a product or

system meets specified requirements and quality
standards.

QA includes activities such as process definition, quality

planning, and systematic evaluation of processes.

Dr. Renjith P N Module – 2 – Blackbox Testing 6

Software Testing

A document that outlines the approach, scope,

resources, and schedule of testing activities.
It serves as a guide for the entire testing process.

Dr. Renjith P N Module – 2 – Blackbox Testing 7

Test Plan
• A document that outlines the approach, scope, resources, and
schedule of testing activities.
• It serves as a guide for the entire testing process.

8
Test Suite
• A collection of test cases grouped together for
execution and management.
• Test suites help organize and streamline the testing
process.

9
Test Case
• A set of conditions or variables under which a tester will
determine whether an application or system works as
intended.
• It includes inputs, expected outcomes, and execution steps.

10
Test Execution

• The process of running a set of test cases against a software

application to identify and report defects.

11
Defect:

• Any deviation or flaw in the software system that does

not meet the specified requirements or expectations.

12
Bug

• A defect or error in the software that causes it to behave

unexpectedly or not according to specifications.

13
Fault
• A fault is the result of an error.
• It is more precise to say that a fault is the representation of an error.
• Defect is a good synonym for fault, as is bug.
• An error of omission results in a fault in which something is missing
that should be present in the representation.

14
Input / output faults
• Correct input not accepted
• Incorrect input accepted
• Description wrong or missing Parameters wrong or missing
• Output in Wrong format
• Wrong result
• Correct result at wrong time (too early, too late)
• Incomplete or missing result
• Spelling/grammar error

15
Coding Standards
 Most software development organizations formulate their
own coding standards that suit them most, and require
their engineers to follow these standards strictly
 The purpose of requiring all engineers of an organization to
adhere to a standard style of coding is the following:

A coding standard gives a uniform appearance to the codes

Good software written by different engineers.
development organizations It enhances code understanding.
normally require their
programmers to adhere to It encourages good programming practices.
some well-defined and
standard style of coding
called coding standards.

Dr. Renjith P N Module – 2 – Blackbox Testing 16

Coding Standards Cont.
A coding standard lists several rules to be followed such as, the way variables are to
be named, the way the code is to be laid out, error return conventions, etc.

The following are some representative coding standards

1 Rules for limiting the use of global
These rules list what types of data can be declared global and what cannot.
2 Naming conventions for global & local variables & constant identifiers
A possible naming convention can be that global variable names always start with a capital letter, local
variable names are made of small letters, and constant names are always capital letters.
3 Contents of the headers preceding codes for different modules
• The information contained in the headers of The following are some standard header data
different modules should be standard for an Module Name Creation Date Author’s Name
organization.
• The exact format in which the header Modification history Synopsis of the module
information is organized in the header can Global variables accessed/modified by the module
also be specified Different functions supported, along with their input/output parameters

Dr. Renjith P N Module – 2 Blackbox Testing 17

Coding Standards Cont.
Sample Header
/*
* PositiveTests <br>
* This class is merely for illustrative purposes. <br>
*Revision History:<br>
* 1.1 – Added javadoc headers <br>
* 1.0 - Original release<br>
* @author P.N.R
* @version 1.1, 12/02/2025
*/
public class PositiveTests {
. . .
}

4 Error return conventions and exception handling mechanisms

• The way error conditions are reported by different functions in a program are handled
should be standard within an organization.
• For example, different functions while encountering an error condition should either
return a 0 or 1 consistently.
Dr. Renjith P N Module – 2 Blackbox Testing 18
Coding Standards Cont.
EXAMPLES OF GLOBAL AND LOCAL.

What can be Declared Global

1 Rules for limiting the use of global
These rules list what types of data can be declared global and what cannot.

Type Example Reason

Constants PI = 3.14 Used across program
Config settings DEBUG = True Needed globally
Logging configuration LOG_LEVEL = "INFO" Consistent log levels

Dr. Renjith P N Module – 2 Blackbox Testing 19

Coding Standards Cont.
EXAMPLES OF GLOBAL AND LOCAL.

What cannot be Declared Global

1 Rules for limiting the use of global

Type Example Reason

Temporary counters counter = 0 in global scope Should be inside function

May cause memory/resource

File handles file = open(...) globally
issues

Can be modified anywhere—

Mutable containers data = [] in global scope
risky

Dr. Renjith P N Module – 2 Blackbox Testing 20

Example
# Acceptable Global (constant)
PI = 3.14159

# Avoidable Global
total = 0 # Not recommended

def calculate_area(radius):
# Using global constant is OK
return PI * radius * radius

Dr. Renjith P N Module – 2 Blackbox Testing 21

Example
 Good Code

def update_total(value, current_total):

return current_total + value

# Usage
total = update_total(5, total)

Dr. Renjith P N Module – 2 Blackbox Testing 22

Check the code below
value = 0

def add(x):
value += x

add(5)
print(value)

Dr. Renjith P N Module – 2 Blackbox Testing 23

Rewrite the program without Global

score = 0

def update_score(points):
global score
score += points

Dr. Renjith P N Module – 2 Blackbox Testing 24

Coding guidelines The following are some representative coding guidelines

Do not use a coding style that is too clever or too difficult to understand
Do not use an identifier for multiple purposes
The code should be well-documented
The length of any function should not exceed 10 source lines
Do not use goto statements
Well Documented

Do not use goto

Dr. Renjith P N Module -2 Blackbox Testing 25
Software Faults Types of Faults
 Quite inevitable
(unavoidable) Algorithmic Logic is wrong

 Many reasons Syntax Wrong syntax; typos Compiler

Software systems with Computation/ Precision Not enough accuracy

large number of states Documentation Misleading documentation

Complex formulas, Stress/Overload Maximum load violated

activities, algorithms Capacity/Boundary Boundary cases are usually special cases

Customer is often unclear Timing/Coordination Synchronization issues

of needs Throughput/Performance System performs below expectations
Size of software Recovery System not recovered from abnormal state

Number of people involved Hardware & related software Compatibility issues

Standards Makes for difficult maintenance

Dr. Renjith P N Module -2 Blackbox Testing 26

Software Quality

Software Quality remains an issue Code Review

Who is to blame?
Code Walk Through
Customers blame developers Code Inspection
Arguing that careless practices lead to low-quality software

Developers blame Customers & other stakeholders

Arguing that irrational delivery dates and continuous stream of
changes force the to deliver software before it has been fully
validated

Who is Right? Both – and that’s the problem

Dr. Renjith P N Module -2 Blackbox Testing 27

Code Review
 Code Review is carried out after the Few classical programming errors
module is successfully compiled and all
the syntax errors have been eliminated.  Use of uninitialized variables
 Code Reviews are extremely cost-  Jumps into loops
effective strategies for reduction in  Nonterminating loops
coding errors and to produce high quality  Incompatible assignments
code.
Types of
 Array indices out of bounds
Reviews  Improper storage allocation and deallocation
 Mismatches between actual and formal
Code Walk Code parameter in procedure calls
Through Inspection  Use of incorrect logical operators or incorrect
precedence among operators
 Improper modification of loop variables

Dr. Renjith P N Module -2 Blackbox Testing 28

Code Review Code Walk Through & Code Inspection

Code Walk Through Code Inspection

 Code walk through is an informal code analysis  The aim of Code Inspection is to
technique. discover some common types of errors
 The main objectives of the walk through are to caused due to improper programming.
discover the algorithmic and logical errors in  In other words, during Code Inspection
the code. the code is examined for the presence of
 A few members of the development team are certain kinds of errors.
given the code few days before the walk  For instance, consider the classical error of
writing a procedure that modifies a
through meeting to read and understand code. parameter while the calling routine calls that
 Each member selects some test cases and procedure with a constant actual parameter.
simulates execution of the code by hand  It is more likely that such an error will be
discovered by looking for these kinds of
 The members note down their findings to mistakes in the code.
discuss these in a walk through meeting where
 In addition, commitment to coding
the coder of the module is present. standards is also checked.
Dr. Renjith P N Module – 2 Blackbox Testing 29
Software Documentation
 When various kinds of software products are developed, various kinds of
documents are also developed as part of any software engineering process e.g..

Users’ manual Design documents Test documents Installation manual

Software requirements specification (SRS) documents, etc

 Different types of software documents can broadly be classified into the following:

Software
Documents

Internal External
Documentation Documentation

Dr. Renjith P N Module – 2 – Blackbox Testing 30

Software Documentation Cont. Internal & External Documentation

Internal Documentation External Documentation

 It is the code perception features provided as part of the  It is provided through various
source code. types of supporting documents
 It is provided through appropriate module headers and  such as users’ manual
comments embedded in the source code.  software requirements
specification document
 It is also provided through the useful variable names,  design document
module and function headers, code indentation, code  test documents, etc.
structuring, use of enumerated types and constant
identifiers, use of user-defined data types, etc. A systematic software
 Even when code is carefully commented, meaningful
development style ensures that
variable names are still more helpful in understanding a all these documents are
piece of code. produced in an orderly fashion.
 Good organizations ensure good internal documentation
by appropriately formulating their coding standards and
guidelines.
Dr. Renjith P N Module – 2 – Blackbox Testing 31
Software Testing
Testing is the process of
exercising a program with the
specific intent of finding
errors prior to delivery to the
end user.

Don’t view testing as a

“safety net” that will catch all
errors that occurred because
of weak software engineering
practice.
Dr. Renjith P N Module – 2 – Blackbox Testing 32
Who Test the Software
Developer

Who Test the

Tester
Software?

Understands the system but, will Must learn about the system, but,
test "gently" will attempt to break it <Developer>
and, is driven by "delivery" and, is driven by quality
OR
[Tester]

Dr. Renjith P N Module – 2 – Blackbox Testing 33

State based Software Testing
 State based software testing is a type of software testing which is performed to
check the change in the state of the application under varying input. The condition of
input passed is changed and the change in state is observed.

 State Transition Testing is basically a black box testing technique that is carried out
to observe the behavior of the system or application for different input conditions
passed in a sequence.

 In this type of testing, both positive and negative input values are provided and the
behavior of the system is observed.

Dr. Renjith P N Module – 2 – Blackbox Testing 34

Objectives of State Transition Testing
 Determining the System States:
 Identify and record the different states that the system that is being tested can be in. These
phases are frequently connected to certain circumstances or occurrences inside the system.

 State Transition Modelling

 It makes a model or state transition diagram that shows the system’s various states and the
changes between them

 Verifying Legitimate State Transitions

 Check that the system responds to various inputs or events by switching between valid states in
a correct manner. By doing this, it is ensured that the system transitions between states with
expected behaviour.

Dr. Renjith P N Module – 2 – Blackbox Testing 35

State transition Testing - objectives
 Checking the Beginning and End States
 Verify that, following a series of actions or events, the system finishes in the expected final state
and begins in the proper beginning state. This guarantees correct system setup and dismantling.

 Error Correction and Recovery:

 Examine the system’s capacity to recover from unforeseen conditions and accept faults with
patience.

 This covers situations in which the system operates and runs into unexpected inputs or events.

Dr. Renjith P N Module – 2 – Blackbox Testing 36

Advantages of State Transition Testing
• Clear Visualization:
• The different states and transitions in the system are clearly represented visually through the
use of state transition diagrams.
• Better comprehension, communication and documentation of the system’s behavior are made
possible by this visualization.
• Effective Test Design:
• Effective test case design is facilitated by the modelling of states and transitions.
• Based on the state transition diagram, testers can create test scenarios that encompass both
legitimate and illegitimate state changes.
• Early Error Detection:
• Early fault discovery in relation to state transitions is aided by state transition testing.
• Testers can detect and fix problems early in the development life cycle by methodically testing
various transitions.

Dr. Renjith P N Module – 2 – Blackbox Testing 37

When to Test the Software?
Component Code Component Code Component Code
Unit Test Unit Test Unit Test

Design Specifications Integration Test Integrated modules

System functional requirements Function Test Functioning system

Other software requirements Performance Test Verified, validated software

Customer SRS Acceptance Test Accepted system

User environment Installation Test System in use!

Dr. Renjith P N Module – 2 Blackbox Testing 38
Verification & Validation
Verification Verification Validation
Are we building the product right? Process of evaluating products of a Process of evaluating software at the
development phase to find out whether end of the development to determine
The objective of Verification is to they meet the specified requirements. whether software meets the customer
make sure that the product being expectations and requirements.
develop is as per the
requirements and design Activities involved: Reviews, Meetings Activities involved: Testing like black box
and Inspections testing, white box testing, gray box
specifications. testing

Validation Carried out by QA team Carried out by testing team

Are we building the right product? Execution of code is not comes under Execution of code is comes under
Verification Validation
The objective of Validation is to
make sure that the product Explains whether the outputs are Describes whether the software is
actually meet up the user’s according to inputs or not accepted by the user or not
requirements, and check whether Cost of errors caught is less Cost of errors caught is high
the specifications were correct in
the first place.

Dr. Renjith P N Module – 2 – Blackbox Testing 39

Software Testing Strategy

Unit Testing
It concentrate on each
unit of the software as
implemented in source
code
 Unit Testing It focuses on each
 Integration Testing component individual,
 Validation Testing ensuring that it functions
properly as a unit.
 System Testing

Dr. Renjith P N Module -2 Blackbox Testing 40

Software Testing Strategy Cont.

Integration Testing Validation Testing System Testing

It focus is on design and Software is validated The software and other software
construction of software against requirements elements are tested as a whole
architecture established as a part of Software once validated, must be
requirement modeling combined with other system
Integration testing is the
elements e.g. hardware, people,
process of testing the It give assurance that database etc…
interface between two software meets all
software units or informational, functional, It verifies that all elements mesh
modules behavioral and properly and that overall system
performance requirements function / performance is achieved.

Dr. Renjith P N Module – 2 Blackbox Testing 41

Unit Testing
 Unit is the smallest part of a software system which is testable.
 It may include code files, classes and methods which can be tested individually
for correctness.
 Unit Testing validates small building block of a complex system before testing an
integrated large module or whole system
 The unit test focuses on the internal processing logic and data structures within
the boundaries of a component.
 The module is tested to ensure that information properly flows into and out of
the program unit
 Local data structures are examined to ensure that data stored temporarily
maintains its integrity during execution
 All independent paths through the control structures are exercised to ensure that
all statements in module have been executed at least once
 Boundary conditions are tested to ensure that the module operates properly at
boundaries established to limit or restricted processing
 All error handling paths are tested
Dr. Renjith P N Module -2 Blackbox Testing 42
Diver & Stub (Unit Testing)
A B C
 Let’s take an example to understand it in a better way.
 Suppose there is an application consisting of three
modules say, module A, module B & module C.
 Developer has design in such a way that module B
depends on module A & module C depends on module
B
 The developer has developed the module B and now
Component-testing (Unit Testing) may be
wanted to test it.
done in isolation from rest of the system
 But the module A and module C has not been
In such case the missing software is developed yet.
replaced by Stubs and Drivers and
simulate the interface between the  In that case to test the module B completely we can
software components in a simple manner replace the module A by Driver and module C by stub
Dr. Renjith P N Module – 2 Blackbox Testing 43
Diver & Stub (Unit Testing) Cont.
Driver Stub
 Driver and/or Stub software must be  Stubs serve to replace modules that are
developed for each unit test subordinate (called by) the component to
 A driver is nothing more than a "main be tested.
program"  A stub or "dummy subprogram"
 It accepts test case data  Uses the subordinate module's interface
 Passes such data to the component and  May do minimal data manipulation
 Prints relevant results.  Prints verification of entry and
 Driver  Returns control to the module undergoing
testing
 Used in Bottom up approach
 Lowest modules are tested first.  Stubs
 Simulates the higher level of components  Used in Top down approach
 Dummy program for Higher level component  Top most module is tested first
 Simulates the lower level of components
 Dummy program of lower level components
Dr. Renjith P N Module -2 Blackbox Testing 44
Integration Testing
Integration testing is the process of testing the interface between two software units or modules
It can be done in 3 ways 1. Big Bang Approach 2. Top Down Approach 3. Bottom Up Approach

Big Bang Approach Top Down Approach

 Combining all the modules  Testing take place from top to bottom
once and verifying the
 High level modules are tested first and then low-level modules and
functionality after completion
finally integrated the low level modules to high level to ensure the
of individual module testing
system is working as intended
 Stubs are used as a temporary module, if a module is not ready for
integration testing
Bottom Up Approach
 Testing take place from bottom to up
 Lowest level modules are tested first and then high-level modules and finally integrated the high level
modules to low level to ensure the system is working as intended
 Drivers are used as a temporary module, if a module is not ready for integration testing
Dr. Renjith P N Module – 2 – Blackbox Testing 45
Regression Testing When to do regression testing?
 Repeated testing of an already tested  When new functionalities are added to the
program, after modification, to discover application
any defects introduced or uncovered as a  E.g. A website has login functionality with only Email.
result of the changes in the software Now the new features look like “also allow login using
being tested Facebook”
 Regression testing is done by re-  When there is a change requirement
executing the tests against the modified  Forgot password should be removed from the login page
application to evaluate whether the
modified code breaks anything which  When there is a defect fix
was working earlier  E.g. assume that “Login” button is not working and
tester reports a bug. Once the bug is fixed by developer,
 Anytime we modify an application, we tester tests using this approach
should do regression testing
 When there is a performance issue
 It gives confidence to the developers
that there is no unexpected side effects  E.g. loading a page takes 15 seconds. Reducing load
time to 2 seconds
after modification
 When there is an environment change
 E.g. Updating database from MySQL to Oracle
Dr. Renjith P N Module -2 Blackbox Testing 46
Smoke Testing
 Smoke Testing is an integrated testing Build
approach that is commonly used when product
software is developed
 This test is performed after each Build Release
 Smoke testing verifies – Build Stability F1 F2 F3 F4 F5 F6
 This testing is performed by “Tester” or
Critical Critical Major Major
“Developer”
 This testing is executed for Integration Testing, It test the build just to check if any major or
System Testing & Acceptance Testing critical functionalities are broken
 What to Test? If there are smoke or Failure in the build
 All major and critical functionalities of the after Test, build is rejected and developer
application is tested
 It does not go into depth to test each
team is reported with the issue
functionalities
 This does not incudes detailed testing for the build
Dr. Renjith P N Module – 2 – Blackbox Testing 47
Validation Testing
 The process of evaluating software to determine whether it satisfies specified business
requirements (client’s need).
 It provides final assurance that software meets all informational, functional, behavioral, and
performance requirements
 When custom software is build for one customer, a series of acceptance tests are conducted to
validate all requirements
 It is conducted by end user rather then software engineers
 If software is developed as a product to be used by many customers, it is impractical to
perform formal acceptance tests with each one
 Most software product builders use a process called alpha and beta testing to uncover errors
that only the end user seems able to find

Dr. Renjith P N Module – 2 – Blackbox Testing 48

Validation Testing – Alpha & Beta Test
Alpha Test
 The alpha test is conducted at the developer’s site by a representative group of end users
 The software is used in a natural setting with the developer “looking over the shoulders” of the
users and recording errors and usage problems
 The alpha tests are conducted in a controlled environment
Beta Test
 The beta test is conducted at one or more end-user sites
 Developers are not generally present
 Beta test is a “live” application of the software in an environment that can not be controlled by
the developer
 The customer records all problems and reports to the developers at regular intervals
 After modifications, software is released for entire customer base
Dr. Renjith P N Module – 2 – Blackbox Testing 49
System Testing
 In system testing the software and other system elements are tested.
 To test computer software, you spiral out in a clockwise direction along streamlines that
increase the scope of testing with each turn.
 System testing verifies that all elements properly and overall system function/performance is
achieved.
 System testing is actually a series of different tests whose primary purpose is to fully exercise
the computer-based system.

Types of System Testing

1 Recovery Testing 4 Performance Testing

2 Security Testing 5 Deployment Testing
3 Stress Testing

Dr. Renjith P N Module – 2 – Blackbox Testing 50

Types of System Testing
Recovery Testing
 It is a system test that forces the software to fail in a variety of ways
and verifies that recovery is properly performed.
 If recovery is automatic (performed by the system itself)
 Re-initialization, check pointing mechanisms, data recovery, and restart are
evaluated for correctness.
 If recovery requires human intervention
 The mean-time-to-repair (MTTR) is evaluated to determine whether it is
within acceptable limits
Security Testing
 It attempts to verify software’s protection mechanisms, which
protect it from improper penetration (access).
 During this test, the tester plays the role of the individual who desires
to penetrate the system.

Dr. Renjith P N Module – 2 – Blackbox Testing 51

Types of System Testing Cont.
Stress Testing
 It executes a system in a manner that demands resources in
abnormal quantity, frequency or volume.
 A variation of stress testing is a technique called sensitivity testing.

Performance Testing
 It is designed to test the run-time performance of software.
 It occurs throughout all steps in the testing process.
 Even at the unit testing level, the performance of an individual module
may be tested.

Dr. Renjith P N Module – 2 – Blackbox Testing 52

Types of System Testing Cont.
Deployment Testing
 It exercises the software in each environment in which it is to
operate.
 In addition, it examines
 All installation procedures
 Specialized installation software that will be used by customers
 All documentation that will be used to introduce the software to end users

Dr. Renjith P N Module – 2 – Blackbox Testing 53

Types of System Testing Cont.
Model Question

You are part of a QA team assigned to test a newly developed Online

Railway Reservation System. The system allows users to:
 Search trains between stations
 Book tickets (up to 6 passengers at a time)
 Make payments via debit card, credit card, UPI, or net banking
 View and cancel booked tickets
 Get SMS/email confirmations
The development team informs you that all modules are integrated,
and now the product is ready for System Testing.

Dr. Renjith P N Module – 2 – Blackbox Testing 54

Types of System Testing
Recovery Testing

Test Type Test Scenario Expected Outcome Potential Issues Uncovered

After restarting, the user should Ticket gets booked but no
Simulate a browser crash or power
see booking status updated confirmation is shown due to
Recovery Testing failure while booking a ticket after
correctly (confirmed or payment failure to recover transaction
payment is initiated.
pending). state.
Booking details of another user
Attempt to access booking history by
System should restrict access and are exposed due to improper
Security Testing changing the user ID in the URL (e.g.,
show an error or redirect to login. session or access control
/booking?id=123).
handling.

Simulate 10,000 users trying to book Server crashes or hangs, DB

System may slow down but should
Stress Testing tickets at once (e.g., before festival connection pool exhausted,
not crash or lose data.
season or Tatkal booking window). users see timeout errors.

Dr. Renjith P N Module – 2 – Blackbox Testing 55

Types of System Testing
Recovery Testing

Test Type Test Scenario Expected Outcome Potential Issues Uncovered

Measure the time taken to load Search takes too long due
Train search should complete
Performance train search results and complete to inefficient queries or
within 2 seconds; full booking
Testing a full ticket booking under normal unoptimized APIs, leading
within 10 seconds.
load. to poor user experience.
Application accepts
Try SQL injection in login or
Application should block such malicious input, exposing
Security Testing payment fields (e.g., entering ‘ OR
inputs and log the attempt. DB or allowing
‘1’=’1 in password).
unauthorized login.
Duplicate ticket booked or
Midway through a UPI payment, System should confirm if
payment deducted twice
Recovery Testing disconnect internet. After payment succeeded or let
due to poor transaction
reconnecting, simulate user retry. user retry safely.
rollback.

Dr. Renjith P N Module – 2 – Blackbox Testing 56

Views of Test Objects

Black Box Testing White Box Testing Grey Box Testing

Close Box Testing Open Box Testing Partial knowledge of
Testing based only on Testing based on actual source code
specification source code

Dr. Renjith P N Module – 2 – Blackbox Testing 58

Black Box Testing
 Also known as specification-based testing
 Tester has access only to running code and the specification it is supposed to satisfy
 Test cases are written with no knowledge of internal workings of the code
 No access to source code
 So test cases don’t worry about structure
 Emphasis is only on ensuring that the requirement is met
Advantages
 Scalable; not dependent on size of code
 Testing needs no knowledge of implementation
 Tester and developer can be truly independent of each other
 Tests are done with requirements in mind
 Does not excuse inconsistencies in the specifications
 Test cases can be developed in parallel with code
Dr. Renjith P N Module – 2 Blackbox Testing 59
Black Box Testing Cont.
Disadvantages
 Examine pre-condition, and identify equivalence classes
 All possible inputs such that all classes can’t be covered
 Test size will have to be small
 Specifications must be clear, concise, and correct
 May leave many program paths untested

Test Case 1
Specification Input: x1
Operation op Specification- Exp. Output: y1
Pre: X Based Test Case
Post: Y Design Test Case 2
Input: x2
Exp. Output: y2

Dr. Renjith P N Module -2 Blackbox Testing 60

Robust Testing
Robust Testing

Robust testing is aimed at evaluating the application's ability to handle invalid or unexpected

inputs gracefully without crashing or causing undesired behaviour.

Test Case 1
Input: x1
Specification Exp. Output: y1
Operation op Robust Testing
Input - Invalid Test Case 2
Input: x2
Exp. Output: y2

Dr. Renjith P N Module -2 Blackbox Testing 61

Robust Testing
Objective

The goal of robust testing is to ensure that the software can withstand and recover from

adverse conditions or unexpected situations.

Test cases for robust testing typically include scenarios with invalid inputs, extreme values,

or situations where the system is subjected to conditions beyond normal operation.

Dr. Renjith P N Module -2 Blackbox Testing 62

Robust Testing
Test Case

Test cases for robust testing typically include scenarios with invalid inputs, extreme values,

or situations where the system is subjected to conditions beyond normal operation.

Dr. Renjith P N Module -2 Blackbox Testing 63

Robust Testing
User authentication during login

Invalid Username:

• Input: Username = "invalidUsername", Password = "validPassword"

• Expected Result: System should handle invalid username gracefully, possibly displaying an

appropriate error message.

Dr. Renjith P N Module -2 Blackbox Testing 64

Robust Testing
Scenarios

Similarly
Invalid Password
Empty Fields

Dr. Renjith P N Module -2 Blackbox Testing 65

Worst Case Testing
Worst Case Testing

Worst-case testing involves evaluating the performance and behavior of the software under

the most unfavourable or resource-intensive conditions.

Objective

The objective of worst-case testing is to identify how the system behaves when it is under

stress, with the maximum load, or when resource constraints are at their limits.

Dr. Renjith P N Module -2 Blackbox Testing 66

Worst Case Testing
Test Cases

Test cases for worst-case testing may include scenarios where the system is operating at

peak capacity, handling a large number of concurrent users, or dealing with maximum data

loads.

Dr. Renjith P N Module -2 Blackbox Testing 67

Worst Case Testing
Example

Simulating Heavy Load on the Login System

 Maximum Concurrent Users
• Simulate a high number of users trying to log in simultaneously (e.g., 1000 users).

Expected Result:
• Check how the system handles the load and if it remains responsive without crashing or
significantly slowing down.

Dr. Renjith P N Module -2 Blackbox Testing 68

Worst Case Testing
Example

Simulating Network Delay

• Introduce network delays during login requests.

• Expected Result: Evaluate how the system copes with network latency, ensuring that it does

not lead to timeouts or unexpected errors.

Dr. Renjith P N Module -2 Blackbox Testing 69

Case Boundary Value Testing
Boundary Value Testing

Boundary value analysis (BVA) is a black-box test design technique in which test cases are designed based on boundary

values. Conceptually, boundary value analysis is about testing the edges of equivalence classes

Importance:

Identifying potential issues at the edges of input ranges.

Test Case 1
Specification Input: x1
Operation op Exp. Output: y1
Boundary Value
Pre: X
Testing Test Case 2
Post: Y
Input: x2
Exp. Output: y2

Dr. Renjith P N Module -2 Blackbox Testing 70

Case Boundary Value Testing
Introduction

Boundary value analysis (BVA) is a black-box test design technique in which test cases are designed based on boundary

values .

Conceptually, boundary value analysis is about testing the edges of equivalence classes.

Importance:

Identifying potential issues at the edges of input ranges.

Dr. Renjith P N Module -2 Blackbox Testing 71

Case Boundary Value Testing
Importance of CBVT

Minimizing Bugs: Detecting errors at the boundaries helps minimize the risk of

bugs.

Improved Coverage: Enhances test coverage by focusing on critical points.

Real-World Scenarios: Reflects real-world usage where users often provide

values at the extremes.

Dr. Renjith P N Module -2 Blackbox Testing 72

Case Boundary Value Testing
Basics of BVT

• Input Domain: Define the valid range of input values.

• Boundary Values: Identify the values at the lower and upper limits of the input

domain.

• Edge Cases: Points just inside and outside the boundaries.

Dr. Renjith P N Module -2 Blackbox Testing 73

Case Boundary Value Testing
Type of Boundaries

• Lower Boundaries: Testing values just below the acceptable range.

• Upper Boundaries: Testing values just above the acceptable range.

• Midpoint Values: Testing values at the center of the range.

Dr. Renjith P N Module -2 Blackbox Testing 74

Case Boundary Value Testing
Type of Boundaries

• Testing a system that accepts ages between 18 and 65.

• Lower Bound: Age = 17

• Upper Bound: Age = 66

• Midpoint: Age = 41

Dr. Renjith P N Module -2 Blackbox Testing 75

Case Boundary Value Testing
Type of Boundaries

Dr. Renjith P N Module -2 Blackbox Testing 76

Case Boundary Value Testing
Type of Boundaries

Some typical programming errors occurs:

At boundaries of equivalence class
Programmers often fail to see:
Special processing required at the boundaries of equivalent classes

 Ex. Making a software for grade calculation

 S >90
 A > 80 to 89
 B >70 to 79

Dr. Renjith P N Module -2 Blackbox Testing 77

Boundary value analysis
•Programmers may mistakenly use < instead
of <=
•Boundary value analysis:
•Select test cases at the boundaries of
different equivalence classes
Boundary value analysis
• If an input condition specifies a range, bounded
by values a and b
• Test case should be designed with value a and b and
above a and just below b.

• Example Integer D with inpur range [-3,10]

• Test value: -3,10,-2,9,0

•Enumerate data E with input
condition: {3,5,100,102}

•Test value?
• Enumerate data E with input condition: {3,5,100,102}

• Test value?
• 3,5,100,102, 2, 103,120, etc.
Example
• Process employee application based on a person’s age:

Age Application
0-12 Don’t Hire
12-17 May hire as intern
18-65 May hire full time
65-100 Don’t hire
Corrected Boundary

Age Application
0-11 Don’t Hire
12-17 May hire as intern
18-64 May hire full time
65-100 Don’t hire
Test values ?

Age Application
0-11 Don’t Hire
12-17 May hire as intern
18-64 May hire full time
65-100 Don’t hire
Test value?

Age Application
0-11 Don’t Hire
12-17 May hire as intern
18-64 May hire full time
65-100 Don’t hire
Test values
•{-1,0,1}
•(11,12,13)
•{17,18,19}
•{64,65,66}
•{98,99,100}
Case Boundary Value Testing
Model Question

You are testing the "Apply for Loan" feature of a banking web application. According to business rules:
The minimum loan amount a user can apply for is ₹10,000
The maximum loan amount is ₹5,00,000
The development team has implemented input validation on the loan amount field. You are asked to design tests to
ensure this validation works correctly.
As a senior tester, how would you apply Boundary Value Testing in this scenario?
Identify:
The boundary values to be tested,
The test cases you would design, and
Why boundary testing is critical in this context.
Also, explain what might happen if these boundary cases are not tested properly.

Dr. Renjith P N Module -2 Blackbox Testing 87

Case Boundary Value Testing
Answer

Boundary values are:

• Lower boundary: ₹10,000
• Upper boundary: ₹5,00,000
Boundary test cases would include:
1. ₹9,999 → Just below minimum → Should be rejected
2. ₹10,000 → Minimum valid → Should be accepted
3. ₹10,001 → Just above minimum → Should be accepted
4. ₹4,99,999 → Just below maximum → Should be accepted
5. ₹5,00,000 → Maximum valid → Should be accepted
6. ₹5,00,001 → Just above maximum → Should be rejected

Dr. Renjith P N Module -2 Blackbox Testing 88

Case Boundary Value Testing
Answer

Why it’s critical:

• Many real-world failures occur at boundary points (e.g., off-by-one errors).
• Users might enter edge values (like ₹10,000 or ₹5,00,000), so missing these cases may allow
invalid entries or block valid ones.
• It ensures the robustness of the input validation logic and helps avoid legal/financial
compliance issues.
Risk if not tested:
• Loan requests below ₹10,000 may get approved incorrectly.
• Valid applications may be wrongly rejected, affecting user trust.

Dr. Renjith P N Module -2 Blackbox Testing 89

Ans:
Why it’s critical:
• Many real-world failures occur at boundary points (e.g., off-by-one
errors).
• Users might enter edge values (like ₹10,000 or ₹5,00,000), so missing
these cases may allow invalid entries or block valid ones.
• It ensures the robustness of the input validation logic and helps avoid
legal/financial compliance issues.
Risk if not tested:
• Loan requests below ₹10,000 may get approved incorrectly.
• Valid applications may be wrongly rejected, affecting user trust.
Example

•For a function that computes the square

root of an integer in the range of 1 and
5000

•Test value?
Example
• For a function that computes the square root of
an integer in the range of 1 and 5000

•Test value:
•{0,1,2,4999,5000,5002,2500}
Example
• Consider a program that reads the age of employees and computes
the average age:

Age Program Average Age

Equivalent Partitioning Testing
Equivalence Partitioning Testing
Equivalence Partitioning Testing

Equivalence Partitioning is a black box testing technique that

divides input data into valid and invalid partitions (classes).

If one value in a partition works, the rest will likely behave
similarly — so test just one value from each class.

Dr. Renjith P N Module -2 Blackbox Testing 95

Equivalence Partitioning Testing
Age Validation for Driving License Application

 Valid age: 18 to 60

Class Type Range Example Input Valid?

Invalid Less than 18 17

Valid 18 to 60 (inclusive) 30

Invalid Greater than 60 65

Dr. Renjith P N Module -2 Blackbox Testing 96

Equivalence Partitioning Testing
General Steps to Apply EPT

Identify the input field(s).

Determine all valid and invalid partitions.
Choose one representative value from each partition.
Write test cases for each selected value.

Dr. Renjith P N Module -2 Blackbox Testing 97

Equivalence Partitioning Testing
Password Test
 Rule: Password must be 6 to 12 characters

Partition Type Input Range Test Case Example Expected Result

Invalid Less than 6 chars "abc" Reject

Valid Between 6–12 chars "secure123" Accept

Invalid More than 12 chars "thisiswaytoolong" Reject

Dr. Renjith P N Module -2 Blackbox Testing 98

Equivalence Partitioning Testing
Practice

 Age (18–60)

 GPA (0.0–10.0)

 Password length (6–12)

 Ticket quantity (1–5)

Dr. Renjith P N Module -2 Blackbox Testing 99

Equivalence Partitioning Testing
Practice - AGE

Less than 18 16 Invalid Below minimum age

Between 18 and
30 Valid Falls within valid age range
Age 60 (inclusive)

Greater than 60 65 Invalid Above maximum age

Dr. Renjith P N Module -2 Blackbox Testing 100

Equivalence Partitioning Testing
Practice - GPA

Less than 0.0 -1 Invalid Below minimum GPA

Between 0.0
and 10.0 7.5 Valid Within valid GPA range
GPA
(inclusive)
Greater than
11 Invalid Above maximum GPA
10.0

Dr. Renjith P N Module -2 Blackbox Testing 101

Equivalence Partitioning Testing
Practice - Password Length

Less than 6
"abc" Invalid Too short
characters

Between 6–12
"secure123" Valid Meets length requirement
characters

More than 12
"thisiswaytoolong" Invalid Too long
characters

Dr. Renjith P N Module -2 Blackbox Testing 102

Equivalence Partitioning Testing
Practice – Ticket Quantity

Less than 1 0 Invalid Below minimum ticket limit

Between 1 and
3 Valid Valid quantity
5 (inclusive)
Exceeds max allowed
Greater than 5 7 Invalid
tickets

Dr. Renjith P N Module -2 Blackbox Testing 103

Difference between Boundary Value and Equivalent Partitioning
Aspect Equivalence Partitioning (EP) Boundary Value Analysis (BVA)

To reduce the number of test cases by To test values at the edges of valid and invalid
Purpose
dividing inputs into groups partitions

Focus Representative values within a partition Values at and around the boundary limits

Test Case One value per equivalence class (valid &

Values at min, max, just below min, just above max
Selection invalid)
Test Coverage
Broad input coverage Edge case coverage
Type

Example Scenario Age input: valid range 18–60 Age input: valid range 18–60

EP Test Cases 17 (invalid), 30 (valid), 65 (invalid) 17, 18, 19, 59, 60, 61

Best Used When You have large input ranges Inputs have critical edge rules

Dr. Renjith P N Module -2 Blackbox Testing 104

Model Question
 A university portal allows GPA input between 0.0 and 10.0. Create test cases using equivalence
partitioning for GPA validation.

 Expected Answer:
• Valid partition: 0.0–10.0 → Test with 0.0, 5.5, 10.0
• Invalid partition: <0.0 → Test with -1.0
• Invalid partition: >10.0 → Test with 11.0
• Optional: Non-numeric input → Test with "ten"

Dr. Renjith P N Module -2 Blackbox Testing 105

State Transition Testing
Black Box Testing Technique
State Transition Testing
State Transition Testing

State Transition Testing is a black-box testing technique

used to test the behaviour of a system when it transitions
from one state to another due to events or inputs.

It’s based on the idea that a system changes state depending

on input values or user actions, and we must verify that the
system behaves correctly in each possible state and
transition.
Dr. Renjith P N Module -2 Blackbox Testing 107
State Transition Testing
When to Use It?

The system behaves differently in different situations (states).

The system has a finite number of states, and the transitions are
triggered by events or conditions.
Examples:
•Login process
•ATMs
•Vending machines
•Elevators
•Traffic signals
•Online shopping cart behavior
Dr. Renjith P N Module -2 Blackbox Testing 108
State Transition Testing
Key Terms

Term Meaning
State A specific condition or situation in which the system can exist.
Event/Input An action that triggers a transition (e.g., clicking a button, entering input).
Transition The movement from one state to another based on an event.
Initial State The state where the system starts.
Final State The end state of the system (if applicable).

Dr. Renjith P N Module -2 Blackbox Testing 109

State Transition Testing
Login System

Current State Input Next State

Start Correct Username/Pwd Valid Login

Start Incorrect Username/Pwd Invalid Login

Invalid Login Incorrect Again Invalid Login

Invalid Login 3rd Wrong Attempt Locked

Invalid Login Correct Input Valid Login

Dr. Renjith P N Module -2 Blackbox Testing 110

State Transition Testing
Advantages of State Transition Testing

• Identifies unexpected states and transitions.

• Helps in testing complex logical flows.

• Can detect missing or invalid transitions.

• Especially useful for real-time systems, UIs, process control, and security

features.

Dr. Renjith P N Module -2 Blackbox Testing 111

State Transition Testing
Limitation of State Transition Testing

• Not suitable if the system does not maintain states.

• Complex systems may lead to state explosion (too many states and

transitions).

• Needs clear state definitions, or testing will be ambiguous.

Dr. Renjith P N Module -2 Blackbox Testing 112

State Transition Testing
Test Case Table

TC ID Start State Input Expected Output Next State

TC01 Start Correct login Access granted Valid Login

TC02 Start Wrong login Retry message Invalid Login

TC03 Invalid 2nd wrong login Retry message Invalid Login

TC04 Invalid 3rd wrong login Account locked Locked

TC05 Invalid Correct login Access granted Valid Login

Dr. Renjith P N Module -2 Blackbox Testing 113

Decision Table Testing
Black Box Testing Technique
Decision Table Testing
What is DTT?

Decision Table Testing is a structured way of testing combinations

of inputs and their corresponding system outputs (or actions).

It is ideal when a system's output depends on multiple conditions

and you need to test all possible combinations of those conditions.

Dr. Renjith P N Module -2 Blackbox Testing 115

Decision Table Testing
When to Use Decision Table Testing?

• When the system has complex decision logic.

• When there are multiple conditions, each with two or more
possible values (true/false, yes/no, etc.).
• When different combinations of inputs result in different
outcomes.
• Especially useful in business rule engines, insurance policies,
form validations, banking applications, etc.

Dr. Renjith P N Module -2 Blackbox Testing 116

Decision Table Testing
Key Components of a Decision Table
Component Description

Conditions Inputs or rules the system checks (e.g., Age > 18, Balance > 1000)

Actions Outputs or results based on conditions (e.g., Approve loan, Deny access)

Rules Columns representing a unique combination of condition values and outcomes

Dr. Renjith P N Module -2 Blackbox Testing 117

Decision Table Testing

Dr. Renjith P N Module -2 Blackbox Testing 118

Decision Table Testing
Credit Card Eligibility

Conditions:

1.Age ≥ 18?

2.Has a Job?

3.Credit Score > 700?

Actions:

•Approve Card

•Reject Application

Dr. Renjith P N Module -2 Blackbox Testing 119

Decision Table Testing

Dr. Renjith P N Module -2 Blackbox Testing 120

Decision Table Testing

Policy for charging customer for certain inflight services:

If the flight is more than half-full and ticket cost is more than

Rs.3000, free meals are served unless it is a domestic flight.

The meals are charged on all domestic flights.

Dr. Renjith P N Module -2 Blackbox Testing 121

Decision Table Testing
 If the flight is more than half-full and ticket cost is more than Rs.3000, free
meals are served unless it is a domestic flight. The meals are charged on all
domestic flights.

Dr. Renjith P N Module -2 Blackbox Testing 122

Decision Table Testing
Check acceptance policy
 Create a decision table for a check acceptance policy. The conditions are:
• Check amount is less than $100
• Customer has a driver's license
• Customer has a check guarantee card
• Check is a two-party check
• Customer is a "preferred customer"
The check can be accepted if:
 Customer has a check guarantee card and a driver's license
 Check is less than $100 and the customer shows a driver's license or a
 check guarantee card
 Customer is a "preferred customer" and check amount is less than $100
 Customer is a "preferred customer" and check is a two-party check

Dr. Renjith P N Module -2 Blackbox Testing 123

Decision Table Testing
 Customers on a ecommerce site get following discount:
 A member get 10% discount for purchases lower than Rs. 2000, else 15% discount
 Purchase using SBI card fetches 5% discount
 If purchase amount after all discount exceeds Rs. 2000 then shipping is free.

Dr. Renjith P N Module -2 Blackbox Testing 124

Decision Table Testing
The "Print Message" is a software that reads 2 character and depending on the values a message
is to be printed.
Ist Character must be A or B
2nd Character must be a digit

If Ist character is A or B and Second character is a digit the file must be updated.
If the Ist character is incorrect message 'x' is to be printed.
If the 2nd character is incorrect message 'Y' to be printed.

Dr. Renjith P N Module -2 Blackbox Testing 125

Cause Effect Graphing Based
Testing
Black Box Testing Technique
Cause Effect Graphing Based Testing
Definition
 Cause-Effect Graphing Testing is a black-box testing technique that helps in designing test

cases by establishing a logical relationship between inputs (causes) and outputs (effects) of a

system using a graphical representation.

Dr. Renjith P N Module -2 Blackbox Testing 127

Cause Effect Graphing Based Testing
Terminologies

Term Description

Cause An input condition

Effect An output condition or system response

A boolean logic diagram showing how causes combine to

Graph
produce effects

Decision Table Created from the graph to derive test cases

Dr. Renjith P N Module -2 Blackbox Testing 128

Cause Effect Graphing Based Testing
Steps involved
1.Identify causes and effects
Extract conditions (causes) and actions (effects) from the requirements.
2.Establish relationships
Use AND, OR, NOT logic to connect causes to effects.
3.Draw the cause-effect graph
Represent the logical relationships in a boolean graph format.
4.Convert the graph to a decision table
The decision table summarizes which combinations of inputs produce which outputs.
5.Generate test cases
Each column in the decision table represents a test case.

Dr. Renjith P N Module -2 Blackbox Testing 129

Cause Effect Graphing Based Testing
Example
A customer gets a discount if:
•They are a premium member
•AND they have made a purchase above ₹1000
Then the system applies a 10% discount

Dr. Renjith P N Module -2 Blackbox Testing 130

Cause Effect Graphing Based Testing
Identify causes and effects

Causes Description
C1 Is premium member
C2 Purchase > ₹1000

Effects Description

E1 Apply 10% discount

Dr. Renjith P N Module -2 Blackbox Testing 131

Cause Effect Graphing Based Testing
Decision Table With TC

Test Case C1 C2 E1 (Apply 10% discount)

TC1 T T Yes
TC2 T F No
TC3 F T No
TC4 F F No

Dr. Renjith P N Module -2 Blackbox Testing 132

Cause Effect Graphing Based Testing
The "Print Message" is a software that reads 2 character and depending on the values a message
is to be printed.
Ist Character must be A or B
2nd Character must be a digit

If Ist character is A or B and Second character is a digit the file must be updated.
If the Ist character is incorrect message 'x' is to be printed.
If the 2nd character is incorrect message 'Y' to be printed.

Dr. Renjith P N Module -2 Blackbox Testing 133

Cause Effect Graphing Based Testing
Advantages

• Helps understand complex logical conditions

• Ensures comprehensive decision logic testing

• Reduces ambiguity in requirements

• Test cases are traceable to specific logic rules

Dr. Renjith P N Module -2 Blackbox Testing 134

Cause Effect Graphing Based Testing
Limitations

• Time-consuming for large systems

• Requires clear, well-written requirements

• Graphing logic becomes complex as causes/effects increase

Dr. Renjith P N Module -2 Blackbox Testing 135

Cause Effect Graphing Based Testing
Problem 2
 If depositing less than Rs. 1 Lakh, rate of interest:
 6% for deposit upto 1 year
 7% for deposit over 1 year but less than 3 years
 8% for deposit 3 years and above.

 If depositing more than Rs. 1 Lakh, rate of interest:

 7% for deposit upto 1 year
 8% for deposit over 1 year but less than 3 years
 9% for deposit 3 years and above.

Dr. Renjith P N Module -2 Blackbox Testing 136

Cause Effect Graph Based Testing
 Requirement Summary

Deposit Amount Tenure Interest Rate

< ₹1,00,000 ≤ 1 year 6%
> 1 yr and < 3 yrs 7%
≥ 3 yrs 8%
> ₹1,00,000 ≤ 1 year 7%
> 1 yr and < 3 yrs 8%
≥ 3 yrs 9%

Dr. Renjith P N Module -2 Blackbox Testing 137

Cause Effect Graph based Testing
 Identify Causes and Effects

ID Description

C1 Deposit < ₹1,00,000

C2 Deposit > ₹1,00,000

C3 Tenure ≤ 1 year

C4 1 year < Tenure < 3 years

C5 Tenure ≥ 3 years

Dr. Renjith P N Module -2 Blackbox Testing 138

Cause Effect Graph based Testing
 Identify Causes and Effects

ID Description
E1 Interest = 6%
E2 Interest = 7%
E3 Interest = 8%
E4 Interest = 9%

Dr. Renjith P N Module -2 Blackbox Testing 139

Cause Effect Graph Based Testing

Interest
TC C1 (<1L) C2 (>1L) C3 (≤1y) C4 (1-3y) C5 (≥3y)
Effect
1 T F T F F E1 → 6%
2 T F F T F E2 → 7%
3 T F F F T E3 → 8%
4 F T T F F E2 → 7%
5 F T F T F E3 → 8%
6 F T F F T E4 → 9%

Dr. Renjith P N Module -2 Blackbox Testing 140

9%
Cause Effect Graphing Based Testing
Online Banking Login System
 Requirements:
1. A user can log in only if:
1. They enter the correct username,
2. AND the correct password,
3. AND the account is not locked.
2. If the password is wrong, the system increments the failed attempt counter.
3. After 3 failed attempts, the account gets locked automatically.
4. If login is successful, the user is redirected to the dashboard.

Dr. Renjith P N Module -2 Blackbox Testing 144

 C1 (Uname C3 (Not C4 (Attempts
TC C2 (Pwd ok) E1 (Login) E2 (Inc fail) E3 (Lock)
ok) locked) ≥ 3)

1 T T T F

2 T F T F

3 T F T T

4 T T F T

5 F F T F

6 F F T T

7 F T T F

Dr. Renjith P N Module -2 Blackbox Testing 145

Cause Effect Graphing Based Testing
Online Shopping Checkout System
 Requirements:
1.Free shipping is available if:
1. The order total ≥ ₹2000
2. AND user is a registered member
2.Apply 10% discount if:
1. The user has a valid coupon
3.Cash on Delivery (COD) is disabled if:
1. The shipping address is in a restricted zone
4.Gift wrap option is enabled if:
1. The user selects it
2. AND the item is eligible for gift wrapping

Dr. Renjith P N Module -2 Blackbox Testing 146

Cause Effect Graphing Based Testing
 Requirements:
1.Free shipping (E1) is available if:
1.The order total ≥ ₹2000 (C1)
2.AND user is a registered member (C2)
2.Apply 10% discount (E2) if:
1.The user has a valid coupon (C3)
3.Cash on Delivery (COD) is disabled (E3) if:
1.The shipping address is in a restricted zone (C4)
4.Gift wrap option is enabled (E4) if:
1.The user selects it (C5)
2.AND the item is eligible for gift wrapping (C6)

Dr. Renjith P N Module -2 Blackbox Testing 147

Model Question – Cause Effect Based Testing
 A bank has deployed a secure approval system for processing high-value fund transfers, which
evaluates several factors before determining how to handle each transaction. The system
considers whether the user has authenticated using both a password and a one-time password,
whether the transfer amount exceeds ₹5 lakhs, if the beneficiary was added within the last 24
hours, whether the transaction occurs outside regular business hours, and whether the device
used is recognized as one previously associated with the user. If both authentication methods
are successfully completed on a known device and the transfer is ₹5 lakhs or less, the
transaction is processed immediately. If both authentication methods are valid but the device
is unfamiliar and the amount exceeds ₹5 lakhs, the transaction is held for manual review. In
situations where the amount is high, the beneficiary is newly added, and the transaction occurs
outside business hours, the system flags it as potentially fraudulent regardless of
authentication status. Any transaction missing either form of authentication is rejected
outright. Even when all credentials and conditions are valid, if the transfer exceeds ₹5 lakhs
and the beneficiary is new, the transaction is held for review. Additionally, if only one of the two
authentication methods is completed and the amount exceeds ₹5 lakhs, the transaction is also
placed on hold.

Dr. Renjith P N Module -2 Blackbox Testing 148

Cause Effect Based Testing
 Conditions (Causes):
• C1: The user is authenticated via password.
• C2: The user is authenticated via OTP (One Time Password).
• C3: The transfer amount is greater than ₹5 lakhs.
• C4: The beneficiary is new (added within the last 24 hours).
• C5: The transaction is initiated outside business hours.
• C6: The device used is recognized (previously used by the user).

Effects:
E1: Transaction is approved immediately.
E2: Transaction is put on hold for manual verification.
E3: Transaction is rejected due to authentication failure.
E4: Fraud alert is triggered to the security team.
Dr. Renjith P N Module -2 Blackbox Testing 149
Model Question - Cause Effect Based Testing
A bank has deployed a secure approval system for processing high-value fund transfers, which
evaluates several factors before determining how to handle each transaction. The system
considers whether the user has authenticated using both a password and a one-time password,
whether the transfer amount exceeds ₹5 lakhs, if the beneficiary was added within the last 24
hours, whether the transaction occurs outside regular business hours, and whether the device
used is recognized as one previously associated with the user. If both authentication methods
are successfully completed on a known device and the transfer is ₹5 lakhs or less, the
transaction is processed immediately. If both authentication methods are valid but the device is
unfamiliar and the amount exceeds ₹5 lakhs, the transaction is held for manual review. In
situations where the amount is high, the beneficiary is newly added, and the transaction occurs
outside business hours, the system flags it as potentially fraudulent regardless of authentication
status. Any transaction missing either form of authentication is rejected outright. Even when all
credentials and conditions are valid, if the transfer exceeds ₹5 lakhs and the beneficiary is new,
the transaction is held for review. Additionally, if only one of the two authentication methods is
completed and the amount exceeds ₹5 lakhs, the transaction is also placed on hold.
Dr. Renjith P N Module -2 Blackbox Testing 150
 New Outside
Password Amount > Known
TC OTP Auth(✓/✗) Beneficiary(✓/ Business Outcome
Auth(✓/✗) ₹5L(✓/✗) Device(✓/✗)
✗) Hours(✓/✗)
Immediate
1 ✓ ✓ ✗ ✗ ✗ ✓
Approval (E1)

2 ✓ ✓ ✓ ✗ ✗ ✗ On Hold (E2)

Fraud Alert
3 ✓ ✓ ✓ ✓ ✓ ✓
(E4)
Rejected
4 ✗ ✓ ✗ ✗ ✗ ✓
(E3)
Rejected
5 ✓ ✗ ✗ ✗ ✗ ✓
(E3)

6 ✓ ✓ ✓ ✓ ✗ ✓ On Hold (E2)

7 ✓ ✗ ✓ ✗ ✗ ✓ On Hold (E2)

8 ✗ ✓ ✓ ✗ ✗ ✓ On Hold (E2)

Fraud Alert
9 ✓ ✓ ✓ ✓ ✓ ✗
(E4)
Dr. Renjith P N Module -2 Blackbox Testing 151
Cause and Effect Graph
• A wholesale retailer has 3 commodities to sell and has 3 types of
customers.
• The discount is given as per following:
• For Board members of the firm order 10% discount irrespective of the
value of the order
• For orders more than 50k agent get discount of 15% and retailer get the
discount of 10%
• For the orders of 20k or more and up to 50k agents get 12% and retailers
get 8% discount.
• The order of less than 20K agent get 8% and the retailer get 5% discount.
• The above rules do not apply to furnitures items where in flat 10%
discount is given to all customers irrespective of the order value.
Decision Table
The "Print Message" is a software that reads 2 character and depending on
the values a message is to be printed.

Ist Character must be A or B

2nd Character must be a digit
If Ist character is A or B and Second character is a digit the file must be
updated.

If the Ist character is incorrect message 'x' is to be printed.

Id the 2nd character is incorrect message 'Y' to be printed.

Design Cause Effect Graph & Decision Table
• For a manufacturing company, the pricing strategy for bulk orders is
determined by the quantity of products ordered. If the order quantity
is less than 100 units, the discount rates vary as follows:
• 5% for orders up to 50 units
• 7% for orders over 50 units but less than 100 units
• For orders of 100 units or more, the discount rates are as follows:
• 7% for orders up to 150 units
• 10% for orders over 150 units but less than 300 units
• 15% for orders of 300 units and above
Error Guessing Based Testing
Black Box Testing Technique
Error Guessing Based Testing
What is Error Guessing?

 Error Guessing is a black-box testing technique where test

cases are designed based on the tester’s experience, intuition,
and understanding of common programming errors.
 Rather than following formal rules or models (like in equivalence
partitioning or decision tables), testers "guess" the errors that
could occur and create tests to uncover them.

Dr. Renjith P N Module -2 Blackbox Testing 156

Error Guessing Based Testing
Key Concepts

Feature Description
Based on tester's domain knowledge and previous
Approach
experience.
Uncover typical errors not covered by other test
Target
techniques.
Type ad-hoc.
Experienced testers familiar with the application
Best suited for
domain.

Dr. Renjith P N Module -2 Blackbox Testing 157

Error Guessing Based Testing
Common Types of Errors Testers Guess

Division by zero
Null or empty input
Invalid data types
Exceeding input boundaries
Database connection issues
Memory leaks
File not found
Missing validations
Dr. Renjith P N Module -2 Blackbox Testing 158
Error Guessing : Simple login page with username and password.

Error Guess Test Case

Username field left blank Try logging in without entering username

Password field left blank Enter username but no password

Special characters in username Use admin!@# as username

Long password input Enter a 200-character-long password

SQL injection Input ' OR 1=1-- as username/password

Dr. Renjith P N Module -2 Blackbox Testing 159
Error Guessing : ATM Withdrawal System

Error Guess Test Case

Try withdrawing ₹50,000 when only
Withdraw more than available balance
₹10,000 is available
Enter invalid PIN Try multiple incorrect PIN entries
Insert expired card Use an expired card for the transaction
Cancel at different stages (after PIN,
Cancel during transaction
before amount)
Network timeout during transaction Simulate network disconnection

Dr. Renjith P N Module -2 Blackbox Testing 160

Error Guessing Based Testing
Advantage

Finds real-world errors missed by structured testing

Leverages tester expertise
Complements formal testing methods

Dr. Renjith P N Module -2 Blackbox Testing 161

Error Guessing Based Testing
Limitations

Not systematic or exhaustive

Highly dependent on tester skill
Can miss rare edge cases if not experienced

Dr. Renjith P N Module -2 Blackbox Testing 162

Special Value Testing
Special Value Testing

• The tester has reasons to believe these value

would execute statements having the risk of
containing bugs.
Single Fault Assumption
• Failures rarely occur as the result of simultaneous occurrence of two
or more faults.

• Under this:
• Hold the values of all but one variable at their nominal values and let
that one variable assume its extreme value
Equivalence Partitioning (Black Box Testing)
By identifying and testing one member of each partition we gain 'good' coverage with 'small'
number of test cases
Testing one member of a partition should be as good as testing any member of the partition

Example - Equivalence Partitioning

For binary search the following partitions exist  Pick specific conditions of the array
 Inputs that conform to pre-conditions  The array has a single value
 Inputs where the precondition is false  Array length is even
 Inputs where the key element is a member of the array  Array length is odd
 Inputs where the key element is not a member of the array

Dr. Renjith P N Module – 2 – Blackbox Testing 167

Equivalence Partitioning (Black Box Testing) Cont.

Example - Equivalence Partitioning

 Example: Assume that we have to test field which accepts SPI (Semester Performance Index)
as input (SPI range is 0 to 10)

SPI * Accepts value 0 to 10

Equivalence Partitioning
Invalid Valid Invalid
<=-1 0 to 10 >=11

 Valid Class: 0 – 10, pick any one input test data from 0 to 10
 Invalid Class 1: <=-1, pick any one input test data less than or equal to -1
 Invalid Class 2: >=11, pick any one input test data greater than or equal to 11
Dr. Renjith P N Module – 2 – Blackbox Testing 168
Boundary Value Analysis (BVA) (Black Box Testing)
 It arises from the fact that most program fail at input boundaries
 Boundary testing is the process of testing between extreme ends or boundaries between
partitions of the input values.
 In Boundary Testing, Equivalence Class Partitioning plays a good role
 Boundary Testing comes after the Equivalence Class Partitioning
 The basic idea in boundary value testing is to select input variable values at their:

Just below the minimum Minimum Just above the minimum

Just below the maximum Maximum Just above the maximum

Boundary

Boundary Values

Dr. Renjith P N Module – 2 – Blackbox Testing 169

Boundary Value Analysis (BVA) (Black Box Testing)
 Suppose system asks for “a number between 100 and 999 inclusive”
 The boundaries are 100 and 999
99 100 101 999 999 1000
 We therefore test for values
Lower boundary Upper boundary
BVA - Advantages
 The BVA is easy to use and remember because of the uniformity of identified tests and the automated
nature of this technique.
 One can easily control the expenses made on the testing by controlling the number of identified test
cases.
 BVA is the best approach in cases where the functionality of a software is based on numerous
variables representing physical quantities.
 The technique is best at user input troubles in the software.
 The procedure and guidelines are crystal clear and easy when it comes to determining the test cases
through BVA.
 The test cases generated through BVA are very small.
Dr. Renjith P N Module – 2 – Blackbox Testing 170
Boundary Value Analysis (BVA) (Black Box Testing) Cont.
BVA - Disadvantages
 This technique sometimes fails to test all the potential input values. And so, the results are
unsure.
 The dependencies with BVA are not tested between two inputs.
 This technique doesn’t fit well when it comes to Boolean Variables.
 It only works well with independent variables that depict quantity.

Dr. Renjith P N Module – 2 – Blackbox Testing 171

White Box Testing
 Also known as structural testing
 White Box Testing is a software testing method in which the internal
structure/design/implementation of the module being tested is known to the tester
 Focus is on ensuring that even abnormal invocations are handled gracefully
 Using white-box testing methods, you can derive test cases that
 Guarantee that all independent paths within a module have been exercised at least once
 Exercise all logical decisions on their true and false sides
 Execute all loops at their boundaries
 Exercise internal data structures to ensure their validity

...our goal is to ensure that all

statements and conditions
have been executed at least
once ...

Dr. Renjith P N Module -2 Blackbox Testing 172

White Box Testing Cont.
 It is applicable to the following levels of software testing
 Unit Testing: For testing paths within a unit
 Integration Testing: For testing paths between units
 System Testing: For testing paths between subsystems

Advantages Disadvantages
 Testing can be commenced  Since tests can be very complex, highly skilled
at an earlier stage as one resources are required, with thorough knowledge of
need not wait for the GUI to programming and implementation
be available.  Test script maintenance can be a burden, if the
 Testing is more thorough, implementation changes too frequently
with the possibility of  Since this method of testing is closely tied with the
covering most paths application being testing, tools to cater to every kind of
implementation/platform may not be readily available

Dr. Renjith P N Module – 2 Blackbox Testing 173

White-box testing strategies
 One white-box testing strategy is said to be stronger than another strategy, if all types of errors
detected by the first testing strategy is also detected by the second testing strategy, and the
second testing strategy additionally detects some more types of errors.
White-box testing strategies
1 Statement coverage 2 Branch coverage 3 Path coverage
Statement coverage
 It aims to design test cases so that every statement in a program is executed at least once
 Principal idea is unless a statement is executed, it is very hard to determine if an error exists
in that statement
 Unless a statement is executed, it is very difficult to observe whether it causes failure due to
some illegal memory access, wrong result computation, etc.

Dr. Renjith P N Module – 2 – Blackbox Testing 174

White-box testing strategies Cont.
Consider the Euclid’s GCD computation algorithm

int compute_gcd(x, y) By choosing the test set {(x=3, y=3),

int x, y; (x=4, y=3), (x=3, y=4)}, we can
{ exercise the program such that all
statements are executed at least
1 while (x! = y){ once.
2 if (x>y) then
3 x= x – y;
4 else y= y – x;
5 }
6 return x;
}

Dr. Renjith P N Module – 2 – Blackbox Testing 175

White-box testing strategies Cont.
Branch coverage
 In the branch coverage based testing strategy, test cases are designed to make each branch
condition to assume true and false values in turn
 It is also known as edge Testing as in this testing scheme, each edge of a program’s control
flow graph is traversed at least once
 Branch coverage guarantees statement coverage, so it is stronger strategy compared to
Statement Coverage.
Path Coverage
 In this strategy test cases are executed in such a way that every path is executed at least
once
 All possible control paths taken, including
 All loop paths taken zero, once and multiple items in technique
 The test case are prepared based on the logical complexity measure of the procedure design
 Flow graph, Cyclomatic Complexity and Graph Metrices are used to arrive at basis path.
Dr. Renjith P N Module – 2 – Blackbox Testing 176
White-box testing strategies Cont.
Branch coverage Path Coverage
 In the branch coverage based testing  In this strategy test cases are executed in
strategy, test cases are designed to make such a way that every path is executed at
each branch condition to assume true least once
and false values in turn  All possible control paths taken, including
 It is also known as edge Testing as in this  All loop paths taken zero, once and multiple
testing scheme, each edge of a program’s items in technique
control flow graph is traversed at least  The test case are prepared based on the logical
once complexity measure of the procedure design

 Branch coverage guarantees statement  Flow graph, Cyclomatic Complexity and

coverage, so it is stronger strategy Graph Metrices are used to arrive at basis
compared to Statement Coverage. path.

Dr. Renjith P N Module -2 Blackbox Testing 177

Grey Box Testing
 Combination of white box and black box testing
 Tester has access to source code, but uses it in a restricted manner
 Test cases are still written using specifications based on expected outputs for given input
 These test cases are informed by program code structure

Dr. Renjith P N Module -2 Blackbox Testing 178

Testing Object Oriented Applications
Unit Testing in the OO Context

 The concept of the unit testing changes in object-oriented

software
 Encapsulation drives the definition of classes and objects
 Means, each class and each instance of a class (object) packages
attributes (data) and the operations (methods or services) that
manipulate these data
 Rather than testing an individual module, the smallest testable unit is
the encapsulated class
 Unlike unit testing of conventional software,
 which focuses on the algorithmic detail of a module and the data that
flows 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

Dr. Renjith P N Module -2 Blackbox Testing 179

Integration Testing in the OO Context
 Object-oriented software does not have a hierarchical control structure,
 conventional top-down and bottom-up integration strategies have little meaning
 There are two different strategies for integration testing of OO systems.
1. Thread-based testing
▪ integrates the set of classes required to respond to one input or event for the system
▪ Each thread is integrated and tested individually
▪ Regression testing is applied to ensure that no side effects occur
2. Use-based testing
▪ begins the construction of the system by testing those classes (called independent classes) that use very few (if any)
of server classes
▪ After the independent classes are tested, the next layer of classes, called dependent classes, that use the
independent classes are tested
 Cluster testing is one step in the integration testing of OO software
 Here, a cluster of collaborating classes is exercised by designing test cases that attempt to
uncover

Dr. Renjith P N Module – 2 – Blackbox Testing 180

Validation Testing in an OO Context
 At the validation or system level, the details of class connections disappear
 Like conventional validation, the validation of OO software focuses on user-visible actions and
user-recognizable outputs from the system
 To assist in the derivation of validation tests, the tester should draw upon use cases that are
part of the requirements model
 Conventional black-box testing methods can be used to drive validation tests

Dr. Renjith P N Module – 2 – Blackbox Testing 181

Testing Web Applications
 WebApp testing is a collection of related activities with a single
goal to uncover errors in WebApp content, function, usability,
navigability, performance, capacity, and security
 To accomplish this, a testing strategy that encompasses both
reviews and executable testing is applied.
Dimensions of Quality
 Content is evaluated at both a syntactic and semantic level.
 At the syntactic level spelling, punctuation, and grammar are
assessed for text-based documents.
 At a semantic level correctness of information presented,
Consistency across the entire content object and related
objects, and lack of ambiguity are all assessed.

Dr. Renjith P N Module – 2 – Blackbox Testing 182

Dimensions of Quality Cont.
 Function is tested to uncover errors that indicate lack of conformance to customer requirements
 Structure is assessed to ensure that it properly delivers WebApp content
 Usability is tested to ensure that each category of user is supported by the interface and can learn
and apply all required navigation.
 Navigability is tested to ensure that all navigation syntax and semantics are exercised to uncover
any navigation errors
 Ex., dead links, improper links, and erroneous links
 Performance is tested under a variety of operating conditions, configurations and loading
 to ensure that the system is responsive to user interaction and handles extreme loading
 Compatibility is tested by executing the WebApp in a variety of different host configurations on
both the client and server sides
 Interoperability is tested to ensure that the WebApp properly interfaces with other applications
and/or databases
 Security is tested by assessing potential vulnerabilities

Dr. Renjith P N Module – 2 – Blackbox Testing 183

Content Testing User Interface Testing
 Errors in WebApp content can be Verification and validation of a WebApp user
 as trivial as minor typographical errors or interface occurs at three distinct points
 as significant as incorrect information, improper
organization, or violation of intellectual property
1. During requirements analysis
laws  the interface model is reviewed to ensure that it
conforms to stakeholder requirements
 Content testing attempts to uncover these
and many other problems before the user 2. During design
encounters them  the interface design model is reviewed to
ensure that generic quality criteria established
 Content testing combines both reviews and for all user interfaces have been achieved
the generation of executable test cases 3. During testing
 Reviews are applied to uncover semantic  the focus shifts to the execution of application-
errors in content specific aspects of user interaction as they are
manifested by interface syntax and semantics.
 Executable testing is used to uncover
content errors that can be traced to  In addition, testing provides a final
dynamically derived content that is driven by assessment of usability
data acquired from one or more databases.
Dr. Renjith P N Module – 2 – Blackbox Testing 184
Component-Level Testing Navigation Testing
 Component-level testing (function  The job of navigation testing is to ensure
testing), focuses on a set of tests that that
attempt to uncover errors in WebApp  the mechanisms that allow the WebApp user to
functions. travel through the WebApp are all functional
and,
 Each WebApp function is a software  to validate that each Navigation Semantic Unit
component (implemented in one of a (NSU) can be achieved by the appropriate user
variety of programming languages) category
 WebApp function can be tested using black-  Navigation mechanisms should be tested
box (and in some cases, white-box)
techniques. are
 Navigation links,
 Component-level test cases are often  Redirects,
driven by forms-level input.  Bookmarks,
 Once forms data are defined, the user selects  Frames and framesets,
a button or other control mechanism to initiate
execution.  Site maps,
 Internal search engines.

Dr. Renjith P N Module – 2 – Blackbox Testing 185

Configuration Testing Security Testing
 Configuration variability and instability are  Security tests are designed to probe
important factors that make WebApp testing a  vulnerabilities of the client-side
challenge. environment,
 the network communications that occur
 Hardware, operating system(s), browsers, as data are passed from client to server
storage capacity, network communication and back again, and
speeds, and a variety of other client-side factors  the server-side environment.
are difficult to predict for each user.
 Each of these domains can be
 One user’s impression of the WebApp and the attacked, and it is the job of the
manner in which he/she interacts with it can security tester to uncover weaknesses
differ significantly.  that can be exploited by those with the
 Configuration testing is to test a set of probable intent to do so.
client-side and server-side configurations
 to ensure that the user experience will be the same
on all of them and,
 to isolate errors that may be specific to a particular
configuration
Dr. Renjith P N Module – 2 – Blackbox Testing 186
Performance Testing
 Performance testing is used to uncover
 performance problems that can result from lack of server-side resources,
 inappropriate network bandwidth,
 inadequate database capabilities,
 faulty or weak operating system capabilities,
 poorly designed WebApp functionality, and
 other hardware or software issues that can lead to degraded client-server performance

Dr. Renjith P N Module – 2 – Blackbox Testing 187

 Software Testing

Thank
You

Dr. Renjith P N
School of Computer Science and Engineering
Vellore Institute of Technology, Chennai Campus
[email protected]
91-9840330858