Manual Testing

IT Company Projects – Dev team and testing Team

( project technology – application – java – dev team) testing is
required
( projectteachnolgy – Application - .net – dev team ) testing is
required
Types of testing
1- Manual testing – manual 1 and manual 2
2- Database testing
3- Web service testing/ Api testing
4- Automation testing
5- 2 real time projects
1- Project – Manual testing,Automationtesting,database
testing, API testing/Web service testing
Manual Testing
Manual 1
Process – SDLC/Fish model, V-Model,Waterfall model, Agile
model (90 to 95%)
Types of testing –Smoke testing, sanity testing, functional
testing, regression testing, retesting etc
Manual 2
Real testing part
Project in IT company – Peoples involved
Client – project ( Requirement / Application)
BA ( business Analyst) – Collect the requirement from client
Delivery Manager (DM) –Requirement of client are provided
on Time or not
PM( project Manager) – works with BA and project team
Solution designer/ Architect – Application Design
Dev team – Development team – Developer- coding
Testing team – Application testing
Team size – 18 people
Peoples involed in project team
BA- 1
PM – 1
Solution designer/ Architect – 1
Developer – 11
Tester- 4
Ratio of Dev an tester
1- Normal project – VI application etc
Retail project – Amazon Flipkart
Ratio – 2 dev to 1 tester 2:1
2 – banking domain / Investment/ payment transactions
Ratio 3 dev to 1 tester 3:1
Paytm Project

Module 1 module 2 module 3 module 4

Recharge Ticket Booking Gas booking Insurance
3:1 2:1 3:1 3:1
Manual testing
Manual testing is the process of manually testing the
software for defects.
Software testing
Process of checking the completeness and correctness of the
developed application
SQA ( Software Quality Assurance )
It is a process in which client monitors and measures the
strength of developed application.
Communication between customer and business analyst is
called software quality assurance.
Factors
1- Requirement of client are fulfilled not.
2- Clients expectations ( performance and security)
3- Time to deliver
4- Cost of project
5- Maintenance

BA
Requirements

Client
Developers Testers

Process – type
1- SDLC – (Software development life cycle)/ Fish model
a- Fish model
b- Waterfall model
c- V- model
d- Agile model ( 90-95%)

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 a 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/ client requirement gathering
2- Analysis
3- Design
4- Coding/ development
5- Testing
 6- Maintenance/ Support

Different types of phases /Stages are there

1- Information gathering/ Client 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/FRS/CRS (

software/System/Functional/Customer requirement
specification)

Design/ Architecture – HLD/LLD

Coding – Developer – Application develop

Testing – tester – Test the Application

Maintenance /Support

BRS ( Business Requirement Specification)

The document generally consists of the complete scope of the
project , the performance , requirement and usability.
BRS is bridge between customer/client and BA.
SRS ( Software Requirement Specification)
A software requirement is a description of a software system to
be developed.
In SRS document all functional and non-functional requirement
are covered.
SRS is derived from BRS.
SRS Document Include
1-Functional Flow Diagram
Eg- Signup page- Login page – Home page – Profile page

2-Functional Requirement
Eg- Signup page – First name, Last name , email id,
mobile number, DOB, Password , Submit button etc..

3-Use cases
Use cases consists of description and acceptance criteria.
Description – Details about the requirement. ( Entering
the mobile number)
Acceptance – Does and don’ts of the functionality.( Field
should accept 10 digit mobile number)

4-Screenshot/Snapshot
Snapshots are visualization of functionalities before
development of product.
Snapshot is made by BA using HTML code and Irise
software.
Design
Solution designer/Architect
2 types of design
1- HLD ( high level design) – External functionality of the
application – Main module
2- LLD (low level design) – Internal functionality of the
application – Sub module – Front End developer
Coding
1- Coding means Program
2- One line is code
 3- Multiple line code is called as program
4- Set of program written developer creates software.
2 types of developer
1- Front end developer- UI, Functionalities, Functional
flowdeveloper is called as
2- Backend developer – Data management,Data gathering,
data security
Who can work as front end as well as back end developer is
called as full stack developer.
Testing
Testers are working on
TCD – Test case design – to write test cases
TCE – Test Case execution
Maintenance/ Support
We provide some warranty – 1 month free
After 1 month client will pay for support.

What is BRS and SRS?

BRS
Business requirement
Specification
The document generally
consists of the complete
scope of the project , the
performance , requirement
and usability.
SRS
Software requirement
specification
A software requirement is a
description of a software
system to be developed.

