• There are various forms of
acceptance testing:
✔ User acceptance Testing
✔ Business acceptance Testing
✔ Alpha Testing
✔ Beta Testing
• User acceptance testing is
used to determine whether
the product is working for
the user correctly.
USER • Specific requirements
ACCEPTAN which are quite often used
by the customers are
CE TESTING primarily picked for the
testing purpose. This is also
termed as End-User
Testing.
• BAT is used to determine
whether the product meets the
business goals and purposes or
not.
BUSINESS • BAT mainly focuses on business
ACCEPTAN profits which are quite
challenging due to the changing
CE TESTING market conditions and new
technologies so that the current
implementation may have to
being changed which result in
extra budgets.
• Alpha testing is used to
determine the product in the
development testing
ALPHA environment by a
TESTING specialized testers team
usually called alpha testers.
• Beta testing is used to assess
the product by exposing it to
the real end-users, usually
called beta testers in their
environment.
BETA • Feedback is collected from
TESTING the users and the defects are
fixed.
• Also, this helps in enhancing
the product to give a rich user
experience.
ACCEPTANCE CRITERIA
Functional
Correctness and Data Integrity Data Conversion Usability
Completeness
Confidentiality Installability and
Performance Timeliness
and Availability Upgradability
Scalability Documentation
INTRODUCTION:
Regression Testing
• Regression Testing is the process of
testing the modified parts of the code
and the parts that might get affected
due to the modifications to ensure that
no new errors have been introduced in
the software after the modifications
have been made.
• Regression means return of something
and in the software field, it refers to
the return of a bug.
PROCESS
TECHNIQ
UES FOR
THE
SELECTIO
N OF TEST
CASES
It ensures that no new bugs has been
introduced after adding new functionalities
As most
to the of the test cases used in Regression
system.
Testing are selected from the existing test
suite and we already know their expected
outputs. Hence, it can be easily automated
by the automated
It helps to maintaintools.
the quality of the source
code.
ADAVNTA
GES
It can be time and resource consuming if
automated tools are not used.
It is required even after very small changes in
the code.
DISADVANT
AGES
Selenium
WATIR (Web Application Testing In Ruby)
QTP (Quick Test Professional)
RFT (Rational Functional Tester)
TOOLS Winrunner
Silktest
INTRODUCTION : Functional
Testing
Functional
Testing is a
type of
Software
Functional
Testing in
testing
which the
ensures
system is
that
tested the
This testing
requiremen
against the
is
ts not
or
functional
concerned
specificatio
requiremen
about
ns are the
ts and
Each
source
properly code
specificatio
functionalit
of
ns.the by
satisfied
yapplication.
of the
the
software
application.
This testing
application
focuses
is testedonby
checking
providingof
user
appropriate
interface,
test input,
APIs,
expecting
PROCESS
MAJOR FUNCTIONAL TESTING
TECHNIQUES
Unit
Testing
Integratio
n Testing
Smoke
Testing
Interface
Testing
Usability
Testing
System
Testing
Regression
Testing
User
Acceptance
Testing
TESTING TOOLS
Selenium QTP JUnit
SoapUI Watir
ADVANTAGES
It ensures to
deliver a
bug-free
product.
It ensures to
deliver a
high-quality
product.
No
assumptions
about the
structure of the
system.
This testing is
focused on the
specifications
as per the
customer
usage.
DISADVANTAGES
There are
high
chances
Logical errors can be
of
missed
product.
out in the
performi
ng
If the requirement is
redundan
not complete then
performing this
tdifficult.
testing.
testing becomes
INTRODUCTION : Black Box (functional )
The technique of testing without having any knowledge of the interior workings of
the application is called black-box testing.
The tester is oblivious to the system architecture and does not have access to the
source code.
Typically, while performing a black-box test, a tester will interact with the system's
user interface by providing inputs and examining outputs without knowing how
and where the inputs are worked upon.
1. Syntax Driven Testing –
This type of testing is applied to systems that can be syntactically represented
by some language.
For example- compilers,language that can be represented by context free
grammar.
In this, the test cases are generated so that each grammar rule is used at least
once.
2. Equivalence partitioning
• It is often seen that many type of inputs
work similarly so instead of giving all of them
separately we can group them together and
test only one input of each group.
• The idea is to partition the input domain of
the system into a number of equivalence
classes such that each member of class
works in a similar way, i.e., if a test case in
one class results in some error, other
members of class would also result into
same error.
The technique involves two steps:
• Identification of equivalence class
– Partition any input domain into minimum
two sets: valid values and invalid values.
For example, if the valid range is 0 to 100
then select one valid input like 49 and one
invalid like 104.
• Generating test cases –
(i) To each valid and invalid class of input assign
unique identification number.
(ii) Write test case covering all valid and invalid
test case considering that no two invalid inputs
mask each other.
3. Boundary value analysis
• Boundaries are very good places for errors to
occur.
• Hence if test cases are designed for boundary
values of input domain then the efficiency of
testing improves and probability of finding errors
also increase.
• For example – If valid range is 10 to 100 then
test for 10,100 also apart from valid and invalid
inputs.
4. Cause effect Graphing
• This technique establishes relationship between logical
input called causes with corresponding actions called
effect.
• The causes and effects are represented using Boolean
graphs.
• The following steps are followed:
1. Identify inputs (causes) and outputs (effect).
2. Develop cause effect graph.
3. Transform the graph into decision table.
4. Convert decision table rules to test cases.
• It can be converted into decision table like:
Each column corresponds to a rule which will become a test case for
testing.
So there will be 4 test cases.
1 2 3 4
Cause C1 1 0 0 0
s C2 0 1 0 0
C3 0 0 1 1
C4 1 0 0 0
C5 0 1 1 0
C6 0 0 0 1
Effects E1 X - - -
E2 - X - -
E3 - - X -
E4 - - - X
5. Requirement based testing
• It includes validating the requirements given
in SRS of software system.
6. Compatibility testing
• The test case result not only depend on product but also
infrastructure for delivering functionality.
• When the infrastructure parameters are changed it is still
expected to work properly.
• Some parameters that generally affect compatibility of
software are:
Processor (Pentium 3,Pentium 4) and number of processors.
Architecture and characteristic of machine (32 bit or 64 bit).
Back-end components such as database servers.
Operating System (Windows, Linux, etc).
Static Testing is a
type of a Software
Testing method
which is performed
to check the defects
in software without
actually
Dynamicexecuting
Testing
the code
checks ofcode
the the is
software
executed to detect
application.
the defects.
INTRODUCTION
Static Testing Static testing is
performed in early
stage of
development to
avoid errors as it is
easier to find
sources
The errorsof failures
that can’t
and it can
not be be fixed
found using
easily. Testing,
Dynamic
can be easily found
by Static Testing.
Static testing
Review (in syllabus) Analysis
WALKTHROUGH
• A walkthrough is conducted by the author of the ‘document under
review’ who takes the participants through the document and his or her
thought processes, to achieve a common understanding and to gather
feedback.
• This is especially useful if people from outside the software discipline
are present, who are not used to, or cannot easily understand software
development documents.
• The content of the document is explained step by step by the author, to
reach consensus on changes or to gather information.
• The participants are selected from different departments and
backgrounds If the audience represents a broad section of skills and
disciplines, it can give assurance that no major defects are ‘missed’ in
the walk-through.
• A walkthrough is especially useful for higher-level documents, such as
requirement specifications and architectural documents.
TECHNICAL REVIEW
• A technical review is a discussion meeting that focuses on technical
content of a document.
• It is led by a trained moderator, but also can be led by a technical
expert.
• Compared to inspections, technical reviews are less formal and there is
little or no focus on defect identification on the basis of referenced
documents.
• The experts that are needed to be present for a technical review can be
architects, chief designers and key users.
• It is often performed as a peer review without management
participation.
INSPECTIONS
• Inspection is the most formal review type.
• It is usually led by a trained moderator (certainly not by
the author).
• The document under inspection is prepared and checked
thoroughly by the reviewers before the meeting, comparing
the work product with its sources and other referenced
documents, and using rules and checklists.
• In the inspection meeting the defects found are logged.
• Depending on the organization and the objectives of a
project, inspections can be balanced to serve a number of
goals.
ADVANTAGES
• Types of defects that can be found during static testing are:
deviations from standards, missing requirements, design defects,
non-maintainable code and inconsistent interface specifications.
• Since static testing can start early in the life cycle, early
feedback on quality issues can be established, e.g. an early
validation of user requirements and not just late in the life cycle
during acceptance testing.
• By detecting defects at an early stage, rework costs are relatively
low and thus a relatively cheap improvement of the quality of
software products can be achieved.
• The feedback and suggestions document from the static testing
process allows for process improvement, which supports the
avoidance of similar errors being made in the future.
THANK
YOU!!!!!
