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

Database 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/Agile model)

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

functional testing etc..)

Manual 2

Real Testing Part

Project in IT Company – Peoples involved
Client – Project (requirement/Application)

BA (Business Analyst) – Collect the requirement from client

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

time or not.

PM (Project Manager)- works with BA and project team

Solution designer/ Architect – Application Design or

Architecture of your project

Dev team (Development Team) – Developer – coding

Testing – Tester – Application Testing

Interview Question
What is your Team Size?

Team Size – 18 or 19

Peoples involved in project team

BA- 1

PM- 1

Solution Designer/ Architect – 1

Developer – 11 or 12

Tester – 4 or 5

Ratio of Dev and testers

1- Normal project – VI app, JIO app
Retail project – Amazon, Flipkart
Ratio 2:1 - 2 dev to 1 tester

2- Banking domain/Investment/Payment transactions

 Ratio 3:1 - 3 dev to 1 tester

Paytm Project

Module 1 Module 2 Module 3 Module4

Recharge Ticket booking Gas booking Insurance

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

Manual Testing – It is the process of manually testing the

software for defects.

Software Testing – Process of checking the completeness and

correctness of developed software.

Process –Type

SDLC – Software Development Life Cycle

1- Fish Model
2- Waterfall Model
3- Agile Model

SDLC – Software Development Life Cycle

1- It is a process used by the software industry to design ,

develop and test high Quality Software.
2- The SDLC aims to produce a high quality software that
meets clients expectations, reaches completion within time
and cost estimate.

Different types of phases/Stages are there

1- Information 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 – HLD/LLD

Coding – Developer – Application Developed

Testing – Tester – Test the Application

Maintenance/Support

BRS (Business Requirement Specification)

1- This document generally consists of complete scope of the
project.
2- BRS Document is prepared BA
3- BRS is between Customer/Client and BA
4- BRS document is called as non technical document.
SRS (Software Requirement Specification)
1- A Software Requirement Specification is a description of a
software system to be developed.
2- In SRS document all functional and Non-functional
Requirements are covered.
3- SRS is derived from BRS.

SRS Document Includes

1-Functional Flow Diagram

Eg – Facebook – Signup page – Login Page – Homepage –
Profile page

2-Functional Requirement
Eg. Signup page – (Requirement – Firstname, Lastname,
Mobile number, email id, gender, DOB, Password , Submit
button etc.)

3-Use cases
Use cases consist of description and acceptance criteria.
Description – Details about the requirement
Acceptance – Do’s and Don’ts of the functionality
Eg – Mobile number
Description – In this filed contact number should be entered
with Country code.
Acceptance – It should accept 10 digits contact number. If
we are entering 9 digit or 11 digit contact number error
message should be displayed. Like please enter correct
contact number. This field should not accept characters and
special characters.

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

Design – Solution designer /Architect

2 types

1- HLD (High Level Design) – External Functionality of the

application
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 of code is called program
4- Set of program written by developer creates the
application/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 gathering, Data security

Who can work as front end developer and Backend developer is

called as full stack developer.

Testing – Testers

Testers are working on

1- TCD – Test case design

2- TCE – Test case execution
 Maintenance/Support

We provide some warranty – 1month/2 month free

After 1 month client will pay for support.

What is the difference between BRS and SRS?

BRS SRS
BRS is Business Requirement SRS is Software requirement
Specification Specification
This document generally In SRS document all functional
consists of complete scope of and Non-functional
the project. Requirements are covered.

BRS document is prepared in SRS document is prepared in

Non-technical form Technical form
Use cases are not present Use cases are present
From Client BA collects the SRS document is derived from
requirement and prepares BRS BRS
document

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 model/Fish Model
1- Fish model is advance version of SDLC.
2- Fish model consists of verification and Validation

Analysis Design Coding

(SRS) (HLD)/(LLD) (WBT) Support

Req (BRS) Testing(BBT)

Gathering TCD/TCE

(Review) (Review) (Review)

Verification Validation

Static Testing Dynamic Testing

Quality Assurance Quality Control

What is the difference between WBT and BBT?

WBT (White Box Testing) BBT (Black Box Testing)