BA people prepares BRS BA people prepares SRS

From client BA collects
requirements - BRS
All requirements are covered
Use cases are not present
Derived from BRS
All functional and non-
functional requirements are
covered
Use cases are present in SRS
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

SRS HLD/LLD WBT Support
Req testing
Gathering BBT
(review) ( Review) ( review)
Verification Validation
Static testing/ Quality Control Dynamic testing
Quality Assurance
Fish model is advance version of SDLC.
Fish module consist of verification and Validation.
Difference between WBT and BBT?
WBT BBT
Developers perform WBT Tester perform BBT
Types of WBT – Unit testing Types of BBT – Sanity ,
and Integration testing smoke, functional , retesting ,
regression etc.
Developers are checking their Testers are checking the
code of developed application functionality of application as
as per requirement. per 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
In this testing BA people will
review their SRS, Designer will
review their design , and
Developer their code.
Involved BA,
Designer,Developer
+ve scenario
Verification is the process of
checking that the software
meets the specification
It is also called as static
testing or Quality Assurance
Validation
In this testing tester will check
the functionality of the
application means he will be
validating the application.
Involved Tester
+ve and –ve scenario
Validation is the process of
checking whether the
specification captures the
customers requirement.
It is also called as dynamic
testing or Quality Control

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 need programming
knowledge.
4- The role of grey box tester is , whenever final S/w is
handed over to tester , tester checks its functionality and
if any fault occurs in the o/p of function then tester does
not revert defect 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
correctness and completeness 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, the review starts from project initiation
node to the maintenance phase, due to this fish model is
a costly methodology for development.
2- It is a time consuming process to develop a product.
3- It is an expensive model so the development failure will
cause a lot of damage and loss.
Questions
1- Difference between BBT and WBT?
2- Difference between static testing and Dynamic testing?
3- Difference between verification and validation?
Waterfall model
Information
Gathering(BRS)
Analysis(SRS)
Design(HLD,LLD)
Coding
Testing(TCD,TCE)
Support
1- It is a process to develop a software.
2- Waterfall model is called as a 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.It is named as 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.
Disadvantage
1- Cannot accept new CR (Change request)
2- For bigger and complex project this model is not good.
3- If we are getting any changes, we can’t go to the back
stage.
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 testing and sanity testing
(Build installation) System and functional testing
UAT
Documentation
Maintenance DRE (Defect removal efficiency)
RFC, CR
Post mortem 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 testing
stages.
4- Duration of V-model is of 3-months.
5- V-model is used in big organization.
Assessment of dev phase
Assessment of dev phase means to make the strategy for
testing.
In this phase we decide which methodology is going to be
used for testing manual or Automation.
Test Plan preparation
In test plan preparation PM prepares a test team and TL
prepares Test plan.
In this phase test estimation is created.
Test estimation means who will work on which module and
how much time it will take to complete.
Design/program phase testing
In this phase code is tested.
This code testing starts from small unit of program.
In this testing developer is involved as he knows the code.
And we can call it as WBT.
Test case design
+ve and –ve scenario test design
Testers are involved
This is called as BBT when we will be executing this test
design.
Eg. 10 digit mobile number
Defect removal Efficiency
DRE= A/A+B
A- Defects found by tester - 8
B- Defects found in client environment – 2
0.8 – good tester
0.5- 0.8 – Avg tester
Less than 0.5 – below avg tester
Postmortem testing
Done by white box tester.
When whole testing is done and product is ready for release
and if product is not providing the desired o/p then white
box tester need to check all modules in detail.
Advantages of V-Model
1- Testing activities like planning, test designing happens
well before coding.
2- Time saving and quick.
 3- Avoids the downward flow of the defects.
Dis-advantages of V-model
If there is any change requirement in between then the test
document along with the requirement needs to be updated.
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 – repetition till project is completed)
2- Agile is a continuous process for development and testing.
3- Duration of agile is 1/2/3/4 weeks – 2 weeks
4- Agile is a value driven process.
5- If CR comes then we will check its impact on
development, testing and production or its priority in that
application.
Agile framework/Submodule
1- XP – extreme programing – continuous development
2- Scrum – 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 on Scrum agile methodology.
Agile Architecture
Information Product backlog(200 req)
Gathering (BRS)

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

[20req-2sprint]
[20req-3sprint]

Use cases User story/ 1 requirement

