Manual

Manual testing
IT company projects – Dev team And Test team

1- Project technology – application – java – dev team – java

language) testing team
2- Project technology – Application - .net – dev team - .net
language) testing team

Types of testing
Manual testing – Manual 1 and manual 2

Web service testing/ API testing

Data base testing

Automation testing

2 live projects

Project – Manual tester, Automation tester, Database tester, Api

tester

Manual testing
Manual 1

Process ( SDLC/Fish model, Waterfall model, V model, Agile

model)

Testing types – ( Sanity, smoke, functional, regression , retesting

etc.....)

Manual 2

Real testing Part

Project in IT company – Peoples involved

Client – Project ( requirement /Application / S/w implementation )
Business Analyst (BA) – Collects the requirement from Client

Delivery Manager (DM) – Requirement of client are provided on

time or not.

Project Manager (PM) – Works with BA and project team

Solution Designer / Architect – Application Design or Architecture

Project

Dev team – Development team – Developer – Coding

Testing Team – Application Testing

Interview Question
What was your team size?

Team size- 18 people

Peoples involves in project team

BA- 1

PM- 1

Solution designer/Architect – 1

Developer – 11

Tester – 4 (including TL)

Ratio of Dev and Tester

1- Normal project - VI App , Retail Project – Amazon , Flipkart

Ratio – 2:1 – dev – 2 tester- 1

2- Banking Domain/ Investment / Payment transaction

Ratio – 3:1 – dev – 3 tester – 1

Paytm Project

Module 1 Module 2 Module 3 Module 4

Recharge Ticket Booking Insurance Electricity Bill

3:1 2:1 3:1 3:1

Manual Testing – Manual testing is the process of manually
testing the software defects.

Software testing – Process of checking completeness and

correctness of developed software.

SQA – Software Quality Assurance

It is process in which client monitors and measures the strength
of a developed application.

Communication between customer and business analyst is called

as SQA.

BA
Requirement

Tester Client
Developer

Factors

1- Requirement of client are fulfilled or not

2- Client expectations ( Performance and security )
3- Time to deliver
4- Cost of the project
5- Maintenance

Process – Type
1- SDLC (Software development life Cycle ) / Fish Model
 2- Waterfall Model
3- V-Model
4- Agile Model

SDLC – Software development Life Cycle

It is a process used by the software industry to design, develop
and test high quality software. The SDLC aims to produce high
quality software that meets clients expectations, reaches
completion within time and cost estimates.

Different Types of phases / stages are there in SDLC

1- Information Gathering/ Requirement Gathering

2- Analysis
3- Design
4- Coding/Development
5- Testing
6- Maintenance / Support

Client (Application)

Information Gathering/Requirement Gathering (BA) –

BRS(Business requirement Specification)

Analysis – BA – SRS – (Software/System Requirement

Specification)

FRS – Functional Requirement Specification

CRS - (Customer Requirement Specification)

Design/Architecture – Design – (HLD/LLD)

 Coding- Developer – Application Implements

Testing – Tester – Test the application

Maintenance/Support

BRS- Business requirement Specifications

1- This document generally consist of complete scope of the

project, the performance , requirement and usability,
2- BRS is bridge between customer/client and BA,

SRS – Software Requirement Specification

1- A software requirement Specification is a description of a

software to be developed.
2- In SRS document all functional and non functional
requirement are covered.
3- A functional requirement defines a system or its
components. A non functional requirement defines the
quality attribute of a software system.
4- SRS is derived from BRS.

SRS document Includes

1- Functional Flow diagram
Eg. Sign up – login page – Home page – Profile page