Developers perform WBT Testers perform BBT
Types of WBT – Unit testing and Types of BBT – Smoke, Sanity,
Integration Testing Functional, retesting, regression
testing etc
Developers are checking their Testers are checking the
code of developed application functionality of the application
as per requirement. as per the requirement.
Called as code level testing Called as system and functional
testing
+ve scenario testing +ve and -ve scenario testing
What is the difference between Verification and
Validation?
Verification Validation
In this testing BA people will In this testing tester will check
review their SRS, Designer will the functionality of the
review their Design, Developer application.
will review 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 the specification. specification captures the
customers requirement.
It is called as static testing It is called as Dynamic Testing
It is called as Quality Assurance It is called as Quality Control
+ve scenario +ve and –ve scenario test
It includes checking of It includes testing and
documents, design, codes and validating the actual product.
program

Grey Box Testing

1- Grey Box Testing is combination of White box testing 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 will check the functionality and if any
fault occurs in the o/p of functionality then tester does not
revert system back to developer, instead of that tester
himself solve or make changes in the 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
high quality software.
3- It provides full documentation of the application.

Disadvantages

1- In this model, the review and testing starts from the project
initiation node to the maintenance phase due to this reason
fish model is a costly methodology for development.
2- It is a time consuming process to develop the product.
3- It is an expensive model so the development failure will
cause lot of damage and loss.

Questions
1- What is Fish Model and its advantages and Disadvantages?
2- Difference between WBT and BBT?
3- Difference between Verification and Validation?
4- Difference between Static testing and Dynamic Testing?s

Waterfall Model
1- It is a process to develop 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 falls from higher level to lower level like a
waterfall. It is named as waterfall model.
5- Duration of waterfall model is of 3 months.
6- It is plan driven process
Information

Gathering

Analysis

(SRS)

Design

(HLD/LLD)

Coding

(WBT)

Testing

(TCD/TCE)

Maintenance

/Support

Note – Completion of Design phase is the entry criteria for

Coding phase and completion of coding is the exit criteria for
Coding phase.

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- If we are getting any changes we can’t go to the back stage.

2- For bigger and complex project this model is not good.
3- Cannot accept new CR (Change request)
Agile Model/Methodology/Process
1- The Agile Scrum Methodology is combination of both
incremental and iterative model for managing product
Development.
( Incremental – which keeps on increasing. Iterative – which
keeps on repeating)
Iterative
means that a team delivers work frequently rather than all
at once.
Incremental
means that they deliver it in small packets of end-to-end
functionality.
2- Agile is a continuous process for development and Testing.
3- Duration of Agile is 1week, 2week, 3week or 4week. (In my
organisation duration of Agile is 2 week)
4- If CR comes then we will check its impact on development,
testing and production or its priority in that application.
5- Agile is a value driven process.

Sprint – A sprint is a set period of time during which specific

work has to be completed and made ready for review.

Agile Framework/Sub module

1- XP – extreme programming – Continuous development

2- Scrum – Scrum is a framework that helps teams work
together. To give sprint wise delivery to client.
3- FDD – Future driven development.
4- Kanban
5- Lean
On which Methodology you have worked?

I have worked in Scrum Agile Methodology.

Agile Architecture

Information Gathering(BRS) Product Backlog(200req)

Analysis (SRS) Sprint Backlog [20req – 1 sprint]

[14req – 2 sprint]

[18req- 3 sprint]

Use Cases User story (1 requirement)

Description criteria Description Criteria

Acceptance Criteria Acceptance Criteria

Design (HLD/LLD) Design (HLD/LLD)

Coding (WBT) Coding (WBT)

Testing(TCD/TCE) Testing(TCD/TCE)

Maintenance/Support Maintenance/Support
Peoples involved in Agile with their name.

Client - Stakeholder

BA – Product Owner

DM – Solution Master

PM – Scrum Master

Designer - Designer

Developer - Developer

Tester – Tester

Stakeholder

1- Client or Customer is called as stakeholder in Agile

2- He is the member of top most body of company.
3- At any phase of dev, testing production they can request for
change.

Product owner

1- Product owner collects the requirement from stake holder.

2- He is the member of sprint planning meeting.

Product backlog

Product backlog are the total requirement for the whole project.
It includes requirement of all modules.

Sprint Backlog

1- Created by product owner.

2- Sprint backlog contains user story.
Agile Meetings/Ceremonies

Meeting Purpose Involvement of

