Self-Notes for Manual Testing

INDEX
Manual Testing
SQL (Structured Query
Language)
Core Java
Selenium
Maven
TestNG (Test Next Generation)
API Testing
Git
 Jenkins

 Project Preparation :
- Data Driven Testing Framework
- Page Object Model
- Page factory Design Pattern
- Day 2 Day activity in IT Company
Automation Framework Setup From
Scratch
- Mock Interview After 2weeks
 Who developed Testing?
 “TOM KILBURN” a Computer Scientist is
responsible for introducing software
testing in year 1948.

1.What is testing?
 Process of checking the quality of the
product before launching is known as
testing.
 Testing means verifying the behaviour of
the software based on the client
requirements and make sure that the
software is user friendly and easy to use.

2.Why testing is important?

 Testing is the most important part of a
software to maintain the Reputation and
the good quality of the app in the Market.
 Testing Principle :

Testing shows the presents of

defects :

 Software testing reduces the presence of

defects.
 Software testing talks about the presence of
defects and it doesn't talk about the absence of
defects.
 Software testing can ensure that defects are
present, but it can’t prove that software is
defect-free.
 Even after multiple times of testing can never
ensure that software is 100% bug-free.
  Testing can reduce the number of defects but
not removes all defects.
"We can never say that our system is
defect free"
Exhaustive testing is not possible :

 It is the process of testing the functionality

of the software in all possible inputs (valid or
invalid) and pre-conditions is known as
exhaustive testing.
 Exhaustive testing is impossible means the
software can never test at every test case.
 It can test only some test cases and assume
that the software is correct, and it will
produce the correct output in every test
case.
 If the software will test every test case, then
it will take more cost, efforts, time, etc., and
which is impractical.

Early Testing :
 To find the defect in the software, early test
activity shall be started.
 The defect detected in the early phases of
SDLC will be very less expensive.
 For better performance of software, software
testing will start at the initial phase i.e.,
testing will perform at the requirement
analysis phase.

PHASES OF SDLC :

Defect clustering :
In a project, a small number of
the module can contains most of
the defects.
  Pareto Principle to software
testing state that 80% of software
defect comes from 20% of
modules.

Pesticide Paradox :
 Repeating the same test cases, again
and again, will not find new bugs.
 So, it is necessary to review the test cases
and add or update test cases to find new
bugs.

Testing is context-dependent :
 The testing approach depends on the
context of the software developed.
 Different types of software need to perform
different types of testing.
For example, The testing of the e-
commerce site is different from the
testing of the Android application.
 Absence of errors fallacy :
If a built software is 99% bug-free but it does
not follow the user requirement, then it is
useless.
It is not only necessary that software is 99%
bug-free but it is also mandatory to fulfil all the
customer requirements.

Skill set for SDET :

Preparing software tests
Understanding the testing process
Following sign-off procedures
Automating software test cases
Understanding DevOps and Agile methods
Understanding programming languages
Fitting into the systems development life
cycle
Learning current technology trends
Running cross-browser testing

Introduction of SDLC :
The software development life cycle (SDLC) is a
process which is used to develop software.
SDLC is a step-by-step procedure need to be
followed by the organization to design and
develop a high-quality product.
The phases of software development life cycle
are which describes that how to develop,
maintain software.
The life cycle aims to develop a good quality
product/software.
SDLC produces intermediate products that can be
reviewed to check whether they work according to
customer requirement.
c

WATERFALL MODEL :
 Classical waterfall model is the basic software
development life cycle model.
 It is very simple but idealistic.
 Earlier this model was very popular but
nowadays it is not in used.
 It is very important because all the other
software development life cycle models are
based on the classical waterfall model.

FEASIBILITY STUDY :
 The main goal of this phase is to determine
whether it would be financially and
technically feasible to develop the software.
 The feasibility Study involves understanding
the problem and then determine the various
possible strategies to solve the problem.
 These different identified solutions are
analysed based on their benefits and
drawbacks, The best solution is chosen, and
all the phases are carried out as per this
solution strategy.
 REQUIREMENTS ANALYSIS &
SPECIFICATION:

 The aim of the requirement analysis and

specification phase is to understand the
exact requirements of the customer and
document them properly.

 This phase consists of two different

activities
1. Requirement gathering and analysis
2. System Requirement Specification