2- Functional Requirement
Eg. Sign up page – (Requirement – First name, Last name ,
Mobile number, Email id, DOB , Password , Submit button.

3- Use cases –
Use cases Consists of description and Acceptance Criteria.
 Eg. Mobile Number
Description – To complete the signup mobile number field is
mandatory. Without Mobile number user cannot signup
through the application.
Acceptance – It should accept 10 digit mobile number. If we
enter less than 10 digit or more than 10 digit mobile
number. Error message should be displayed that “Please
enter valid contact number”

4- Screenshot/Snapshot
1- Snapshot are visualization of functionalities before
development of software.
2- Snapshot is made by BA using HTML code and Irise
software.

Design – Solution designer/Architecture

2 – Types

1- HLD (High level design) – External functionality of the

application – Solution Designer
2- LLD (Low level design) – Internal functionality of the
application – Front End developer

Coding – Developer- Development

1- Coding means program

2- One line is code
3- Multiple line code is called program
4- Set of program written by developer creates software.

2 – Types of developer

1- Front end developer

UI functionalities, Functional flow etc , developed by front
end developer
 2- Backend developer
Data management, Data Security , Data gathering

Who can work as front end developer and back end developer is
called as full stack developer.

Testing – Testers

Testers are Working on

1- TCD – Test Case design – to write test cases

2- TCE – Test Case Execution

Maintenance / Support

We provide some warranty - 1 month free

After 1 month client will pay for support

What is the difference between BRS and SRS?

BRS SRS
Business Requirement Software requirement
Specification Specification
This document generally consist A software requirement
of complete scope of the Specification is a description of
project, the performance , a software to be developed.
requirement and usability.
BA people Prepares BRS BA people prepares SRS
From Client BA collects the SRS is Derived from BRS
requirement and prepares BRS
document.
All requirements are covered in In SRS all functional and Non-
BRS functional requirements are
covered
Use cases are not Present Use cases are Present.

Interview Questions
1- What is your Team Size?
2- What is SDLC?
 3- What is BRS and SRS?
4- What is SRS and what all it contains?
5- What is use cases?

Basic SDLC Module/Fish Module

Analysis Design Coding BBT

REQ (SRS) HLD/LLD WBT Testing Support

Gathering TCD/TCE

Review Review Review

Verification Validation

Static Testing Dynamic testing

Quality Assurance Quality Control

1- Fish module is advance version of SDLC

2- Fish module consists of verification and validation.

What is the difference Between WBT and BBT?

WBT (White Box Testing) BBT (Black Box Testing)
Developers perform WBT Tester performs BBT
Types of WBT – unit testing and Types of BBT – Sanity testing,
integration testing Smoke testing, Regression
testing, Functional testing etc
Developers are checking their Testers are checking the
code of developed application functionality of application as
as per the requirement per the requirement.
It is mandatory to have No knowledge of programming
knowledge of programming is required
Called as code level testing Called as system, and functional
testing
+ve scenario testing +ve and –ve scenario testing
Difference Between Verification and Validation?
Verification Validation
In this testing BA people will In these testing tester will check
review their BRS,SRS, Designer the functionality of the
will review their design, application.
Developer will check their code
Involved BA, Designer, Involved Tester
Developer
Verification is the process of Validation is the process of
checking that the software checking whether the
meets its specifications specification captures the
customer requirement.
It is also called as static testing It is also called as Dynamic
and Quality assurance testing and Quality control
+ve Scenario +ve and –ve scenario test
It includes checking of It includes testing and
documents, Design, codes and validation of actual product
program

Grey Box testing

1- Grey box testing is the combination of White box and black
box testing.
2- Tester is involved in this testing.
3- To do grey box testing tester needs programming
knowledge.
4- The role of grey box tester is, whenever final s/w is handed
over to tester , tester checks the functionality and if any
fault occurs in the o/p then tester does not revert system
back too developer, instead of that tester himself solve or
make changes in code , So knowledge of coding is required.

Advantages of fish model

1- It is easy to implement.
 2- Every stage of this model is tested by a separate team for
completeness and correctness of application, so it provides a
high quality software.
3- It provides full documentation of the application.

Disadvantages of Fish Model

1- In this model, review and testing starts from the project

initiation to the maintenance phase , due to this reason fish
model is a costly methodology.
2- It is a time –consuming process to develop a product.
3- It is an expensive model so the development failure will
cause lot of damage and loss.

Questions
1- Difference between WBT and BBT?
2- Difference between static testing and Dynamic testing?
3- Difference between Verification and validation?
4- What is Fish Model and its advantages and disadvantages?

Waterfall Model
Information
Gathering
Analysis
(SRS)
Design
HLD/LLD
Coding
Testing
TCD/TCE
Maintenance
/support

1- It is a process to develop a software

2- Waterfall model is called as sequential Model
 3- In waterfall model we can move to next phase when
previous phase is completed.
4- As phases fall from Higher level to lower level like a waterfall
so it is named a waterfall model.
5- Duration of waterfall model is of 3 months.

Advantages
1- Simple and Easy to understand and use.
2- For smaller projects, waterfall model works well.
3- Phases are processed and completed one at a time.

Disadvantages
1- Cannot accept the new CR in between
2- For bigger and complex project this model is not good.
3- If we are getting any changes in between we cannot go to
the back stage.
Note – Completion of Development phase is the entry criterion
for testing phase and Completion of Testing phase is the exit
criterion for testing phase.

V-Model

Verification Validation
(Development) (Testing)

Information gathering Assessment of dev phase

And analysis Test plan preparation

Design and Coding Design phase test

Program phase test
Test case design

Integration Smoke and sanity testing

Build installation System and functional testing
 UAT testing
Documentation

Maintenance and DRE(Defect removal efficiency)

Support RFC, CR
Postmortem testing

1- V-stands for verification and Validation

2- In V-model verification and validation are running parallel
3- In V-model development stages are mapped with the testing
stages
4- Duration of v-model is of 3 months
5- V-model is used in big organization.
Assessment of dev phase
1- Assessment of dev phase means to make the strategy for
testing.
2- In this phase we decide which methodology is going to be
used for testing manual or automation.

Test Plan Preparation

1- In test plan preparation PM prepares the test team and TL
prepares test plan.
2- In this phase test estimation is created.
3- Test estimation means who will work on which module and
how much time it will take to complete it.

Design/Program phase test

1- In Design phase test HLD and LLD is checked or tested by
the design team.
2- In Program phase test code is tested.
3- This code testing starts from small unit of program.
 4- In this testing developer is involved as he knows the code
and we can call it is WBT.

Test Case design

1- In this phase tester is writing the test cases by considering
+ve and –ve scenarios by refereeing the SRS document.
2- Tester are involved in this phase.
3- This is called as BBT.

DRE – Defect removal Efficiency

How deeply we have tested the application or Build.
DRE = A/A+B
A= defect found by tester
B= Defect found by client side – in UAT

A=8 B=2
DRE= 0.8 good tester
A=8 B=4
DRE = 0.5 to 0.8 avg tester
A=8 B=7
DRE = less than 0.5 below avg tester

Postmortem testing
1- Done by white box tester
2- When whole testing is done and product is ready for release
and if product is not producing the desired output the white
box tester performs the postmortem testing where he check
all the modules in detail.

Advantages of V-model
1- Testing activities like planning , test designing happens well
before the coding.
2- Time saving, Quick.
3- Avoids the downward flow of the defect.
Disadvantages of V-model
1- If there is any change request in between then the test
document along with the new requirement needs to be
updated which is time consuming.
2- The management of the v-model is risky and Unstable.
3- The V-model is very hard to execute as compared to other
models.`

Agile model/Methodology/Process
1- The agile scrum methodology is combination of both
incremental and iterative modal for managing product
development.
(incremental – which keeps on increasing , iterative –
repetition- till project is completed.)
2- Duration of agile is of 1 week, 2 week, 3 week, 4 week.
(In your organization duration of Agile is of 2 week . that
duration of 2 weeks is called as Sprint)
3- Agile is continuous process for development and testing.
4- If CR comes then we will check its impact on development,
testing and production or its priority in the application.
5- Agile is a value driven process.

Agile framework /Sub module

1- XP – Extreme programming – Continuous development
2- Scrum – To give sprint wise delivery to client where
complete team works together to develop a software.
3- FDD – Future driven development
4- Kanban
5- Lean

On Which methodology you have worked?

I have worked on Scrum Agile methodology.
Agile Architecture

Information Gathering Product backlog[200 req]

(BRS)

Analysis Sprint Backlog[20req- 1 sprint]

(SRS) [20req- 2 sprint]
[20 req- 3 sprint]

Use cases User story – 1 requiremnt

Description criteria Description
Acceptance criteria Acceptance

Design Design

Coding(WBT) Coding(WBT)

Testing(TCD,TCE) Testing(TCD,TCE)

Maintenance/Support Maintenance / Support

Peoples involved in Agile with their name

1- Client - Stakeholder
2- BA – Product owner
3- DM – Solution master
4- PM – Scrum master
5- Designer - Designer
6- Developer - Developer
7- Tester – Tester

Sprint
A sprint is a set period of time during which specific work has to
be completed and made ready for review.
Stakeholder
1- Client or customer is called as Stakeholder in Agile
2- He is the member of top most body of the company.
3- At any phase of dev, testing or production they can request
for change.

Product owner
1- Product owner collects the requirement from stakeholder
2- He is the member of Sprint planning meeting

Product backlog
1- Product backlog contains the complete requirement of a
whole project.
2- It includes requirement of all the modules.

Sprint backlog
1- Created by Product owner
2- Sprint backlog contains user story.

Agile Meetings/ Ceremonies

Meetings Purpose Involvement of

people
Grooming Meeting If there any doubts 30min/1 hr product
(Before start of the about the owner (Chair
sprint) requirement that are person), dev team,
been cleared here in testing team, design
Grooming meeting. team, Scrum master
(optional)
Sprint Planning 1- Decide the user 1hr – Scrum
Meeting (1st day of story(1 sprint – master(chair person)
Sprint) 20 req) , dev team , testing
2- Estimation team, design team,
(time slot to Product owner
complete the
 user story)
(1 user story –
16hrs)
Daily stand up 1- What you have 15min to 30min –
meeting done Scrum master(Chair
(Scrum meeting) yesterday? person) , dev team,
2- What you are testing team, Design
going to do team, product
today? owner(Optional)
3- What are the
roadblocks or
issues you have
faced?
Sprint review Demo/Review of the 1hr –
Meeting (End day of user stories Stakeholder/Product
Sprint) completed in current owner (Chair
sprint. person). Dev team ,
testing team, design
team, Scrum
master(Optional)
Sprint retrospective In this meeting Good 30min – Scrum
Meeting(End day of and Bad things are master(chair
sprint or 1st day of discussed about the person), dev team ,
next sprint) current sprint. testing team, Design
team, Product
owner(optional)

Zero Sprint
It generally refers to the first step or pre-preparation stem that
comes before the 1st sprint. It includes all activities such as
development environment, preparing backlog, project skeleton,
etc.

Advantages
1- Sprint wise delivery
2- Working software is delivered frequently.
 3- Customers , developers and testers constantly interact with
each other.
4- Change request are accepted frequently.

Disadvantages
1- If requirement is not cleared before the sprint the sprint can
go out of scope.
2- Less Documentation
3- Cost of Agile Development methodology is slightly more as
compared to other development methodology.

Agile terms
1- Burn Down Chart – How much user story remaining w.r.t
time.

2- Burn Up Chart – How much user stories Completed w.r.t to

time.
3- Epic – It is US in a Sprint.

4- Velocity – Progress against the estimated work(time)

Environments in Project
How many environments are there in your project?

Environment
Dev SIT Environment UAT Environment Prod Environment
Environment Testers Dev and Testers
Developers Live

Pune Company USA Client

Remote Desktop(Access UAT)

Types of testing in different Environment

1- Dev Environment (WBT)
a- Unit testing
b- Integration Testing

2- SIT Environment
Initial Build
Sanity / Smoke testing

For stable Build

a- Functional Testing
b- Regression Testing
 c- Retesting
d- Etc

Regression Testing UAT

SIT

3- UAT Environment

a- Alpha Testing
b- Beta Testing

UAT Regression Testing Prod

4- Production Environment

Dev Environment
Unit testing

1- Testing which will be performed on individual module is

called as unit testing.
2- Developer will perform unit testing.
3- Test application is checked in +ve scenario/way.

Integration Testing

1- The testing performed on main module by combining various

modules is called as integration testing.
2- Integration testing is performed by developer.

There are 3 ways of integration testing.

1- Top down approach
 2- Bottom up approach
3- Sandwich/Bidirectional Approach

Top down approach

1- In top down approach testing is done by integrating or

joining two or more modules by moving from top to bottom.
2- In these high level modules are tested first and then the low
level modules are tested.
3- In this type of testing , stubs are used as a temporary
module if a sub module is not ready for integration testing.
4- In this case we are using dummy module
5- Dummy module is created from STUB.
6- STUB is a dummy program created by developer.

Bottom up Approach

1- If we have sub module but we are not having the main

module in that case we use bottom up approach.
2- To check sub module, developer creates dummy main
module.
3- Developer first creates the program called ’driver’.
4- These driver programs are in XML language.

Bidirectional Approach.

1- When developer want to check the functionality of main

module but don’t have the sub module then developer uses
STUB program.
2- When developer want to check the functionality of sub-
module but don’t have the main module , then developer
uses driver program.
3- Combination of top down and bottom up approach is called
as bidirectional approach.
SIT Environment (System Integration Testing)

Smoke testing
1- It is a software testing process that determines whether the
developed software build is stable or not.
2- When developer sends a new build/initial build to the tester
then smoke testing is performed.
3- It is also called as zero level testing or Build acceptance
testing.
4- In smoke testing we are checking either the build is stable or
not.
Smoke testing Checkpoints/Validation
1- Validating the core functionality.
2- Validating the GUI/UI functionality
3- Validating the links present in the build.
4- Validating the tabs.
5- Validating the pages.

In this testing we are going to verify all the basic functionalities

are working or not based on this we will accept or reject the build.
Accordingly our test lead will send a mail to development lead
saying that we are accepting the build for further major testing.
If build is not meeting the acceptance criteria test lead will mail to
development lead that we are rejecting the build and he will be
specifying what all are the features not working.

Sanity Testing
1- Sanity testing is a subset of regression testing.
2- After receiving the build from developer sanity testing is
performed to ensure that the code changes are working as
expected.
3- If it is working as expected then we will be performing the
further major functional testing.
 4- If the defects are found during the sanity testing then the
build is rejected that is helpful in saving time for execution of
regression testing.

Difference Between Smoke and Sanity testing?

Smoke testing Sanity Testing
It is a broad approach to testing It is a narrow approach to
where all parts of the testing where specific parts of
application are tested. the application are tested.
Smoke testing is the first Sanity testing is performed
testing performed on the initial when the build is comparatively
build. stable.
It is used to test the end to end It is used to test only modified
function of the application. or defect fixed functions.
Smoke testing is performed by Sanity testing is performed by
developer and tester. tester.
In this we are going to check It is a subset of regression
whether the build is ready for testing in this we are going to
testing or not. focus on particular part of the
application.

Retesting
When we find any defect then that defect will be raised to
developer, developer will fix that defect after fixing that defect
tester will retest it that is called as retesting.

Regression Testing
1- When we are moving from one environment to another
environment regression testing is been performed.
2- After fixing the defect we will be checking that any another
functionality of the application is impacted or not that we are
going to check that is nothing but regression testing.
3- Also we are going to perform the regression testing
whenever any CR comes from the customer.
System and Functional Testing
1- It is nothing but BBT.
2- In this testing we are going to check the whole functionality
of the application.

System and Functional testing includes

1- Usability testing
2- Functional Testing
3- Security Testing
4- Performance testing

Usability Testing
1- Testing the user friendliness of the application is called as
usability testing.

Factors that decide the user friendliness of an

application
1- It should be easily accessible.
2- It should be easy to understand
3- Application should be in easy language.
4- Proper help text message should be displayed.
5- If user is doing any mistake or entering the wrong
credentials it should show error message.
6- Appearance of the application.
7- Navigation of the application should be very simple.

Functional Testing
1- Functional testing
2- Non-functional testing

Functional Testing
Functional testing depends on validating/checking the internal
functionality of the application/module/sub-module as per the
requirement.

It includes Six types of coverage/Testing

1- Behavioral Coverage/Testing
2- Input Domain Coverage/Testing
3- Error Handling Coverage/Testing
4- Backend Coverage/Testing
5- Service Level Coverage/testing
6- Calculation Based Coverage/testing

Behavioral Coverage/Testing
In this we are validating or checking the behavior of the
application.
Validate objects and Behavior of Object
Objects Behavior of Object
Text Box Focus or Unfocus
Radio Button On/OFF
List box/Drop down Enabled or Disabled
Checkbox Clickable or Non clickable

Input Domain Testing/Coverage

Validating or checking the data types and size/length of data

which we are passing into the object(Web elements)
Eg . 10 digit contact number – size – 10 datatype – number

In this we have two types

1- BVA – Boundary Value Analysis
2- ECP – Equivalence Class Partitioning

BVA – Boundary Value Analysis

 1- In BVA we are checking size/length if data passing into the
object.
2- In BVA we are going to check how our system is functioning
or working when we insert a boundary value.
3- Formula for BVA – Min, Max, Min-1, Min+1, Max-1, Max+1

Eg. Password text box should accept 4 to 8 char

Object Passing Criteria Fail Criteria

Text box 4 char Number Pass
Text box 8 char Number Pass
Text box 3 char Number Fail
Text box 5 char Number Pass
Text box 7 char Number pass
Text box 9 char Number Fail

ECP – Equivalence Class Partitioning

In ECP we are going to define the data type which we are passing
into the object.
Data in Object Passing criteria Fail Criteria
Mobile number (Text Int(0-9) A-Z , a-z , Special
box Field) char
4-8 char password A-Z, a-z Int 0-9 , special char
textbox

What is Decision Table?

A decision table is a tabular representation of several input
values, cases , rules and test conditions. Through this table we
can check and verify all possible combinations of testing.

Eg. We will create the decision table for a login screen that asks
for User id and Password. The condition here is that user will be
redirected to the homepage if he enters the correct username
and password, and error message will be displayed if the input is
wrong.
Terms
C- Correct username and password
W- Wrong username and password
E- Error message is displayed.
H- Home screen is displayed.

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Username C/W W C W C
Password C/W W W C C
Output E/H E E E H

Error Handling testing/Coverage

In this testing we will be validating/Checking the filed by passing
the invalid Test data into the application and it should show error
or warning message.

Eg. Payment Tab – Debit card

Debit card no.

Validity

CVV

Holder name

Submit

1- By passing invalid card number – error message – Please

provide the valid debit card number.
2- By passing blank values in Debit card – This field should not
be blank, Please provide debit card number, This field is
mandatory.
Backend Coverage/Testing
In this we will be validating/Checking whatever operations are
been performed on front end same are stored in
backend/database or not.
Eg. SIP ,EMI

Service level testing/Coverage

In this we are going to check the sequence and function of
module on the basis of functional flow diagram. We check working
of system as per functional flow diagram or not.

Calculation Based testing/Coverage

We check arithmetic operations , it includes addition, subtraction,
multiplication and division.

Non-functional Testing
Validating or checking the external functionality of the application
or how our application is interacting with other application.

Types of Non-functional Testing

1- Recovery Testing
2- Compatibility testing
3- Configuration Testing
4- Intersystem testing
5- Installation Testing
6- Parallel Testing
7- Sanitation / Garbage Testing
8- Globalization testing

Recovery Testing
1- It is a testing which verifies software ability to recover from
failures like software/hardware crashes, network failures etc.
2- Process of checking that system is able to recover from
abnormal situation to normal situation.
Eg. Restart the system when browser has multiple sessions
open and check whether the browser is able to recover or not.
 Eg. Download

Compatibility Testing
It is a testing to check whether our software is capable to run on
different OS , Applications, Browsers , mobile devices etc

Types of compatibility Testing

1- Forward compatibility Testing
2- Backward Compatibility Testing

Forward compatibility Testing

Our Build is correct but OS or Browser is not working properly
then it is called as forward compatibility testing.

Backward Compatibility testing

1- I have worked in Backward compatibility Testing.

2- In Backward compatibility testing I have worked in Browser
compatibility testing.

Browser compatibility testing is of 2 types

1- Cross Browser compatibility testing
We will be validating our build is working properly on
different types of browsers or not.
Eg. Chrome, FF , IE , Edge , Safari etc

2- Version Comparison Compatibility testing

In this we will be validating the different versions of same
browser is supporting our build or not.
Eg. Chrome browser with latest version – 98.00, 97.07,
96.453, 95.087

Configuration Testing
It is the process of validating or checking whether our application
supports or works on different hardware or not.
It is nothing but hardware Compatibility testing
Eg. OS, Android devices, iOS devices(Iphone, ipad) etc

Inter-System testing
It is the process of checking or validating whether or application
shares the data with another application or not.
Eg. Paytm Book my show

Installation Testing (Not performed)

It is been performed to check if the software has been correctly
installed or not and product is working as per the expectations.

Parallel Testing
Parallel Testing is the testing multiple application or components
of the application simultaneously to reduce the time.

Sanitation Testing
Validating or checking the extra features added by the developer
but not present in SRS document. At that time sanitation testing
is performed.
Eg. Mobile number -
+9 9999999999
1

Globalization Testing
It is a process of checking whether our application supports
different languages or not.

It includes
1- Localization Testing
In this testing we are going to check whether our application
supports local languages or not.
Eg. Marathi , Hindi

2- Internationalization
 To check whether our application supports international
languages or not.
Eg. Japanese , Spanish, French etc

3- Globalization
To check whether our application supports English language
or not.

Security Testing
Security testing is a process of checking privacy related to user
application.

Types
1- Authorization
2- Access control
3- Encryption and decryption

Authorization
Process of checking whether person is authorized or not.
Authorized person is registered person.

Access Control
Process of checking whether authorized person has permission to
access specific operations.

Encryption and Decryption

Encryption is the process of converting normal message (plain
text ) into meaningless message (Cipher text). Whereas
decryption is the process of converting meaningless message into
its original form.
Performance testing
Performance testing is termed as a type of software testing to
ensure that the software application will perform under their
expected load.

Attributes of performance testing

1- Speed
It shows whether the software responses quickly in all
conditions.

2- Scalability
How much load the software can handle when multiple user
performing operations with the software for a particular time
period.

3- Stability
It helps to know that the software is stable under the
fluctuating loads.

4- Reliability (Consistent)
It checks whether the software can perform a fault free task
for a given period of time in a specified environment.

UAT (User Acceptance testing)

1- UAT is also called as Customer acceptance testing.
2- In UAT we check the real time scenarios of the application.
3- UAT is a type of testing which is performed by the client or
end-user to verify/accept the software application before
moving to production environment.
4- In UAT both dev and testers are involved.
5- After completion of all the testing in SIT environment we
perform UAT testing.
6- UAT is a type of testing, which is done by the customers
before accepting the final product.
 Prerequisites of User Acceptance testing
1- Business Requirements must be available
2- Application should be fully developed.
3- Unit testing, integration testing, system testing, functional
testing should be completed.
4- Only cosmetic error is acceptable before UAT.
(Cosmetic error – spelling mistake, tab sequence ,
background color of specific field, etc)
5- Regression testing should be completed with no major
defects.
6- All the reported defects should be fixed and tested before
UAT.
7- UAT environment must be ready.
8- Mail from testing team should be there that system is ready
for UAT execution.

Who performs UAT?

1- Client – Alpha Testing
2- End User – Beta Testing

Difference Between Alpha Testing and Beta testing?

Alpha Testing Beta Testing
In alpha testing client is In Beta testing End-user is
involved involved
In alpha testing both dev and In beta testing dev and testers
testers are present are not available immediately
Alpha testing ensures the Beta testing also concentrates
quality of the product before on the quality of the product
moving it further but collects the users input on
the product .
Alpha Testing requires a testing Beta testing doesn’t requires a
environment. testing environment.
Alpha testing may require long Beta testing requires only few
execution cycle. weeks of execution.
In alpha testing critical issues Most of the issues or feedback
can be immediately identified are collected from beta testing
and fixed. and will be implemented on the
application in the further
version.

Production Issue
1- If we found a issue/defect in the production environment it is
called as production issue.
2- If we have missed some functionality while doing the
testing , production issue may occur which is called as hot
fix.

What should we do if we found a defect in production

environment?
1- Reproduce the defect – checking it in all the environments or
checking we are using the same software and hardware that
a client or end user.
2- Try to receive as much information as possible , checking all
the browsers and devices
3- Find the cause.
4- Indicate the time when the bug should be fixed.
5- Check if the bug has been fixed.
6- You should analyze why the issue has happened.

Testing Terminologies
Monkey testing
1- Monkey testing is the testing to test the application with
random i/p to check whether our application is crashing or
not.
2- It is also called as speed testing.
3- When there are number of test cases and less time to
execute it at that time we are going to perform the monkey
testing.
 4- In monkey testing we are conducting testing on high priority
test cases and core functionality of the application.
Eg – In my project – payment tab – UPI module – user story –
100 test cases for execution within 2hrs.
PM will say execute the test cases in 2hrs – tester will say I will
be performing the monkey testing.

Exploratory testing
1- When we are not having any knowledge about the
application but we have the test data at that we are going to
perform exploratory testing.
2- Step by step we will be passing multiple test data on the
application to get aware about its functionality.
3- In exploratory testing we write the test cases when we are
aware about the functionality.

Ad-hoc testing
1- We have knowledge about the application , we have test
cases but not the test data at that time we will be
performing the Ad-hoc testing.
2- As per our previous experience about the module or
functionality of the application we will be performing Ad-hoc
testing.

Priority and Severity

Severity
The impact of the bug on the application is known as severity.
Where functionality of the application gets break is known as
severity.
Eg. Signup button not working

Severity can be Critical, Major and Minor

1- Critical – If it is critical, that means the main functionality is
not working, and the test engineer cannot continue testing.
 Eg. Login button not working

2- Major – If it is major , which ,means that the supporting

components and modules are not working fine, but test
engineer can continue the testing.
Eg. In CC section we cannot add multiple emails.

3- Minor – If the severity of bug is minor, which means that UI

is not working fine, but testing can be processed without any
interruption.
Eg. UI defect

Priority
The impact of the bug on the client is known as priority. Priority is
important for fixing the bug or which bug to be fixed first or how
soon the bug should be fixed.

Priority can be High, Medium, and low

1- High – It is a major impact on the customer application and
has to be fixed first.
Eg – Payment tab

2- Medium – In this , the problem should be fixed before the

release of current version of the application.
Eg. Search tab

3- Low – The bug should be fixed if there is time, but it can be

deferred with the next release.
Eg- Alignments, Help tab

Who decides the severity and priority of a defect?

The organization decides the standards regarding , who sets the
priority and severity of a defect. However in most of the cases,
the severity type of defect are set by tester based on the product
functionality. The priority is decided by product owner based on
customer requirement.

Examples of priority and severity

1- High Priority and High Severity
Eg. Payment tab is not working

2- High Priority and Low severity

Eg. Bank logo is not correctly present

3- Low priority and High severity

Eg. Songs site - Download button

4- Low priority and Low severity

Eg – Help and support function tab is not working.

Difference between error , bug and defect?

1- Error – If there is something wrong in the code then it is
called as error.
2- Defect – While doing the testing when we found the error
(Functionality is not working) then it is called as defect.
3- Bug – When developer will accept the defect then it is called
as bug.

The END