people
Grooming Doubts about the 30min/1hr –
Meeting requirement will be Product owner
(Before start of cleared. (Chair person), Dev
Sprint) team, Design
Team, Testing
team, Scrum
master(optional)
Sprint Planning 1- Decide the user 1hr – Scrum
Meeting (1st day story- (eg – 16req) master (Chair
of Sprint) 2- Estimation/Story person), Dev team,
point (time slot to Design team,
complete the user Testing Team,
story) (1user story Product owner.
– 16hrs)
Daily Stand up 1- What you have 15min/30min –
(Scrum Meeting) done yesterday? Scrum
2- What you are Master(Chair
going to do today? Person). Dev team,
3- What are the Design team,
Roadblocks or Testing Team,
issues faced? Product
Owner(optional)
Sprint Review User story completed – 1hr – Product
Meeting (End day Demo or review is given owner(chair
of Sprint) person),
Stakeholder, Dev
team , Testing
team, Design
Team, Scrum
master(optional))
Sprint Good and Bad things in 30min – Scrum
Retrospective the current sprint. Master (chair
Meeting (End day (Discussion) person), Testing
of sprint/1st day of team, Dev team,
next sprint) Design Team,
Product owner
(Optional)

Zero Sprint – It generally refers to the first step or pre-

preparation step that comes just before the first sprint. It
includes all activities such as setting development environment,
preparing backlog, project skeleton etc.

Sprint – 3 (14US)
1st Week

Monday (First day of Sprint) – (Office time 11am -8pm)

 Sprint Planning Meeting (1hr/2hr)

1- Sprint 3- 14 US added and US allocated/Assigned – 4US
2- Every US Estimation/Story point – 1US- 16hr
dev+14hrs(Testing) – 30hrs

1US – Developer – Coding 8hr – in progress

1US – Tester – TCD(6-7hrs) – 1US TCD- Completed

Tuesday

 Stand Up Call/ Scrum Meeting (15min/30min)

1- What you have done yesterday? – 1US TCD – Completed
2- What you are going to do today? – 2US TCD – Start
3- Any Issues/Roadblock

1US – Developer – Completed and sent build to tester.

2US – Tester – TCD(6-7hrs) – TCD completed.

Wednesday

 Stand Up Call/ Scrum Meeting (15min/30min)

 1- What you have done yesterday? – 2US TCD – Completed
2- What you are going to do today? – 1US TCE – Start
3- Any Issues/Roadblock

2US – Developer – Coding – in progress

1US – Tester – TCE(7hrs) – TCE completed

Thursday

 Stand Up Call/ Scrum Meeting (15min/30min)

1- What you have done yesterday? – 1US TCE – Completed
2- What you are going to do today? – 3US TCD – Start
3- Any Issues/Roadblock

2US Developer – Completed and Build send for testing

3US Tester – TCD completed

Friday

 Stand Up Call/ Scrum Meeting (15min/30min)

1- What you have done yesterday? – 3US TCD – Completed
2- What you are going to do today? – 2US TCE – Start
3- Any Issues/Roadblock

3US – Developer – Coding in progress

2US – Tester – TCE Completed

2nd Week

Monday

 Stand Up Call/ Scrum Meeting (15min/30min)

1- What you have done yesterday? – 2US TCE – Completed
2- What you are going to do today? – 4US TCD – Start
3- Any Issues/Roadblock
3US – Developer – Completed the coding and build sent for
testing

4US – Tester – TCD in progress

Tuesday

 Stand Up Call/ Scrum Meeting (15min/30min)

1- What you have done yesterday? – 4US TCD
2- What you are going to do today? – 3US TCE – Start and
Remaining 4US TCD complete
3- Any Issues/Roadblock

4US – Developer – Coding in progress

4US – tester – TCD completed – 3US – TCE in progress and

having few doubts about the requirement.

Wednesday

 Stand Up Call/ Scrum Meeting (15min/30min)

1- What you have done yesterday? – 4US TCD – Completed,
3US TCE in progress
2- What you are going to do today? – 3US TCE
3- Any Issues/Roadblock – Requirement is not properly cleared
(Scrum master will say – Connect with the product owner
and get your doubts cleared)

4US – Developer – Completed

3US – TCE Completed – In 3US TCE we found defects – 2 defects

raised and assigned to developer – Developer will fix the defect –
Sent for testing – Tester will retest that 2 defects

Developers are working on raised defect

Thursday

 Stand Up Call/ Scrum Meeting (15min/30min)

 1- What you have done yesterday? – 3US TCE – Completed - @