DESIGN:
 The aim of the design phase is to transform
the requirements specified in the BRS
Document into a structure that is suitable for
implementation in some programming
language.

CODING AND UNIT TESTING :

 In coding phase software design is translated
into source code using any suitable
programming language.
 Thus, each designed module is coded.
 The aim of the unit testing phase is to check
whether each module is working properly or
not.

INTEGRATION & SYSTEM TESTING:

 Integration of different modules are
undertaken soon after they have been coded
and unit tested
 Integration of various modules is carried out
incrementally over several steps.
 During each integration step, previously
planned modules are added to the partially
integrated system and the resultant system
is tested.
 Finally, after all the modules have been
successfully integrated and tested, the full
working system is obtained, and system
testing is carried out on this.

MAINTENANCE :
 Maintenance is the most important phase of
a software life cycle.
 The effort spent on maintenance is the 60%
of the total effort spent to develop a full
software.

ADVANTAGES :
 Simple and easy to understand and use.
 Each Phase has specific deliverables and
a review process
 Works well for smaller projects where
requirements are very well understood.
 Well understand milestones.

DISADVANTAGES :
 No working software isn’t produced until
late during the life cycle.
 Not a good model for complex and
object-oriented projects.
 Poor model for long and ongoing
projects.
 Not suitable for the projects where
requirements are at a moderate to high
risk of changing. So, risk and
uncertainity is high with this process
model.
 It is difficult to measure progress within
stages.
 Adjusting scope and a life cycle can end
a project.
 VERIFICATION :
 Jab hum koi documents ke upar testing
karte hai without executing the code.
 It involves static analysis technique
(Review) done without executing code.
 It is the process of evaluation of the
product development phase to find
whether specified requirements meet.
VALIDATION:
 The process of evaluating software
during or at the end of the
development process to
determine whether it satisfies the
requirements of the client or not.
 DESIGN PHASE:

• Requirement Analysis: This phase contains

detailed communication with the customer to
understand their requirements and expectations. This
stage is known as Requirement Gathering.
• System Design: This phase contains the
system design and the complete hardware and
communication setup for developing product.
• Architectural Design: System design is
broken down further into modules taking up different
functionalities. The data transfer and communication
between the internal modules and with the outside
world (other systems) is clearly understood.

• Module Design: In this phase the system

breaks down into small modules. The detailed design of
modules is specified, also known as Low-Level Design
(LLD).

ADVANTAGES :
 This is a highly disciplined model and
phases are completed one at a time.
 V-Model is used for small projects
where projects requirements are clear.
 Simple and Easy to understand and
use.
 This model focuses on verification
and validation activities early in the life
cycle thereby enhancing the probability
of building an error-free and good quality
product.
 It enables project management to
track progress accurately.
 DISADVANTAGE:
 It is not that good for complex and
object-oriented projects.
 It is not suitable for projects where
requirements are not clear and contains
high risk of changing.
 This model does not support iteration of
phrase.
 It does not easily handle concurrent
(parallel) events.
ITERATIVE MODEL:
The iterative waterfall model can be thought
of as incorporating the necessary changes to
the classical waterfall model to make it
usable in practical software.
It’s almost the same as the classical waterfall
model except some changes are made to
increase the efficiency of the software
development.
 AGILE MODEL:
The meaning of Agile is SWIFT (quickly) or
VERSATILE (changeable). ”Agile Process
Model” refers to a software development
approach based on iterative (repetitions)
developments.
Agile methods break tasks into smaller
iterations, or parts do not directly involve
long term planning.
Plans regarding the numbers of iterations,
the duration and the scope of each
iterations are clearly defined in advance.
The division of the entire project into
smaller parts helps to minimize the project
risk and to reduce the overall project
delivery time requirements.
Each iterations involves a team working
through a full software development life
cycle including Planning, requirements
analysis, design, coding, and testing
before a working product is demonstrated
to the client.
 What is Iteration?
 In Agile software development, an iteration is
a set amount of time reserved for
development.
 Typical iterations last 1-2 weeks, However,
Some may go as long as 4 weeks.
 Most agile development terms agree on the
length of their iterations and proceed to
operate on an iteration-by-iteration basis.
Types of Agile Development Methodology

Design
Requirement Analysis Document & Prototype

