�ݺ�ߣ

DO NOT DISTRIBUTE – HIGHLY CONFIDENTIAL
Agenda:
• Testing Methodologies
• Software Testing Principles

Testing Methodologies:
• White Box Testing
• Black Box Testing
• Grey Box Testing
2www.talentsprint.com

White Box Testing:
• Testing the Source Code.
• Developers
• Also called clear box testing or glass box
testing or structural testing.
• Unit Testing and Integration Testing.

Reasons for white box testing:
• Finding defects are easy as the source code is visible.
• To remove as many defects as possible.
• Fixing defects that are identified in black box testing is time
consuming because the root cause analysis takes time.
• White box testing is more economical when compared with
black box testing.
• To ensure 100% code coverage.

White box testing Covers:
• Testing that takes into account internal mechanism of a
system or component, types include Statement Testing,
Branch testing, Path testing etc…
• The tester is going to test the chronological order of
program.
• Test cases are designed which can test internal logic of the
program.

How to Test Source Code:
• Derive test cases that:
 Exercise all independent execution paths.
 Exercise all logical decisions on both true and false
sides.
 Execute all loops at their boundaries and within
operational bounds.

What to Test in Source Code:
Control flow testing:
1. Statement coverage
2. Decision coverage
3. Condition coverage
4. Multiple condition coverage
5. Path coverage

White Box Testing:
Disadvantages:
1. Does not ensure that user’s requirements are met.
2. Does not establish if the decisions / conditions /
paths / statements are insufficient.

Black Box Testing:
• Conducted on application.
• Test Engineers or by Domain experts.
• To confirm whether the application is developed as per
the customer business requirements or not.
• Also called Requirement base testing or Specification
base testing or Functional Testing.
• BBT= System Testing + UAT.

Black Box Testing:

Reasons for Black box testing:
• In WBT developers will check does the source code is
working as per expected or not, where as in the black box
testing the testers will check whether the application
working according to the end user business requirements
or not.
• The objective of white box testing is code coverage where
as the objective black box testing is requirement coverage.
• WBT will be conducted in a technical perception where as
BBT will be conducted with an end user perception.

• White box testing will be conducted in a positive
perception where there is a chance of bugs left in where as
black box testing will be conducted in a negative perception
where there is a chance of identifying more defects.
• Non functional requirements will not be validated in white
box testing, to check that same black box testing is needed.
• Testing based exclusively on analysis of requirements
(specification, user documentation, etc..)

• Also called functional testing or “data-driven” or “I/O-
driven” testing.
• The test cases are based on specifications.
• Black-box testing techniques apply to all levels of testing
(e.g., unit/ component and system).
• Test planning can begin early in the software process.
• Black box testing is practiced widely.
• Conducted for Integration testing, System Testing &
Acceptance Testing.

Black box testing:
Test Case Design Methods:
1. Commonly used methods
1. Equivalence Partitioning Method
2. Boundary value Analysis
3. Error guessing
4. Decision Table Method
2. Leaser used methods
1. Cause Effect Graph
2. State transition testing

Grey box testing:
• It is a combination of white box testing and black box testing
i.e. if we interested with both structural and non-structural
components to validate any scenario in the system then it is
called grey box testing.
• Note: Database testing is a best example for grey box testing.

Software Testing Principles:
Early Testing:
– Testing should start as early as possible in the SDLC.
Testing shows presence of Defects:
– We have to test a application with an intension of showing defects.
For this negative testing is the best approach.
Testing is context Dependant:
– We have to select or opt appropriate testing approach based on the
type of application we are testing.

Risk Based Testing:
– Identifying the operations which most likely to cause failures and
then testing these functionalities on priority basis is called Risk based
Testing.
Exhaustive Testing is impossible:
– Testing everything is called Exhaustive Testing.
– If you test functionality with all possible valid and invalid inputs then
it is called Exhaustive Testing.

Pesticide Paradox:
– If prepared test cases are not finding defects, add/ revise test cases to
find more defects.
– The prepared test cases are not helping to find defects then add or
modify the test cases for better testing.
Defect Clustering:
– The small number of modules or functionality may contain more
number of defects. Concentrate more on testing these functionalities.
Absence of Errors is a Fallocy: Finding and fixing defects. 100% bug free
app is impossible.

Summary:
• In this session we have discussed
 Testing Methodologies
 Software Testing Principles

Points to Remember:
• Cost of fixing defects will increases over the time in
development life cycle. So, to reduce cost of fixing defects
early testing is required.
• Defects identified at early stages are economical to fix.

�ݺ�ߣ

Mt s3 methodoligies&principles

More Related Content

Mt s3 methodoligies&principles