defects raised
2- What you are going to do today? – 4US TCE
3- Any Issues/Roadblock

3US – Developer – Fixed the defect – Defect ids – 11901,11907

4US – Tester – TCE in progress – raised 1 defect – Defect id –

11909

Tester has tested 2 defects – 11901, 11907

Developer not accepting the defect id – 11909

Friday

 Stand Up Call/ Scrum Meeting (15min/30min)

1- What you have done yesterday? – 4US TCE in progress – 1
defect
2- What you are going to do today? – 4US TCE remaining
3- Any Issues/Roadblock – Developer not accepting the defect (
Scrum master – Raised defect is valid defect fixed it)

4US – Developer – Defect fixed – 11909

4US – Tester – TCE completed – Developer has fixed the defect

and tester had retested it.

 Sprint Review Meeting (1HR)

Every Tester will give the demo to stakeholder/Product
owner – 4US demo

 Sprint Retrospective Meeting

Current Sprint 3 – Next Sprint 4
Good – Tester has raised very high priority defects.
Bad – Developer has not done proper coding.

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

Disadvantages

1- If requirement is not clear before the sprint then sprint can

go out of scope.
2- Less Documentation
3- Cost of Agile Methodology is slightly more as compared to
other development Methodology.

Agile Terms
1-Burn Down Chart –How much user story are remaining
w.r.t time.
2-Burn Up Chart – How much user story completed w.r.t time
3-Epic – It is US in sprint

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

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

Environments

Dev SIT UAT Prod

Environment Environment Environment Environment
Developer Tester Dev and Tester

Pune Company USA Client

Access of remote desktop (UAT)

Types of testing in different Environments

Dev Environment (WBT)

1- Unit Testing
2- Integration Testing

SIT Environment

1- Initial Build
Sanity/Smoke Testing
2- For Stable Build
Functional Testing
Retesting
Regression Testing

Regression Testing UAT

SIT

UAT Environment

1- Alpha Testing
2- Beta Testing

UAT
Regression Testing Prod
Production Environment

Dev Environment
Unit Testing – Testing which will be performed on individual
module will be called as Unit Testing.

Integration Testing – The testing perform of main module by

combining various module is called integration Testing.

SIT Environment (System Integration Testing)

Smoke Testing

1- It is a software testing process that determines whether the

developed build /Software 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- Smoke testing is performed by developers or Testers.
5- Test cases are not written
6- In smoke testing we are checking either the build is stable
for testing or not.

Smoke testing Checkpoints/Validation

1- Validating the core functionality

2- Validating GUI/UI functionality
3- Validating the links present in Build
4- Validating the tabs
5- Validating the pages

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

functionalities of our application 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 major
testing.
 If build is not meeting the acceptance criteria then test lead
will send email to development lead saying that we are
rejecting the build and 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 developers 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
further functional testing.
4- If the defects are found in sanity testing then build is
rejected, that is helpful in saving time for execution of
regression testing.

What is the 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 part 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 end to end It is used to test only modified
function of the application functions of the applications.
Smoke testing is performed by Sanity testing is performed by
developers or tester. testers.
In this we are going to check It is a subset of regression
whether the build is ready for testing in that we are going to
testing or not. focus on particular part of our
application.
Regression Testing

1- When we find any defect then that defect is fixed by

developer, then tester will retest that defect. After the
retesting we will be performing regression testing to check
whether other functionality of the application are not
impacted.
2- We will be performing regression testing when we are
moving from one environment to another environment.
3- Also we are going to perform regression testing whenever
any CR comes from the client.

Retesting

When the tester finds the defect in the application he will assign
that defect to developer to fix that defect. Once that defect is
fixed by the developer then that developer will assign back that
defect to tester. Then tester will retest that defect to check
whether it is fixed or not that is nothing but the retesting.

Extra Points

Regression Testing:
 Regression testing is one of the black box testing
techniques. Regression testing is done to validate a code
change in application is not impacting the existing
functionality of the software.
 Regression testing is making sure that the software works
fine with a new added functionality, defect fix or any other
change in software.
 In Regression testing test cases are re executed to check the
previous functionality is working fine or not.
  It is performed on a newly delivered build by development
team after a significant change in original functionality.
 Regression testing ensures that the software still works after
changes in software.

When To Perform Regression Testing:

Regression testing is done whenever the software code is
modified.