Iteration,Demo
& feedback
Production &
Technical
Support

Iterations,Demo
& Feedback
 DEPLOYMENT

 In this phase, the team issues a product

for the user’s work environment.
 FEEDBACK
 After releasing the product, the last step is
feedback.
 In this, the team receives a feedback
about the product and works through the
feedback.
 AGILE CEREMONIES
 Agile ceremonies are meetings with defined
lengths, frequencies, and Goals.
 Their purpose is to help project team plan,
track, and engage stakeholders with their
work and help them reflect on how well
they’ve worked together.
 They’re typically a part of the Scrum
framework of Agile.
 While each ceremony is different, they
facilitate the same overall purpose.

Sprint review
• The sprint review meeting is an opportunity
for the project team to showcase what
they've achieved during the sprint to key
business stakeholders.
• The Product Owner facilitates the sprint
review and seeks feedback from the business
on progress-to-date and what items need to
be prioritized next.
• Goal: discuss and demo work completed, celebrate and
highlight accomplishments and determine next actions
• Participants: entire Scrum team, Product Owner,
business stakeholders
• Frequency: end of each sprint, typically every 1-4 weeks
• Length: up to an hour per week of the sprint, i.e., 2-hour
meeting for a 2-week sprint

Sprint Retrospective
• A sprint retrospective is an opportunity for the
development team to give feedback on how they felt the
previous sprint went — what worked, what didn't, and
what you should change.
• Start by reviewing your notes from the previous sprint
retrospective.
• Retrospectives are also an opportunity to have an
honest conversation about workloads.
 One of the main reasons sprints fails is that your team
overestimated what they could complete
within the timeframe.
During the Sprint Retrospective, the team discusses
• What went well in the Sprint
• What could be improved
• What will we commit to improve in the next Sprint
• The Scrum Master encourages the rest of the Scrum Team to
improve its process and practices to make it more effective and
enjoyable for the next Sprint.
• Participants: entire project/scrum team
• Frequency: end of each sprint, usually over within 1-4 weeks
* Length: 2-3 hours is about average

Daily Scrum Meetings

 • Daily Scrum ceremony is the most popular Agile ceremony.
• During the stand-up, each team member provides a brief
update on what they've completed over the last 24 hours, what
they plan to tackle next, and any roadblocks getting in the way
of their work.
• A scrum master, they'll take note of these challenges. One of
the Scrum Master's core responsibilities is to remove blockages
for the team and help them move forward with their work.

Product backlog refinement

• A product backlog is the list of tasks and issues that your
team wants to complete in future sprints.
• But because Agile is based on rapid feedback, these issues
can become outdated or change in priority.
• While not an official Agile ceremony, refining your backlog is
an essential part of keeping your team efficient and effective.
• Participants: The product owner. As this isn't necessarily an
'event," it doesn't require your full team.
• Frequency: No Frequency
• Length: 1-3 hours is about average

How to refine your backlog

• There are two moments when you'll want to focus on refining
your backlog.
• Before a sprint starts: Prioritize your backlog of tasks and
issues for the next two sprints. Thinking beyond your
immediate workload can help you effectively prioritize and stay
true to your product strategy.
• During the sprint: The product owner is free to reprioritize
work in the backlog at any time based on customer feedback, a
shift in requirements, or market insights. However, try not to
make changes to work that's already in progress.

Advantage
- Frequent Delivery
• Face-to-Face Communication with clients.
• Efficient design and fulfils the business requirement.
• Anytime changes are acceptable.
• It reduces total development time.

Disadvantages
• Due to the shortage of formal documents, it creates confusion
and crucial decisions taken throughout various phases can be
misinterpreted at any time by different team members.

Spiral Model
 • This Spiral model is a combination of iterative development
process model and sequential linear development model i.e.,
the waterfall model with a very high emphasis on risk analysis,
- It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.
• Spiral model is one of the most important Software
Development Life Cycle models, which provides support for
Risk Handling.
• Using the spiral model, the software is developed in a series
of incremental releases.

When to use Spiral Model?

 • When deliverance is required to be frequent.
* When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.
Disadvantages
* Can be a costly model to use.
* Risk analysis needed highly particular expertise
* Doesn’t work well for smaller projects.