Description criteria Description
 Acceptance criteria Acceptance

Design design

Coding Coding

Testing Testing

Maintenance/support Maintenance/support

People 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- Dev team – dev team
7- Tester - tester
Sprint – A sprint is a set period time during which specific work
has to be completed and make ready for review.
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, or production they can
request for change.
Product owner
1- Product owner collects the requirement from stakeholder.
2- He is the member sprint planning meeting.
Product backlog
Product backlog are the total requirement for the whole
project.
 It includes requirements for all modules.
Sprint backlog
1- Created by product owner
2- Sprint backlog contains user story.
Zero Sprint
It generally refers to the first step or pre-preparation that
comes just before the first sprint. It includes all activities
such as development environment, preparing backlog,
project skeleton, etc.

Agile Meetings/Ceremonies

Meeting Purpose Involvement of

people
Grooming Any doubts in the 30min/1hr Product
Meeting (Before requirement. owner(Chair
start of the person) , dev
Sprint) team, testing
team, Design
team, Scrum
master(Optional)
Sprint planning 1- Decide the user 1hr – Scrum
meeting (1st day story. master(chair
of Sprint) 2- Estimation(time person), Product
slot to owner, designer,
complete the dev, tester
user story)
(1user story –
16hr)
Daily stand up 1- What you have 15min – Scrum
(Scrum Meeting) done master(Chair
yesterday? person), Designer,
2- What you are dev, tester,
going to do Product
today? owner(optional)
3- What are the
 roadblocks or
issues?
Sprint review After completion of Stakeholder,
meeting(End day User story – giving product owner ,
of sprint) the review/demo dev team, testing
team, designer,
Scrum master
Sprint Good and the bad 30min – Scrum
Retrospective things in the current master(Chair
Meeting(end day Sprint(discussion) person) , Testing
of sprint/1st day team, dev team,
of next sprint) designer , product
owner(optional)

Advantages
1- Sprint wise delivery
2- Working software is delivered frequently.
3- Customers, developers and testers constantly interact
with other.
4- Change request are accepted immediately.
Disadvantage
1- If requirement is not clear before the sprint the sprint
can go out of scope.
2- Less documentation
Agile terms
1- Burn Down Chart
How much user story remaining with respect to time.
2- Burn up chart
How much user story completed with respect to time.

3- Epic
It is the user story in sprint.

4- Velocity

Progress (woork done) against the estimated time.

Environments in Project

How many environments are there in your project?

Environment

Dev SIT UAT Production

Environment Environment Environment Environment
Developer Tester Dev and testers

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
Smoke/Sanity testing

For stable build (BBT)

 Functional testing
Retesting
Regression Testing

SIT
Regression Testing UAT

3-UAT Environment
a- Alpha testing
b- Beta testing

UAT Regression Testing Prod

4-Production Environment

….…………………………………………………………………………
Dev Environment
1-Unit testing
a- Testing which is performed on individual module is
called as unit testing.
b- Developer will perform Unit testing
c- Test application is checked in +ve scenario/way

2-Integration Testing
The testing perform on main module by combining various
module is called as integration testing.
Integration testing is perform by developer.

There are 3 ways of integration Testing

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

Top Down Approach

1- In top down approach testing is don 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 types of testing, stubs are used as temporary
module if a module is not ready for testing.
4- I this case we are using dummy module.
5- STUB is a dummy program created by developer.
Bottom up approach
1- If we have sub module but do not have main module
then in that case we use bottom up approach.
2- To check sub module, developer creates dummy main
module.
3- Developer first creates program called driver.
4- These DRIVER program are in XML language.
Bidirectional Approach
Combination of Bottom up approach and top down
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.

Smoke testing checkpoints /Validation

1- Validating the core functionalities.
2- Validating the GUI/UI functionality
3- Validating the links present in build.
4- Validating the tabs
5- Validating the pages

4- In this testing we are going to verify all the basic

functionalities are working or not based on that we will
accept or reject the build.
 5- Accordingly our test lead will send a mail to
development lead saying that we are accepting the
build for major testing.
6- If build is not stable or it does not meet the acceptance
criteria then test lead will send mail to development
lead saying that we are rejecting the build. Specifying
that 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
further functional testing.
4- If the defects are found during sanity testing, then build
is rejected that is helpful in saving time for execution of
regression testing.

Difference between Smoke testing and Sanity testing

Smoke testing Sanity testing