The software code is modified in the following scenarios:

 When new functionality added to the application.

 When there is a Change Requirement.

 When there is a defect fixed.
 When there is a performance issue fix.
 When there is an environment change.

Smoke Testing :

Smoke testing is done at the time of receiving build from the

development team.
 Purpose of smoke testing is to determine that the build
received is testable or not.
 Smoke testing is also known as Day 0.
 Smoke testing is a time saving process. It reduces time of
testing, because testing activity will only be performed when
the key functionality of software are working fine.
 The main focus of smoke testing is on the working of core or
primary functionality of software.
 The existing test cases are used in smoke testing. The cases
are picked as per the requirement of the smoke testing.
Sanity Testing:
 Sanity testing is done at the time of build with minor
changes in the functionality.
The motive of sanity testing is to ensure that all the defects
have been fixed and no defect arise from the fixed defects.
 Sanity testing is a kind of regression testing with focus on
impacted modules only.
 Sanity testing make sure that changes in code or software
have no impact on the connected modules. Therefore the
related modules are tested in sanity testing.
 The sanity test cases are picked from test suite and no new
cases are designed for sanity testing.

System and Functional Testing

In this testing we are going to check whole functionality of the
application.

System and functional testing includes

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

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

Factors that decides the user friendliness of an application.

1- Application should be easy to understand.

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

Functional Testing/Functionality Testing

1- Functional Testing
2- Non-functional Testing

Functional Testing – It depends on validating /checking the

internal functionality of the application/module/sub-module as
per the requirement.

It includes six types of coverage’s/testing

1- Behavioural 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

Behavioural Testing/Coverage

In this we are validating/checking the behaviour of the

application.

Validate Objects and behaviour of object.

Object Behaviour of object

Text box Focus or unfocus
Radio button On/off
List box/Drop down Enabled or disabled
Checkbox Clickable / non clickable
Input domain coverage/testing

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

which we are passing into object.

Eg – Mobile Number -

10 digit mobile number – Data type – number, size - 10

In this we have two types

1- BVA – Boundary value Analysis

2- ECP – Equivalence class partitioning

BVA – Boundary value analysis

1- We are checking size/length of data passing into the object.

2- In BVA we are going to check how our application is
functioning when we insert a boundary value.
3- Formula of BVA – Min, Max, Min-1, Min+1, max-1, Max+1

Eg – Password text box accepts 4 to 8 number

Object Passing criteria Fail Criteria

Text box – 4 digit number pass
Text box – 8 digit number pass
Text box – 3 digit number fail
Text box – 5 digit number pass
Text box – 7 digit number pass
Text box – 9 digit number fail

ECP – Equivalence class partitioning

In ECP we are going to validate the data types which we are

passing into the object.

Object Passing criteria Fail criteria

Mobile number (text Int (0-9) A-Z, a-z , special
box) Char
4-8 char textbox A-Z, a-z Int (0-9), Special
char

Q- What is decision table?

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

Eg – We will create the decision table for a login screen that asks
for userid and password. The condition here is that user will be
redirected to homepage if he enters the correct userid and
password and an error message will be displayed if the input is
wrong.

Terms

C- Correct username or 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 Coverage/Testing

In this testing we will be validating or checking the field by

passing invalid test data that system is showing warning or error
message.

Eg – Payment tab – debit card

 Card number –

Exp date –

CVV –

holder name -

SUBMI

Debit card –

1- By passing invalid card number – error message will be

shown – Please provide valid card number
2- By passing blank value in debit card – this field should not
be blank / Please provide debit card number etc

Backend Testing/Coverage

In this we will be validating/checking whatever operations are

performed on frontend same are stored in backend/database or
not.

Service level testing/Coverage

In this we are going to check sequence and functions of module

on the basis functional flow diagram. We check working of system
as per functional flow diagram this is called as service level
testing.

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 failure etc.
2- Process of checking 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.

Compatibility Testing

It is a testing to check whether our application is capable to run

on different OS, Devices, browsers etc.

Types of Compatibility Testing

 Forward Compatibility Testing

 Backward Compatibility Testing

Forward Compatibility Testing

Build is correct but OS, browsers or devices are not working
properly then forward compatibility testing is performed.

Backward Compatibility Testing

I have worked on Backward Compatibility Testing. In Backward

Compatibility Testing we 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 or not on
different types of browser.
Eg – Chrome, Edge, Safari, FF etc