Static Testing
• Static Testing is a software testing technique which is used to
check defects in software application without executing the
code.
* Static testing is done to avoid errors at an early stage of
development as it is easier to identify the errors and solve the
errors.
• It also helps finding errors that may not be found by
Dynamic Testing.
 Why Static Testing?
• Early defect detection and correction
• Reduced development timescales
• Reduced testing cost and time
• For improvement of development productivity
• To get fewer defect at a later stage of testing.

What is Tested in Static Testing

• Unit Test Cases
• Business Requirements Document (BRD)
• Use Cases
• System/Functional Requirements
• Test Data
• User Manual/Training
Guides/Documentation
• Test Plan Strategy Document/Test Cases

What is Tested in Static Testing

• Unit Test Cases
• Business Requirements Document (BRD)
• Use Cases
• System/Functional Requirements
• Tost Data
• User Manual/Training
Guides/Documentation
• Test Plan Strategy Document/Test Cases

How Static Testing is Performed

• Use Cases Requirements Validation: It validates that all the
end-user actions are identified, as well as any input and output
associated with them. The more detailed and thorough the use
cases are, the more accurate and comprehensive the test
cases can be.
• Functional Requirements Validation: It ensures that the
Functional Requirements identify all necessary elements. It also
looks at the database functionality, interface listings, and
hardware, software, and network requirements.
• Architecture Review: All business level process like server
locations, network diagrams, protocol definitions, load
balancing, database accessibility, test equipment, etc.
• Prototype/Screen Mockup Validation: This stage includes
validation of requirements and use cases.
• Field Dictionary Validation: Every field in the UI is defined
well enough to create field level validation test cases. Fields are
check for min/max length, list values, error messages, etc.
 Informal Reviews
• Informal reviews are applied in the early stages of the life
cycle of the document.
• These reviews are conducted between two-person team. In
later stages more people are involved.
• The aim of informal reviews is to improve the quality of the
document and help the authors.
• These reviews are not based on the procedure
and not documented

Formal reviews
• Formal reviews follow the formal process i.e, these reviews
are well structure and managed.
I. Planning
II. Kick-Off
III. Preparation
IV. Review meeting
V. Rework
VI. Follow-up
i) Planning
• Review process starts with planning phase.
• In planning, the review process starts with a request for
review by the authors to the inspection leader.
• Entry criteria verifies the document is ready to enter the
formal review process.
ii) Kick-off
• The aim of kick-off step is to explain the objectives of review
and distribute the documents in meeting etc.
iii) Preparation
• In preparation, reviewers review the document separately
using related rules, procedures, documents.
End y nestanding of izes the defects, questions and comments
as per their role
iv) Review meeting
Review meeting includes three phases:
1. Logging Phase - Defects and issues are identified in the
preparation step that are logged page by page.
2. Discussion Phase - This phase handles the issues that
require discussion.
3. Decision Phase - Decision on the document reviews is
constructed by reviewers or participants.
v) Rework
• If the number of defects found per page is more than certain
level, then they document needs to be reworked.
vi) Follow-up
• In follow up, moderator ensures that author has taken an
action on all known defects.

Walkthrough
• In walkthrough, author guides the review team via the
document to fulfil the common understanding and collecting
the feedback.
• Walkthrough is not a formal process.
• Walkthrough is useful for higher-level documents. i.e,
requirement specification and architectural documents.
Goals of walkthrough
• Make the document available for the stakeholders both
outside and inside the software discipline for collecting the
information about the topic under documentation.
Inspection
• The trained moderator guides the Inspection. It is most formal
type of review.
• The reviewers are prepared and check the documents before
the meeting.
• In Inspection, a separate preparation is achieved when the
product is examined, and defects are found.
Goals of Inspection
• Efficiently and rapidly remove the defects.
• Generating the documents with higher level of quality and it
helps to improve the product quality.

Technical Review
• Technical review is a discussion meeting that focuses on
technical content of the document. It is a less formal review.
• It is guided by a trained moderator or a technical expert.
Goals of technical review
• In early stages it ensures that the technical concepts are used
correctly.
• Notify the participants regarding the technical content
of the document.
Tools used for Static Testing
• Checkstyle
• Soot
• SourceMeter
• Jira