It is a broad approach to
testing where all parts of
the application are tested.
Smoke testing is the first
testing performed on the
initial build.
It is used to test end to
end function of the
application
Smoke testing is
performed by developer or
tester
In this we are going to
check whether the build is
ready for testing or not.
It is a narrow approach to
testing where specific part
of the application is tested.
Sanity testing is performed
when the build is
comparatively stable.
It is used to test only
modified or defect fixed
functions.
Sanity testing is performed
by tester.
It is a subset of regression
testing in that we are going
to focus on particular part
of our application.
Retesting
When we find the defect then defect is fixed by developer ,
then tester is going to check whether the defect is fixed or
not that means he will retest it . i,e is called as retesting.

Regression Testing
1- After fixing the defect we will be checking that any other
functionality of an application will not be impacted that we
are going to check that is nothing but regression testing.
2- Also when we are going to move from one environment to
another we are performing Regression testing.
3- Also we are going to perform regression testing whenever
any CR comes from the customer.

System and Functionality testing

It is nothing but BBT.
In this testing we are going to check the whole functionality
of the application.
System and functionality testing includes.
1- Usability testing
2- Functional testing
3- Security testing
4- Performance testing

Usability testing :
Testing the user friendliness of the application is called
usability testing.
Factors that decide the user friendliness of an application
1- It should be easily Accessible
2- Application should be in easy language.
3- It should be easy to understand
4- Proper help text messages should be displayed.
5- Navigation should be very simple
6- Appearance of the application.

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
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 coverage/testing
In this we are validating or checking the behaviour of the
application.
Validate objects and behaviour of objects.
Object Behaviour of the 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.
Eg . 10 digit mobile number – datatype – number, size-10
In this we have two types
1- BVA (Boundary value analysis)
2- ECP ) Equivalent class partition)

BVA (Boundary value analysis)

We are checking the size/length of data passing in the
object.
 In BVA we are going to check how our system is functioning
or working when we insert a boundary value.
Formula for BVA – Min,Max, Min-1,min+1,max-1,max+1
Eg. Password text box accept 4 to 8 char value
Object Passing Criteria Fail Criteria
Text box 4 char no pass
Text box 8 char no pass
Text box 3 char no fail
Text box 5 char no pass
Text box 7 char no pass
Text box 9 char no fail

ECP (Equivalent Class portion)

In ECP we are going to define the data types which we are
passing into object.
Eg.
Passing criteria Fail criteria
Mobile number Int(0-9) A-Z,a-z, Special
(Text box) char
4-8 char text box A-Z, a-z 0-9, special char

What is Decision Table?

A decision Table is the tabular representation of several input
values, Cases, rules and test conditions. Through this table we
can check and verify all possible combinations of testing
conditions.
Eg. We will create the decision table for a login screen that
asks for userid and password. The conditions here bis that user
will be redirected to homepage if he enters thr correct
username and password. And an 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 (Login) is displayed
Conditions Rule1 Rule2 Rule3 Rule4
Username W C W C
C/W
Password W W C C
C/W
Output E/H E E E H
Error Handling Coverage/Testing
In this testing we will be validating/checking by passing
invalid test data that that system is showing error
message or not.
Eg .Payment tab – Debit card

Debit card number

Exp date

CVV
SUBMIT

By passing invalid card number – Error message – Please

provide valid debit card number
Keeping the debit card field blank – Please provide debit
card number

Backend Coverage/testing
In this we will be validating /checking whatever operations
has been performed on front end the same thing is stored
in backend or database or not.
Eg. SIP

Service Level coverage/testing

In this we are going to check the sequence and functions
of module on the basis of functional flow diagram. We
check working of system as per functional flow diagram or
not.
Calculation based coverage/testing :
We arithmetic operations , it includes addition,
multiplication, division and subtraction.

Non-Functional testing :
Validating or checking the external functionality of the
application or how your application is interacting with other
application.
Types of Non-Functional testing
1- Recovery testing.
2- Compatibility testing.
3- Configuration testing.
4- Intersystem system.
5- Installation Testing.
6- Parallel testing.
7- Sanitation testing/Garbage testing.
8- Globalization testing.

1-Recovery Testing
It is a testing which verifies software ability to recover
from failures like software/hardware crashes , network
failure, etc.
Process of checking the 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. Downloading

