Scribd
Upload
12 views

Software Testing Methodologies & Black Box Testing Techniques

Uploaded by

keshavachittari2024
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
12 views

Software Testing Methodologies & Black Box Testing Techniques

Uploaded by

keshavachittari2024
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Software Testing Methodologies

1. White Box Testing


This techniques analyzes the internal structures the used data structures, internal
design, code structure, and the working of the software rather than just the
functionality as in black box testing. It is also called glass box testing or clear box
testing or structural testing. White Box Testing is also known as transparent testing,
open box testing.

2. Black Box Testing


This is a method of software testing that examines the functionality of an application
based on the specifications. It is also known as Specifications based testing.
Independent Testing Team usually performs this type of testing during the software
testing life cycle.
3. Grey Box Testing
This is a software testing method to test the software application with partial
knowledge of the internal working structure. It is a combination of black box and
white box testing because it involves access to internal coding to design test cases as
white box testing and testing practices are done at functionality level as black box
testing.

GreyBox testing commonly identifies context-specific errors that belong to web


systems. For example; while testing, if tester encounters any defect then he makes
changes in code to resolve the defect and then test it again in real time. It
concentrates on all the layers of any complex software system to increase testing
coverage. It gives the ability to test both presentation layer as well as internal coding
structure. It is primarily used in integration testing and penetration testing.

Black box Test Design Techniques


1) Equivalence Partitioning (EP)
2) Boundary Value Analysis (BVA)
3) Decision Table Testing
4) State Transition Testing
5) Use Case Testing Etc…

1) Equivalence Partitioning (EP)


• It can be applied at any level of testing (Unit, Integration, System and
Acceptance Testing)
• In Equivalence Partitioning, inputs to the Software are divided into groups
that are expected to exhibit similar behavior.
• Equivalence Partitions/Classes can be found for both valid data and invalid
data.
Example 1 (Data Range):
Tickets field in a Reservation system accepts 1 to 10 Tickets only.
Partition 1 Partition 2 Partition 3
-Ne to 00 0 1 to 10 11 to 99 or above
(Invalid) (Valid) (Invalid)
Example 2 (Data Type):
Customer Identification Number field in a CRM system accepts only
numbers.
Partition 1 Partition 2 Partition 3 Partition 4
Alpha bytes Numbers Special Characters Alpha-numeric
(Invalid) (Valid) (Invalid) (Invalid)
Example 3 (Data Size)
Phone Number filed accepts 10 digits number only
Partition 1 Partition 2 Partition 3
Below 10 10 Above 10
(Invalid) (Valid) (Invalid)
Example 4 (Others)
A Payment management system accepts credit card payments only
Partition 1 Partition 2 Partition 3
Credit card Net Banking Cash on Delivery
(Valid) (Invalid) (Invalid)

2) Boundary Value Analysis (BVA)


• The maximum and minimum values of a partition are its boundary values.
• Behavior at edge of each equivalence partition is more likely to be
incorrect than behavior within the partition.
• Boundary value analysis can be applied at all Test levels(Unit, Integration,
System and Acceptance Testing).
Example 1:
Partition 1 Partition 2 Partition 3
0 1 to 10 11 to 99 or above
(Invalid) (Valid) (Invalid)
Minimum/maximum 0
Minimum 1
Maximum 10
Minimum 11
Maximum 99
————————————-
Example 3 (Data Size)
Phone Number filed accepts 10 digits number only

Partition 1 Partition 2 Partition 3


Below 10 10 Above 10
(Invalid) (Valid) (Invalid)
Minimum -9
Minimum and Maximum – 10
Maximum -11
—————————————-
Example: User Id field accepts 10 to 20 characters
Partition 1 Partition 2 Partition 3
Below 10 10 to 20 21 to 99
Minimum -1
Maximum – 9
Minimum – 10
Maximum – 20
Minimum – 21
Maximum -99

3) Decision Table Testing


• The decision tables are good way to capture system requirements that
contain logical conditions.
• It may be applied for all situations when the action of the software
depends on logical decisions.
BSRB (Govt) System Job eligibility criteria,
Age should be in between 21 and 35
Conditions:
i) For SC or ST Candidates 5 Years age relaxation
ii) For BC Candidates 5 Years age relaxation
iii) PHC Candidates 5 Years age relaxation
Category Age Valid/Invalid
———————————————-
OC 20 Invalid
OC 21 Valid
OC 35 Valid
OC 36 Valid
BC 36 Valid
BC 39 Invalid
SC 39 Valid
PHC 39 Valid
ST 40 Valid
—————————————————–
Banking System interest rates For fixed deposits.
1 to 2 years 7%
2 to 3 Years 8%
3 to 5 Years 10%
Condition:
For Senior citizens 0.5% extra for all ranges
Age Period Interest Rate
———————————–
25 1year 7%
35 2.5 8%
56 4 10%
66 4 10.5%

4) State Transition Testing

• In State transition Testing Test cases are designed to execute valid and
invalid state transitions.
• A System (Application Under Test) may exhibit a different response on
current conditions or previous history.
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.

In the diagram whenever the user enters the correct PIN he is moved to Access
granted state, and if he enters the wrong password he is moved to next try and if he
does the same for the 3rd time the account blocked state is reached.

5) Use Case Testing


• In Use Case Testing Test Cases are designed to execute User Scenarios or
Business Scenarios.
• A Use Case describes interactions between actors, including users and the
system.
• A Use case usually has a mainstream scenario and sometimes alternative
scenarios.
Another example:
Business Scenario: ATM Cash Withdrawal operation
Mainstream Scenario:
1)
User: Inserts ATM Card
System: Asks for PIN
2)
User: Enters PIN
System: Validates PIN and asks to select language
3)
User: Selects Language
System: Asks to select Account Type
4)
User: Selects Account Type
System: Asks to enter Amount
5)
User: Enters Amount
System: Releases Money
————————————————–
Alternatives
2a) Suppose if user enters invalid Pin
System: Shows error message and asks to enter correct PIN
User: Enters Correct PIN
———————–
4a) Suppose if user selects incorrect Account Type

System: Shows error and asks to select correct Account Type


User: Select correct account type
5a) If User enters incorrect amount (More than the balance amount or more
than the day limit)
System: Shows Error message and asks to enter correct amount
User: Enters correct amount

You might also like