Dynamic Testing
• Dynamic Testing is a software testing method used to test the
dynamic behaviour of software code.
• The main purpose of dynamic testing is to test software
behaviour with dynamic variables or variables which are not
constant and finding weak areas in software runtime
environment.
• The code must be executed in order to test the dynamic
behaviour.
• We all know that Testing is verification and validation, and it
takes 2 Vs to make testing complete.
• Out of the 2 Vs, Verification is called a Static testing and the
other "V", Validation is known as Dynamic testing.
 White Box Testing
• White Box Testing is a software testing method in which the
internal structure/ design is known to the tester.
• The main aim of White Box testing is to check on how System
is performing based on the code.
• It is mainly performed by the Developers or White Box
Testers who has knowledge on the programming.

Black Box Testing

• Black Box Testing is a method of testing in which the internal
structure/ code /design is NOT known to the tester.
- The main aim of this testing to verify the functionality of the
system under test and this type of testing requires to execute
the complete test suite and is mainly performed by the Testers,
and there is no need of any programming knowledge.

Grey Box Testing

• Grey box testing is a software testing technique to test a
software product or application with partial knowledge of
internal structure of the application.
• The purpose of grey box testing is to search and identify the
defects due to improper code structure or improper use of
applications.
• In this process, context-specific errors that are related to web
systems are commonly identified.
• It increases the testing coverage by concentrating on all the
layers of any complex system
• Gray Box Testing is a software testing method, which is a
combination of both White Box Testing and Black
Box Testing method.
In White Box testing internal structure (code) is known
• In Black Box testing internal structure (code) is unknown
• In Grey Box Testing internal structure (code) is partially
known.

Why Gray Box Testing is important

• It provides combined benefits of both black box testing and
white box testing both
• It combines the input of developers as well as testers and
improves overall product quality
• It reduces the overhead of long process of testing functional
and non-functional types
• It gives enough free time for a developer to fix defects
• Testing is done from the user point of view rather than a
designer point of view

Functional Testing
• Functional testing is performed to verify that all the features
developed are according to the functional specifications.
• It is performed by executing the functional test cases written
by the QA team.
• In functional testing phase, system is tested by providing
input, verifying the output and comparing the actual results
with the expected results.
• There are different Levels of Functional Testing out of which
the most important
are
• Unit Testing - Generally Unit is a small piece of code which
is testable, Unit Testing is performed at individual unit of
software and is performed by developers.

• Integration Testing - Integration Testing is the testing

which is performed after Unit Testing and is performed by
combining all the individual units which are testable and is
performed either by developers or testers
• System Testing - System Testing is performed to ensure
whether the system performs as per the requirements and is
generally performed when the complete system is ready, it is
performed by testers when the Build or code is released to QA
team
• Acceptance Testing - Acceptance testing is performed to
verify whether the system has met the business requirements
and is ready to use or ready for deployment and is generally
performed by the end users.
 Non- Functional Testing
Non- Functional Testing: Non-Functional testing is a testing
technique which does not focus on functional aspects and
mainly concentrates on the nonfunctional attributes of the
system such as memory leaks, performance or robustness of
the system. Non-Functional testing is performed at all test
levels.
Performance Testing - Performance Testing is performed to
check whether the response time of the system is normal as
per the requirements under the desired network load.
Recovery Testing - Recovery testing is a method to verify on
how well a system can recover from crashes and
hardware failures.
Compatibility Testing - Compatibility testing is performed to
verify how the system behaves across different environments.
• Security testing - Security testing is performed to verify the
robustness of the application, 1.0., to ensure that only the
authorizes users/roles are accessing the system
• Usability testing - Usability testing is a method to verify the
usability of the system by the end users to verify on how
comfortable the users are with the system.
 Smoke Testing
• Smoke and Sanity testing difference is the most
misunderstood topic in Software Testing.
• There is an enormous amount of literature on the subject, but
most of them are confusing.
• Smoke Testing is a software testing technique performed post
software build to verify that the critical functionalities of
software are working fine.
• It is executed before any detailed functional or regression
tests are executed.
• The main purpose of smoke testing is to reject a software
application with defects so that QA team does not waste time
testing broken software application.

What is Sanity Testing?