2-Compatibility testing
It is Testing to check whether our software is capable to
run on different OS, Network environment or mobile
devices.
Types of compatibility testing
A- Forward compatibility
B- Backward compatibility
Forward Compatibility testing
Build is correct but our OS or browser is not working
properly then it is a forward compatibility.
Backward compatibility Testing
I have worked in Backward Compatibility testing.
In Backward compatibility testing I have worked in
Browser compatibility testing.
Browser Compatibility testing are of two 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, Android, Iphone and Ipad
etc

2- Version Comparison Compatibility testing

In this we will be validating the different version of
same browser is supporting our build or not.
Eg . Chrome browser with different version

3-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(Ipad, Iphone) , Printer,
etc

4-Inter-System Testing
It is the process of checking or Validating whether our
application shares data with other application or not.
Eg.
Paytm Airtel Recharge

5-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
expectations.

6-Parallel testing
 Parallel Testing is the is the testing where various
components of the application are runned parallel to
reduce the time.

7-Sanitation / Garbage Testing

Validating or checking the extra features added by
developer but not present in SRS Document. The
testing which will be perform on that extra feature is
called as Sanitation testing.
Eg. Mobile number –
+91

Amount –
$

8-Globalization Testing
It is a process of checking whether our application
supports different languages or not.
It includes
1- Localization testing
In this we are going to check whether our application
supports local language or not.
Eg. Marathi, Hindi
2- Internationalization
In this we are going to check whether our application
supports international language or not.
Eg, Japanese, French, Spanish 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 or not.

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

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 original form.

Performance testing
Performance testing is termed as type of software testing
to ensure that software applications 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 on software for a particular
time period.
3-Stability
It helps to know that the software is stable under the
fluctuating loads.
4-Reliability
It checks whether the software can perform fault free task
for a given period of time in a specified environment.

UAT (User Acceptance testing)

1- UAT testing is 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 client or
End user to verify/accept the software application before
moving the software to the 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 testing is performed on remote Desktop.
7- UAT is a type of testing which is done by the customers
before accepting the final product.
Need of User Acceptance testing
1- To check whether the application meets customers
requirement as per his expectations.
2- Developers have included features on their own
understanding.
3- Requirement changes not communicated effectively to the
developer.
Prerequisites of User Acceptance Testing
1- Business requirements must be available.
2- Application should be fully developed.
3- Unit testing, Integration testing and System testing
should be completed.
4- Only cosmetic error is acceptable before UAT
(cosmetic error – Spelling mistake , Background color of a
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 Dev and In Beta testing dev and
 testers are present testers are not available
immediately.
Alpha testing ensures the Beta testing also
quality of the product before concentrates on the quality of
forwarding it further. the product but collects the
user input on the product and
ensures that the product is
ready for real time users.
Alpha testing requires a Beta testing doesn’t requires
testing environment a testing environment
Alpha testing may Require a Beta testing requires only a
long execution cycle. few weeks of execution.
In Alpha testing critical issues Most of the issues or
can be immediately identified feedback collected from beta
and fixed. testing will be implemented
in further versions of the
product.

Production Issue
If we found a issue /defect in production it s called as
production issue.
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- Reproduce the defect – Checking in all environments or
checking we are using the same software and hardware
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 root 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 a testing to test the application with
random I/P or O/p to check whether application is
crashing or not.
2- It is a 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 conducting testing on high
priority test cases and core functionality of the application.
Eg. In my project – payment tab – UPI module added-
User story - 100 test cases for execution in 2hrs
PM will say execute the test cases in 2hrs- Tester will say
I will be performing monkey testing.

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

Ad-hoc Testing :
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.
As per our previous experience about the module or
functionality of the application Ad-hoc testing will be
performed.

Severity and Priority

Severity –
1- The impact of the bug on the application where its
functionality gets break is known as severity.
 Where functionality gets break it is known severity.
Eg. Signup button not working.
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 testing.
Eg. Login button is not working
Major – It 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 interruption.
Eg. UI defect

Priority
Priority 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
Medium – In this , the problem should be fixed before the
release of the current version in development.
Eg. Search Tab
Low - The flow 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 cases, the
severity type of a defect is set by the tester based on the
product functionality and the written test cases. The priority is
decided by the Product owner on Customer requirement.
1- High Severity and High Priority
Eg. Payment tab not working, Login button not clickable

2- High Priority and low severity

Eg. Bank logo is not correctly present

3- Low priority and High Severity

Eg. Download button, Print button

4- Low priority and Low severity

Eg. Sequence flow, Help and support tab not working

Difference between error, bug, 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.

END