2-Version Comparison Compatibility Testing

In this we will be validating the different version of same
browser that it is supporting our build or not.
Eg – Chrome browser with latest version – 108, 107, 106,
105

Configuration Testing

It is the process of validating or checking whether our application

is working on different hardware or not. It is nothing but
Hardware Compatibility Testing.

Eg – OS, Android , iOS devices, Printers, Scanner, Webcam etc

Inter-System Testing

It is the process of checking or validating whether our application

shares data with other applications or not.

Eg - Paytm Airtel
Installation Testing (Not Performed)

It is been performed to check if the software is been correctly

installed or not and product is working as per expectations.

Parallel Testing

Parallel Testing is testing multiple applications or components of

the application simultaneously to reduce the time.

Sanitation Testing/ Garbage testing

Validating or checking the extra features added by the developer

but not present in SRS document.

Eg – Mobile Number - +91

Globalization Testing

It is a process of checking whether our application supports

different languages or not.

It includes

 Localization Testing – In this we are going to check

whether our application supports local language or not.
Eg – Hindi , Marathi

 Internationalization - In this we are going to check

whether our application supports international language or
not.
Eg – Spanish , French , German , etc

 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

 Authorisation
 Access Control
 Encryption And Decryption

Authorisation

Process of checking whether person is authorised or not.

Authorised person is registered person.

Access Control

Process of checking whether authorised person has permission to

access specific operations.

Encryption and Decryption

Encryption is the process of converting normal message 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 software application will perform well under their
expected load.

Attributes of performance Testing

 Speed – It shows whether the software responses quickly in

all conditions.
 Scalability – How much load the software can handle when
multiple user performing operation with the software for a
particular time.
  Stability – It helps to know that the software is stable
under the fluctuating loads.
 Reliability (Consistent) – It checks whether the software
can perform a fault free task for a given period of time.

UAT (User Acceptance Testing)

1- UAT is also 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 before moving it to
production environment.
4- After completion of all the testing in SIT environment we
perform UAT testing.
5- In UAT both Dev and testers are involved.
6- UAT is a type of testing which is performed by the customer
before accepting the final product.

DRE – Defect Removal Efficiency

How deeply we have tested the application/Build.

DRE = A/A+B

A= Defect found in SIT

B= Defect Found in UAT

A= 8 B= 2 =DRE = 0.8 – Good Tester

A= 8 B= 4 DRE = 0.67 – 0.5 to 0.8 – Avg Tester

A= 8 B= 6 DRE = 0.5 – less than 0.5 – Below avg Tester

Prerequisites of User Acceptance Testing

1- Business requirements must be available.
2- Application should be fully developed
3- Unit testing, Integration Testing, System and functional
testing should be completed.
 4- Only cosmetic error is acceptable before UAT.