• Sanity testing is a kind of Software Testing performed after
receiving a software build, with minor changes in code, or
functionality, to ascertain that the bugs have been fixed and no
further issues are introduced due to these changes.
• The goal is to determine that the proposed functionality
works roughly as expected.
• If sanity test fails, the build is rejected to save the time and
costs involved in a more rigorous (Extremely thorough and
careful) testing.
• The objective is "not" to verify thoroughly the new
functionality but to determine that the developer has applied
some rationality (sanity) while producing the software.

Important Points
• Both Sanity and Smoke testing are ways to avoid wasting
time and effort by quickly determining whether an application
is too flawed to merit any rigorous testing.
• Smoke Testing is also called tester acceptance testing and QA
team.
• Smoke testing performed on a particular build is also known
as a build verification test.
• One of the best industry practice is to conduct a Daily build
and smoke test in software projects (CI/CD pipeline).
 Regression Testing
• Regression testing is responsible for the overall stability and
functionality of the existing features.
• Whenever a new modification is added to the code,
regression testing is applied to guarantee that after each
update, the system stays sustainable under
continuous improvements.
•It is performed by the Quality Assurance Team (QA)
 Ad hoc Testing
• Ad hoc Testing is an informal or unstructured software testing
type that aims to break the testing process in order to find
possible defects or errors at an early possible stage.
• Ad hoc testing is done randomly, and it is usually an
unplanned activity which does not follow any documentation
and test design techniques to create test cases.
• Ad hoc Testing does not follow any structured way of testing
and it is randomly done on any part of application.
• Main aim of this testing is to find defects by random checking.
• Ad hoc testing can be achieved with the Software testing
technique called Error Guessing.

When execute Ad-hoc Testing?

• Usually, ad hoc testing is performed after the formal test
execution.
• And if time permits, ad hoe testing can be done on the
system.
• Ad hoc testing will be effective only if the tester is
knowledgeable of the System Under Test.
Types of Ad hoc testing
• Buddy Testing
• Pair Testing

Buddy Testing
• Two buddies mutually work on identifying defects in the same
module.
• Mostly one buddy will be from development team and
another person will be from testing team.
• Buddy testing helps the testers develop better test cases and
development team can also make design changes early.
• This testing usually happens after Unit Testing completion.

Pair testing
• Two testers are assigned modules, share ideas and work on
the same machines to find defects.
• One person can execute the tests and another person can
take notes on the findings. Roles of the persons can be a tester
and scriber during testing.
Comparison Buddy and Pair Testing
• Buddy testing is combination of unit and System Testing
together with developers and testers, but Pair testing is done
only with the testers with different knowledge levels.
(Experienced and non-experienced to share their
ideas and views)

Installation Testing
• Installation Testing: It is performed to verify if the software
has been installed with all the necessary components and the
application is working as expected.
• This is very important as installation would be the first user
interaction with the end users.
• Companies launch Beta Version just to ensure smoother
transition to the actual product.
Installation Types:
i. Silent Installation
ii. Network Installation
iii. Clean Installation
 Localization Testing
• Just imagine, your native language is Hindi, and you are
more comfortable with it than English.
• And you are opening the Amazon application for buying a
brand-new mobile.
• There you select Hindi as your preferred language since
you are comfortable with it the most.
• Then the content and user interface will be adapted to the
language "Hindi".
 Globalization Testing
• Globalization Testing is a type of software testing that is
performed to ensure the system or software application can
function independent of the geographical and cultural
environment.
• It ensures that the application can be used all over the
world and accepts all the language texts.
• Sensitivity to the language vocabulary: A product that is
used all over the world needs to Support many languages.
Different language translators are used to verify if the
application uses proper vocabulary for each language
• Date and time formatting : Date and time formats vary
from one place to another.
• Currency Format: Currency formats vary from one country
to another. So, application should support all kind of the
formats. Application should also display the correct symbol
of currency and the units.
• Phone and mobile number formatting: Every country has
different phone and mobile number formats. Also, the ISD
varies from one country to another country.
So, the application should take care of it.
• Address Formatting: Address formats also vary from one
country to another. In
• Zip Code Format: The zip code format also changes from
one country to another.

Compatibility Testing (Forward & Backward Testing)

What is Compatibility?
• Compatibility is nothing but the capability of existing or
living together:
• In normal life, Oil is not compatible with water, but milk can
be easily combined with water.
What is Compatibility Testing?
• Compatibility Testing is a type of Software testing to check
whether your software can run on different hardware,
operating systems, applications, network environments
or Mobile devices.
• Hardware : It checks software to be compatible with
different hardware configurations.
• Operating Systems : It checks your software to be
compatible with different Operating Systems like Windows,
Unix, Mac OS etc.
• Software : It checks your developed software to be
compatible with other software. For example, MS Word
application should be compatible with other software like MS
Outlook, MS Excel, VBA etc.
• Network : Evaluation of performance of a system in a
network with varying parameters such as Bandwidth,
Operating speed, Capacity. It also checks application in
different networks with all parameters mentioned earlier.

• Browser: It checks the compatibility of your website with

different browsers like
Firefox, Google Chrome, Internet Explorer etc.
• Devices: It checks compatibility of your software with
different devices like USB port Devices, Printers and
Scanners, Other media devices and Blue tooth.
• Mobile: Checking your software is compatible with mobile
platforms like
Android, iOS etc.
• Versions of the software: It is verifying your software
application to be compatible with different versions of the
software. For instance, checking your Microsoft Word to be
compatible with Windows 7, Windows 7 SPI, Windows 7
SP2, Windows 7 SP3.

1 User Acceptance Testing

User Acceptance Testing (UAT)

• User Acceptance Testing (UAT) is a type of testing
performed by the end user or the client to verify/accept the
software system before moving the software application to
the production environment.
• UAT is done in the final phase of testing after functional,
integration and system testing is done.
Purpose of UAT
• The main purpose of UAT is to validate end to end business
flow.
• It does not focus on cosmetic errors, spelling mistakes or
system testing.
• User Acceptance Testing is carried out in a separate testing
environment with production-like data setup.
• It is kind of black box testing where two or more end-users
will be involved.
UAT Roles :
DEVELOPMENT : DEVELOPER
INTERGATION : TESTER
UAT : END 2 END TEAM
PERFORMANCE : PERFORMANCE
TEAM
PRODUCTION : -------------
 Alpha Testing
• Alpha Testing is a type of software testing performed to
identify bugs before releasing the software product to the
real users or public.
• The main objective of alpha testing is to refine the software
product by finding and fixing the bugs that were not
discovered through previous tests.
- To put it as simple as possible, this kind of testing is called
alpha only because it is done early on, near the end of the
development of the software, and before beta testing.
• The focus of alpha testing is to simulate real users by using
a black box and white box techniques.

Advantages of Alpha Testing

• Provides better view about the reliability of the software at
an early stage
• Helps simulate real time user behaviour and environment.
• Detect many showstopper or serious errors
• Ability to provide early detection of errors with respect to
design and functionality
Disadvantages of Alpha Testing
• In depth, functionality cannot be tested as software is still
under development stage Sometimes developers and testers
are dissatisfied with the results of alpha testing.
 Beta Testing
• Beta Testing is performed by "real users" of the software
application in "real environment and it can be considered as
a form of external User Acceptance
Testing.
• It is the final test before shipping a product to the
customers. Direct feedback from customers is a major
advantage of Beta Testing.
• This testing helps to test products in customer's
environment.
• Beta version of the software is released to a limited
number of end-users of the product to obtain feedback on
the product quality.
• Beta testing reduces product failure risks and provides
increased quality of the product through customer validation.
Advantages of Beta Testing
• Reduces product failure risk via customer validation.
• Beta Testing allows a company to test post-launch
infrastructure.
• Improves product quality via customer feedback
• Cost effective compared to similar data gathering methods
• Creates goodwill with customers and increases customer
satisfaction
Disadvantages of Beta Testing
• Test Management is an issue. As compared to other testing
types which are usually executed inside a company in a
controlled environment, beta testing is executed out in the
real world where you seldom have control.
 Key Differ
• Alpha Testing is performed at Tester site whereas Beta
Testing is performed at
Client's location.
• Reliability and Security testing are not performed in-depth
in Alpha Testing while
Reliability, Security and Robustness are checked during Beta
Testing.
• Alpha Testing involves both Whitebox and Blackbox testing
whereas Beta Testing mainly involves Blackbox testing.
• Alpha Testing requires testing environment while Beta
Testing doesn't require testing environment.
• Critical issues and bugs are addressed and fixed
immediately in Alpha Testing whereas issues and bugs are
collected from the end users and further
implemented in Beta Testing