(Cosmetic error – Spelling Mistakes, Colour change, Font
size, Alignments, Tab sequence 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. (Done with testing for XYZ module.
Everything is working fine as expected. Giving Signoff from
SIT environment).

Who performs UAT?

1- Client (Alpha Testing)

2- End User (Beta Testing)

What is the 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
forwarding it further. and ensures that the product is
ready for real time users.
Alpha Testing requires a testing Beta testing doesn’t require
environment testing environment.
Alpha testing may require long Beta testing requires few weeks
execution cycle. of execution.
In Alpha testing critical issues In Beta testing Issues or
can be immediately identified feedbacks are collected from
and fixed. End user and it will be
implemented in future version
of the product.

Production Environment
Production Issue

1- If we found issue / defect in production it is called as

production issue.
2- If we have missed some functionality while doing
testing production issue may occur which is called as
hot-fix.

What should we do If we found a defect in production

Environment?
1- Checking in all environments or checking we are using the
same browser or device that a client or end user uses.
2- Try to receive as much information as possible checking all
the browsers, devices where exactly it is happening.
3- Find the cause.
4- Raise the defect and indicate the time when that bug should
be fixed.
5- Check if the bug has been fixed. If the bug is fixed retest it.
6- You should analyze why the issue has happened.

Testing Terminologies
Monkey Testing

1- Monkey testing is a testing to test the application with

random i/p to check whether our application is crashing or
not.
2- It is called as speed testing.
3- When there are maximum number of test cases and less
time to deliver a product then we do monkey testing.
 4- In monkey testing we are performing testing on high priority
test cases and core functionality of the application.
Eg – In my project for payment tab UPI module is added –
User story – 100 test cases and for execution we have 2hrs
– PM will say execute the test cases in 2hrs – Tester will say
I will be performing Monkey testing.

Exploratory Testing

1- When we are not having any knowledge about the

application but we have test data at that time 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 test cases when we are
aware about the application.

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 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. It can be Critical, Major, Minor
Critical – If it is critical that means the main functionality is not
working, and the test engineer cannot continue with the further
testing.

Eg – Signup button is not working

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.

Minor – If the severity of bug is minor, which means that all the
UI problems are not working fine, but testing can be processed
without any interruption.

Eg – Alignment issue, Font size, spelling mistakes etc

Priority - The impact of the bug on the client business is known

as Priority. It is important for fixing the bug or which bug to be
fixed first or how soon the bug should be fixed. It can be High,
Medium and Low

High – It is a major impact on the customer application and it

has to be fixed first.

Eg – Payment tab not clickable, Signup button is not working etc

Medium – In this the problem should be fixed before the release

of the current version or sprint in development.

Eg – Search tab.

Low – This should be fixed if there is time, but it can be deferred

with next release.

Eg- Alignments etc

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 cases, the
severity type of defect is set by tester based on the product
functionality and the written test cases. The priority is decided by
the product owner based on Customer/client requirement.

Few 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 – Print button, Download button

4- Low Priority and Low severity

Eg – UI defects

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.

When a developer says that an issue you reported is not a bug, it could mean
one of two things: either there is no issue or the issue exists but the developer
has a different understanding of the expected behavior.
Here are some steps you can take to resolve the situation:

1. Review the specifications and requirements: Double-check the

documentation and requirements to see if the issue you raised is
actually a bug or if it's a difference in expectations. Make sure to provide
detailed steps to reproduce the issue.
2. Get a second opinion: If you're still convinced that the issue is a bug,
you can get a second opinion from another developer, preferably
someone with more experience in the area.
3. Discuss the issue with the developer: Have a conversation with the
developer and explain why you think it's a bug. Be prepared to provide
additional information, such as logs or screenshots, to support your
argument. Listen carefully to the developer's explanation and try to
understand their perspective.
4. Escalate the issue: If you still can't come to a resolution with the
developer, you can escalate the issue to a higher authority, such as a
project manager or technical lead. Make sure to provide all the
necessary information and documentation to support your claim.
5. Consider the impact: If the issue is not critical and does not affect the
functionality of the system, you may need to consider whether it's worth
pursuing further. Sometimes, it's better to let minor issues go in favor of
focusing on more important ones.

Remember, communication is key in these situations. Stay respectful and

professional throughout the process, and try to work collaboratively with the
developer to find a solution.
Regenerate response

As an AI language model, I don't have personal experiences, but I can provide

a hypothetical example of how a difficult problem in automation can be
solved.
Let's say that you're working on automating a web application that uses
dynamic locators to identify elements on the page. The dynamic locators are
based on the unique attributes of the elements, which can change every time
the page is refreshed or updated.

The issue you face is that the automation script is unable to locate the
element consistently, resulting in frequent failures and false positives. This is a
common problem in automation, and it can be challenging to resolve.

Here are the steps you might take to solve this problem:

1. Analyze the problem: The first step is to understand the cause of the
issue. You might analyze the script's failure logs and identify patterns or
commonalities in the failures.
2. Use stable locators: Instead of using dynamic locators, you might switch
to using stable locators, such as the element's ID or name attribute.
These attributes are less likely to change and can provide a more
reliable way to identify the element.
3. Implement waiting strategies: Sometimes, dynamic locators are
unavoidable. In such cases, you can implement waiting strategies to
allow the element to load fully before the script attempts to locate it.
This could involve adding a sleep function or implementing a wait-for-
element method.
4. Use regular expressions: Another way to locate elements with dynamic
attributes is to use regular expressions. Regular expressions allow you to
search for a pattern in the attribute value, rather than relying on the
exact value itself. This can be a more flexible and reliable way to locate
elements.
5. Perform regular maintenance: Finally, it's important to perform regular
maintenance on the automation script to ensure that it remains up-to-
date with any changes to the application. This might involve updating
locators or modifying the script's logic to accommodate new features.

By following these steps, you can resolve the issue of dynamic locators and
create a more reliable and robust automation script.
Regenerate response
 THE END