Software Testing

• What is Software?
Software is a series of instructions for the computer that perform a particular
task, called a program.

Or simply we can say Software is a collection of specialized programs.

E.g. Excel,Word,Amazon, What's App, Banking Application,CRM etc.

• What is Software Testing?
Software Testing is a method to check whether the actual software product
matches expected requirements and to ensure that software product is Defect free.

Software Testing is a process of executing the application with the intent of finding
the defects by comparing the output behavior of the application with expected
behavior (requirement).

In other words it’s comparing the actual behavior of an application with expected
behavior.

There are two approaches to test the application.

1. Manual Testing
2. Automation Testing
• Why is Software Testing is important?

Humans make mistakes all the time!!

• We humans can’t identify our mistakes in a work done by us. We should get
someone else to check our work because another person may identify the
mistakes done by us.
• In the same way software developers may not identify the mismatches in a
program or application implemented by them which can be identify by the
another department called Software Testing team.
• Why is Software Testing is important?
Testing is important because software bugs could be expensive or even dangerous.
Software bugs can potentially cause monetary and human loss, and history is full of
such examples.

• In April 2015, Bloomberg terminal in London crashed due to software glitch

affected more than 300,000 traders on financial markets. It forced the
government to postpone a 3bn pound debt sale.
• Nissan cars recalled over 1 million cars from the market due to software failure in
the airbag sensory detectors. There has been reported two accident due to this
software failure.
• Starbucks was forced to close about 60 percent of stores in the U.S and Canada
due to software failure in its POS system. At one point, the store served coffee for
free as they were unable to process the transaction.
• What are the benefits of Software Testing?

Software testing helps in finalizing the software application against business

requirements.
Software testing makes sure that the testing is being done properly and hence the
system is ready for the customers to use.

Below are few benefits of software testing.

• To Prevent defects
• Finding the defects before delivery
• Gaines the confidence about quality
• Ensure the requirements are delivered to client
• What is Software Quality?
Software quality is nothing but delivering a bug free application and delivered on time
with all requirements.

Software should:
1. Meet Customer requirements
2. Cost to Purchase (Economical)
3. Time to Release (Timely Release of it)

SQA: The Monitoring & Measuring the strength of development process is called SQA
(Software Quality Assurance).

SQC: The Validation of final product before release to the customer is called SQC
(Software Quality Control).
• What is Project Vs Product?
Project is developed for a single customer on his own requirements by the software
companies and the project will be used by the customer only.

Product is developed for multiple customers on their consolidated requirements by

the software companies and the product will be used by all customers.

• What is Defect?
A defect is a deviation or mismatch from the requirements.
When actual result deviates from the expected result while testing a software
application or product then it results into a defect.
Software Development Life Cycle (SDLC)
Software Development Life Cycle is a systematic approach to develop software. It is a Process
followed by Software Developers and Software Testing is an integral part of Software Development,
so it is also important for Software Testers.
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test software. The SDLC aims to produce a high-quality software that meets or exceeds
customer expectations, reaches completion within times and cost estimates.
Why Software Development Life Cycle is important?
SDLC ensure success in process of software development.
• Phases of Software Development Life Cycle
1. Initial/(Requirement Gathering)
2. Requirement Analysis- SRS
3. Design
4. Coding
5. Testing
6. Delivery & Maintenance
1. Initial(Requirement Gathering):
• Requirement Gathering is the most important phase in software development life
cycle, Business Analyst collects the requirements from the Customer/Client as per
the clients business needs and documents the requirements in the Business
Requirement Specification and provides the same to Development Team.
• Note: Document name may vary from one Organization to another, Some
examples are Customer Requirement Specification (CRS), Business Requirement
Document (BRD) etc
• Suppose Our Planned Software is not intended for a single customer and the
software product for multiple customers then Business Analyst or Business Team
collects Requirements from the Market and also evaluate Other similar products
in the Market
• Key Role in this phase is Business Analyst and Outcome of the phase is "Business
Requirement Specification"
2. Analysis
Once the Requirement Gathering is done the next step is to define and document
the product requirements and get them approved by the customer. This is done
through SRS (Software Requirement Specification) document. SRS consists of all the
product requirements to be designed and developed during the project life cycle.

Key people involved in this phase are Project Manager, Business Analyst and Senior
members of the Team. The outcome of this phase is Software Requirement
Specification.
3. Design
• In Design phase Senior Developers and Architects, they give the architecture of
the software product to be developed. It has two steps one is HLD (High Level
Design) or Global Design and another is LLD (Low Level Design) or Detailed
Design,
• High Level Design (HLD) is the overall system design, covers the system
architecture and database design. It describes the relation between various
modules and functions of the system.
• Low Level Design (LLD) is the detailed system design, covers how each and every
feature in the product should work and how every component should work.
• The outcome of this phase is High Level Document and Low Level Document
which works as an input to the next phase Coding.
4. Coding
• Developers (seniors, juniors and fresher) involved in this phase, this is the phase
where we start building the actual software and start writing the code for the
product.
• The outcome of this phase is Source Code Document and the developed product.

5. Testing
• Once the software is complete then it is deployed in the testing environment. The
testing team starts testing (either test the software manually or using automated test
tools depends on process defined in STLC)
• Testing is done to verify that the entire application works according to the customer
requirement.
• During this phase, Testing team may find defects which they communicate to
developers, the development team fixes the defect and send back to Testing for a re-
test. This process continues until the software is Stable, and working according to the
business needs of that system.
6. Delivery (Deplymement) & Maintenance
After successful testing, the product is delivered (deployed to the customer for
their use), Deployment is done by the Deployment/Implementation engineers or
delivery manager and Once when the customers start using the developed system
then the actual problems will come up and needs to be solved from time to time.
Fixing the issues found by the customer comes in the maintenance phase. 100%
testing is not possible – because, the way testers test the product is different from
the way customers use the product. Maintenance should be done as per SLA
(Service Level Agreement)
Software Organization Hierarchy Structure

AM

DM

BA

PM(Dev)
PM(Testing)

PL
PL

TL TL TL TL

Develpoers Devolopers TE’s TE’s

Fish Model

It defines SDLC, I mean it defines what is SDLC?

Fish Model
R
• BRS -Business Requirements Specification E
• SRS -Software Requirements Specification V
I
• HLD -High-Level Design E
W
• LLD - Low-Level Design s

• Coding ----- White Box Testing

• Testing ----- Black Box Testing
• Maintainance ----Testing Sw changes
BRS -Business Requirements Specification

The BRS defines the requirements of customer to be developed.

This Doc developed by BA people
It acts as bridge between customer and technical people.

Customer BRS Dev and Testing Teams

Eg.
Dual Sim-- 2 sims in single device.
ATM Machine – user should withdraw money.
SRS -Software Requirements Specification

• This doc defines with respect to BRS.

• The SRS defines the functional requirements to be developed and the system
requirements to be used.
• 1 BRS consists multiple srs’s.
• Eg.
• BRS---ATM Machine – user should withdraw money.
• SRS– Magnatic tapes,ATM card, Pin code
Q. Do u aware about SRS?-- Interview
Q. Where did u get SRS doc from? From BA and upload it into sharepoint
What SRS consists?
1.Functinal Req 2 Use case 3 Snapshot 4. Fun flow diag
Q. Where do u get snapshot?---snipping tool
Q. Which tool is for taking snapshots?
Design
• Pictorial representation of the project/Software to be developed.
HLD: -
The HLD documents defined the overall architecture of the system.
The below overall design is also known as Architectural Design / External Design
LLD: - the LLD documents define the internal structure of every module or
Functionality.
Reviews
• A document level testing technique during this review, the responsible
people are estimating the completeness & correctness of corresponding
Document
There are different kind reviews for validate above BRS SRS and Design documents.
1. Walkthrough
In this review system, responsible people Study a document from 1st line to last line
2. Inspection
Search for a specific issue in a document (Without Intimation).
3. Peer Review
Compare a document with other similar document
4. Informal Review
It doesn't follow any process to find out any defects in document. In this review, they just review
and give informal comments.
5. Technical Review
Fun specifications will be reviewed and checked whether it is suitable to product.
Reviews in BRS/SRS
1. Are they Right Requirements?
2. Are they Complete Requirements?
3. Are they Achievable Requirements?
4. Are they Reasonable Requirements?
5. Are they Testable Requirements?

Reviews in Design
After completion of Analysis & their reviews the designer category
people develops HLD & LLD’s are conducts reviews on the documents for completeness & correctness.
The designers prepare these questions on the HLD & LLD’s.
6. Are they understandable designs?
7. Are they meeting the right requirements?
8. Are they complete designs?
9. Are they followable designs?
10. Are they handling errors?
 Coding

After completion of design & their reviews, the programmers start coding.
Coding is set of software program written by development team to construct a physical software.
What is Program
Program: - A set of executable statements is called a program. Software consists of multiple programs. A
program consists multiple statements.
In this phase, the programmers prepare programs & then test each program using
White Box Testing Techniques.
White Box Testing
It is coding level testing technique used to check completeness and correctness of program.
• A program level testing technique. In this technique, the responsible people are verifying the internal
structure of the corresponding program. i.e developers
• White Box Testing techniques are also known as Unit Tesing/Open Box Testing / Glass Box Testing / Clear Box
Testing
Q. Did you involved in WBT/Unit Testing?
No, Amit. I didn’t got chance to work in WBT/Unit Testing.
 White Box Testing
There are 4 White Box Testing Techniques:
1.Basis Path Testing
2.Control Structure testing
3.Program technique Testing
4.Mutation Testing
These Techniques are applicable only for Programs.
1.Basis Path Testing:
During this test the programmers concentrate on the execution of
programs without any runtime errors. To conduct this test, the corresponding
programmer follows the below approach.
Write a program with respect to LLD (Low Level Design)
Draw a flow graph for that program.
Run that program more than one time to cover all areas.
Eg If Else program….This program should be run 2 times executable.
° One time to check whether if condition is satisfied or not
° Next time to check whether the else condition is satisfied or not, without any runtime errors.
2. Control Structure Testing:
During this test, the corresponding programmer concentrates on
correctness of program execution in this test, they verify every statements of
program execution. In this test, they verify every statements input state & Output
state.
Eg: Debugging

3. Program Technique Testing:

During this test, the programmers concentrate on the execution
speed of a program. If the execution speed is not reasonable, then programmers
perform changes in the structure of the program without disturbing functionality
of the program.

4. Mutation Testing:
During this test, the corresponding programmers estimate completeness & correctness of a program
testing. Total req, successful and failed req
Testing
Testing is done to verify that the entire application works according to the customer requirement.

Black Box Testing

This is build level testing technique.

During this testing, test engi validates the internal fun with resp to external interface.
Also known as ‘System and Functional testing’.
Tester doesn’t need to know about internal code written by developer.

Functional Testing and Non functional testing

Functional Testing
1. Behavioral Coverage
2. Input domain Coverage(BVA And ECP)
3. Error handling Coverage
4. Service level Coverage
5. Calculation Based Coverage
6. Backend coverage / Database Testing
Non Functional
1. Compatibility testing
2. Parallel Testing
3. Installation testing
4. Globalization testing
5. Security Testing
6. Performance Testing
7. Sanitation Testing
8. Recovery Testing
Maintenance
After successful testing, the product is delivered (deployed to the customer for their use), Deployment is done
by the Deployment/Implementation engineers and Once when the customers start using the developed system
then the actual problems will come up and needs to be solved from time to time.
Fixing the issues found by the customer comes in the maintenance phase. 100% testing is not possible –
because, the way testers test the product is different from the way customers use the product. Maintenance
should be done as per SLA (Service Level Agreement)
Static Testing Vs Dynamic Testing

• Static testing is verification testing technique where we test the requirement doc and design doc prior
to software being developed i.e. testing without giving any i/p.
• Testing is done before code developed.
• This done during analysis and design phase using reviews techniques.
• It is about prevention.
• Main objective of Static testing is to improve the quality of software product by finding errors in early
stages of development cycle.
• Also known as ‘Non execution testing’ or ‘Verification Testing’.

• Dynamic testing is validation testing where we test the developed software i.e. testing with i/p and
checking the expected results.
• Testing is done after code developed.
• This testing done by white box testing or black box testing.
• It is about Cure.
• Main Objective Dynamic testing Software product work as per business requirements.
• Also known as ‘Execution Testing’ or ‘Validation Testing’.
Verification and Validation
• These both testing techniques are to check that software product is meeting the customer
requirements.
• Static Testing ---Verification
• Dynamic Testing– Validation
• Verification + Validation---SDLC
• Verification– Quality Assurance
• Validation- Quality Control

Difference between Static and Dynamic Testing

Difference between Verification and Validation
Difference between WBT and BBT

What is Grey Box Testing?

We are not involved in this testing.
 Software Development life cycle models
1. Waterfall Model
2. V Model
3. Agile
Waterfall Model
I. Requirements Gathering
II. Requirement Analysis
III. System Design
IV. Coding/Implementation
V. Testing
VI. Deployment
VII. Maintenance

In a waterfall model, each phase must be completed fully before the next phase starts.
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It
works as ‘Locking Process’ means when BRS completed then starts SRS stage starts and so on.
It is very simple to understand and use. This type of model is basically used for the project which is small and
there are no uncertain requirements
Reqt
Gathering
• Advantages of waterfall model:
- This model is simple and easy to understand and use.
- It is easy to manage due to the strictness of the model
- In this model phases are processed and completed one at a time.

• Disadvantages of waterfall model:

- Once an application is in the testing stage, it is very difficult to go back and change in coding.
- Time Consuming
- High amounts of risk
- Not a good model for complex and object-oriented projects.
- Poor model for long and ongoing projects.

• When to use the waterfall model:

- This model is used only when the requirements are very well known, clear and fixed.
- The project is short.
V Model
• V stands for Verification & Validation( 3 months Duration for 1 release)
• This model defines the conceptual mapping in between Development stages & test I.e. in this model all development phases
can be integrated with Testing phases.
• Testing of the product is planned in parallel with a corresponding phase of development stages
• Multiple stages of Testing avoids defects multiplication
Development Phases Integration with Testing Phases
a) User Requirements Vs Acceptance Testing
Business Analyst category people gather requirements and the document the requirements, after documentation Reviews,
Meetings like verification will take place in order get correct & Complete Requirements.
End Users conduct Acceptance Testing using Business / User Requirements.
b) Software Requirements Vs System Testing
Development Manager/Tech Manager/BA converts User Requirements as Software Requirements and Reviews, Meetings like
verification methods will be performed on Software Requirements, after Verification Client provides Approval.
Independent testers create test cases/Test scenarios from Software Requirements in order to perform System Testing
C) Design Vs Integration Testing
System Architect / senior developer creates Global design, Informal Review/ Walk through / Technical Review / Inspection like
Verification methods will be applied on Design documents.
Developers/Testers( with resp to organization) perform Integration Testing based on Software Global Design.
D) Coding Vs Unit / WBT
Developers perform Unit /Component Testing based on Software Detailed Design
Advantages of V Model:
a) Tester role will take place in the requirement phase itself.
b) Multiple stages of Testing available so that Defects multiplication can be reduced.
c) Can be used for any type of requirements

d) Due to Multiple stages of Testing and Multiple teams involvement Quality can be improved .
Disadvantages of V Model:
a) It an expensive model than Waterfall model, needs lot of resources, budget and time.
b) Co-ordination and Maintenance are difficult.
c) Adoption of changes in Requirements and Adding New Requirements at middle of the process are difficult.
d) It needs an established process for proper implementation
V Model
 Agile Methodology

AGILE methodology is a practice that promotes continuous iteration of development and testing
throughout the software development lifecycle of the project.
It’s not a plan driven, it’s a value driven process.
Requirement may comes at any stage of SDLC and In agile it will accept.
I mean, Frequent changes in requirements will not impact on development, testing and production in
agile.
Any stage of SDLC, reqmt may come in agile, we have to accept that reqmt and fulfill it without any
extra charges.
The main Agile methodologies are:
• Scrum
• Kanban
• XP (Extreme Programming)
• FDD (Feature Driven Development)
• AUP (Agile Unified Process)
Scrum Architecture
Meetings In Agile
• Sprint Planning Meeting
• Daily Stand Meeting
• Sprint Review Meeting
• Sprint Retrospective/Agile Grooming Meeting
Advantages of Agile model:
- Customer satisfaction by continuous delivery of software.
- Customers, developers and testers constantly interact with each other.
- Working software is delivered frequently
- Continuous attention to technical excellence and good design.
- Even late changes in requirements are welcomed
Disadvantages of Agile model:
- It is difficult to assess the effort required at the beginning of the software development life cycle.
- The project can easily get taken off track if the customer representative is not clear what final
outcome that they want.
- Only senior programmers are capable of taking the kind of decisions required during the
development process.
- If requirements are complex.
When to use Agile model:
- New changes can be implemented at very little cost
- To implement a new feature the developers need to lose only the work of a few days.
- Unlike the waterfall model in agile model very limited planning is required to get started with the project .
 Software Testing Levels
Unit Testing
• In Unit Testing level individual units/ components of a software are tested. The purpose is to validate that each unit of the
software works as designed .
• Developers conduct Unit Testing using White Box Test Design Techniques
Integration Testing-
• In Integration Testing Level, individual units are combined and tested as a group. The purpose of this level of testing is to
expose faults in the interaction between integrated units.
• Independent Testers and develpors conduct this level of Testing
• After completion of WBT and its review, developers integrate all the dependent modules to form an application/system with
respect to HLD and LLD.
• Developers and testers both will be involved in IT.
• Developers do integration of all the modules and testers perform testing on that integrated application.

There are 3 approaches of Integration t esting

1. Top-Down Approach
2. Bottom-Up Approach
3. Hybrid Approach
1. Top down Approach
The interconnection of the main program & some sub-programs is called the Top-Down Approach.
Programmers use temporary programs called stubs instead of sub-programs, which are under construction or withn other
organization.
The other name for stub is ‘Called Programs’.

In this Approach first Parent Modules are developed

After that Child Modules are developed
Then interconnect Parent & Child Modules.
• Top Down Approach
Submodule1(IBM)

Stub1

Submodule2(Infy)
Stub2
Main Module(TCS)

Stub3
Submodule3(Accentur
e)
Top Down Approach
• In this Approach, submodules are not present with us.
• Either they are with other organization or under construction.
• For above conditions, to test the interdependent module we need to use ‘Stub’.
• Stub is temporary program to test the main module while submodule is in under construction or its with other org.
• It is developed by Developers.
• Mostly it is in XML format.
• We call it as WSDL file---Web service description language
• Bottom Up Approach
• The interconnection of internal sub-programs without using main programs is called the bottom up approach.
• In this approach, programmers use a temporary program instead of main program, which is under construction.
• The temporary program is called Driver or Calling Program

*In this approach first Child Modules are developed.

* After that parent modules are developed
* Then interconnect Child Modules with Parent Modules.
* In the interconnection Process is there any main module is under construction
then the developers create temporary program that is called Driver.
• Bottom Up Approach
Submodule1(IBM)

Driver1

Submodule2(Infy)
Driver2
Main Module(TCS)

Driver3
Submodule3(Accentur
e)
Bottom Up Approach
• In this Approach, Mani modules are not present with us.
• Either they are with other organization or under construction.
• For above conditions, to test the interdependent module we need to use ‘Driver’.
• Driver is temporary program to test the Sub module while main module is in under construction or its with us.
• It is developed by Developers.
• Mostly it is in XML format.
• We call it as WSDL file---Web service description language
3.Hybrid Approach:
Also known as Sandwich approach, this is a combination of the Process Top-Down Approach & Bottom-Up Approaches.
• Difference Between Stub And Driver
• System Testing
• In System Testing level a complete and integrated software is tested. The purpose of this test is to evaluate the system’s
compliance with the specified software requirements
• After completion of integration testing, a separate testing team receives a software build from the development team. This
team a set of block box testing techniques to validate that software build.
• Independent Testers conduct System Testing using Black Box Test Design Techniques
• Acceptance Testing-
• In Acceptance Testing level a software system is tested for acceptability. The purpose of this test is to evaluate the system’s
compliance with the business requirements
• Here, Acceptance basically two types,
• 1) Internal Acceptance Testing (Alpha Testing): It is conducted by technical people from client side/Sr. testers and done in
development environment.
• 2) External Acceptance Testing / User Acceptance Testing (Beta Testing) is conducted by the end users of the software in client
side environment.
• Note: Acceptance Testing environment and System Testing environment almost all same, but Unit Test Environment and
integration Test environment are different
 Entry Criteria and Exit Criteria
Unit testing
Entry criteria of Unit testing --Complete the coding
Exit criteria for Unit testing --Unit testing should be completed

Integration testing
Entry criteria—Unit Testing Completed
Exit criteria----Integration testing is completed

System Testing ---

Entry criteria—Integration Testing Completed
Exit criteria---- System testing is completed

Acceptance Testing
Entry criteria— System Testing Completed
Exit criteria----Acceptance testing is completed
• Usability Testing-GUI Testing
• BBT - Functional/Non Functional
• Performance
• Security
GUI Testing(Usability Testing)
GUI Stands for Graphical User interface testing
During this testing, test engi needs to validate user friendliness of an application/screen/build.
1. Ease of use
2. Look and feel
3. Speed of processing
• Functionality testing
A Moderator testing level during which the testing team concentrates on customer requirements interms of
functionality.

1. Functional Testing
Behavioral Coverage
(Changes in Properties of Objects in Screen)
Error Handling Coverage
(Preventing incorrect Operations)
Input Domain Coverage
(Taking correct size & type of Inputs)
Backend Coverage(Database Testing)
(The Impact of front-end screens operations on backend tables)
Service level coverage (Order of functionalities)
Calculation coverage
Behavioral Coverage
Changes in Properties of Objects in Screen.
• Objects Properties
• Textbox/ Textfield Focused/Unfocused
• Radio Button on/off
• Button Enable/ disable
• Check box checked/unchecked
• Dropdown list box select/deselect multiple items/choices
• Dropdown combo-box select/deselect single item/choice

• Error Handling Coverage

Preventing incorrect Operations
• Input Domain Coverage
Taking correct size & type of Inputs. Applicable for textbox only.
1) Equivalence Class Partitioning (ECP) / Equivalence Partitioning(EP)
• It can be applied at any level of testing (Unit, Integration, System and Acceptance Testing)
• In Equivalence Partitioning, inputs to the Software are divided into groups that are expected to exhibit similar behavior.
• Equivalence Partitions/Classes can be found for both valid data and invalid data.
Example 1 (Data Type): Mostly Used technique in ECP
• Customer Identification Number field in a CRM system accepts only numbers.
Partition 1 Partition 2 Partition 3 Partition 4 Partition 5 Partition 6
Alpha bytes Numbers Special Characters Alpha-numeric Blank Decimal
(Invalid) (Valid) (Invalid) (Invalid) Invalid Invalid
Example 2 (Others)
A Payment management system accepts credit card payments only
Partition 1 Partition 2 Partition 3
Credit card Net Banking Cash on Delivery Debit card
(Valid) (Invalid) (Invalid). (Invalid).
2) Boundary Value Analysis (BVA)
• The maximum and minimum values of a partition are its boundary values.
• Behavior at edge of each equivalence partition is more likely to be incorrect than behavior within the partition.
• Boundary value analysis can be applied at all Test levels(Unit, Integration, System and Acceptance Testing).
Example 1: Partition 1 Partition 2 Partition 3
11 to 99

Min-11---Pass/Valid
Max-99—Pass/Valid
Min+1-12----Pass/Valid
Max-1-98---Pass/Valid
Min-1-10---Failed/Invalid---Defect
Max+1-100– Failed/Invalid---Defect
Example 3 (Data Size)
Phone Number filed accepts 10 digits number only
Partition 1 Partition 2 Partition 3
Below 10 10 Above 10
(Invalid) (Valid) (Invalid)
Min-10
Max-10
Min-1-9
Max+1-11
Max-1=9--
Min+1--11
Example: User Id field accepts 10 to 20 characters and it should accepts alphaNum values.
ECP
Albhabetes---Valid/Pass
Numbers—Valid
Alpha+Numbers—Pass
Special char—Invalid
Alpha+Special Char---Invalid
Numbers+Special Char--- Invalid
Alpha+Numbers+Special Char - Invalid
Blank---Invalid
BVA
Min- 10
Max-20
Min-1-9
Max-1-19
Min+1- 11
Max+1- 21
Service level coverage
Validate Order of functionalities of an application.

Calculation coverage
Validation with respect to arithmetic calculation.

Price=200

Qty= 5

Total= 1000
• Non-Functional Testing:
A complex level in system testing during which the testing team concentrates on extra characteristics of the
software.
i. Recovery Testing/Reliable Testing
ii. Compatibility Testing/Portability Testing
iii. Configuration Testing/Hardware Compatibility Testing
iv. Inter system Testing
v. Installation Testing
vi. Sanitation /Garbage Testing
Vii . Globalization Testing
viii. Parallel Testing
Recovery Testing/Reliable Testing
Recovery testing also called as reliable testing
During this testing we have to validate weather our application recover from abnormal situation to normal situation .
Eg:- Transaction (ATM)
Abnormal situation:-
1. System Crash
2. Server Down
Que:- do you have involved in recovery testing ?
➔ Yes I have involved in recovery testing recently A & application B share the same database.
Requirement is two application share common database --

A B

DB
 Recovery Testing/Reliable Testing

• To test this application condition are :

1.req of application A should be successfully executed .
2. req of application A is under process & req of application B come then it has to wait for 2 min .
3.If req of application A testing taking more than two min time then req of application A should be terminated.
4. req of application B should be successfully executed .
5. Requirement of application B is under process and requirement of application A come then it as to wait for 2 minute.
6. Requirement of application B testing more than 2 minutes time then requirement of application B should be terminated.
7. Requirement of application A= requirement of application B come exactly on same time then by FIFO requirement of
application A process first.
8. Requirement of application A & requirement of application B come on some time then requirement of B processed this
waiting time of 2 minutes is considered as recovery time.
Compatibility Testing/Portability testing:

Compatibility testing also called as Portability testing.

During this testing , test engineers validates that whether an application works on different platform or not.
There are two type of compatibility testing :

1) Forward compatibility : when build /application is ok and problem with OS or browser is called ‘’Forward compatibility’’.
2) Backward compatibility:
---OS or browser is ok but problem with application or build is called as ‘’backward campability’’.
---In generated test engg find maximum defects in backward capability.
Que: Do you involved in compatibility testing ?
→ Basically I was involved in Backward Compatibility Testing.

Browser Compatibility Testing is divided in two types.

1) Cross browsing: we are going to validate the application on different browsers as per reqmt.
Eg :- Edge vs Mozilla , Edge vs chrome , chrome vs mozilla.
Compatibility Testing/Portability testing:

2) Version Comparison: we are going to validates the application on different version of same browser/Os .
Eg: Chrome 96 vs Chrome 98
Performance Testing
• Load Testing
• Stress testing
• Data Volume Testing
• Endurance Testing
Validate the Speed of processing of an application
Load Runner
Jmeter

1. No of users
2. wrong logic by front end developer or backend/db developer

Object elapsed time---Trace file/log file---25sec < 5 sec

Security Testing

• Authorization
• Access Control
• Encryption/Decryption

UserA
UserB
Testing Terminologies
• Monkey Testing
• Exploratory Testing
• Ad Hoc Testing
• Defect Seeding/Debugging
• Big Bang Approach
Defect Leakage
• After the delivery of application or product or we can say after the release, if end user or
Customer find any defect by using that application then it is called defect leakage, it is
also called bug leakage.

• Defect Leakage is the metric which is used to identify the efficiency of the QA
testing i.e., how many defects are missed/slipped during the QA testing.
Defect Leakage = (No. of Defects found in UAT / No. of Defects found in QA
testing.)

Defect Efficiency- = (No. of Defects found in UAT / No. of Defects found in QA

testing) * 100
Defect Efficiency= 10/100*100= 10% or less than 10% we can call it as good
defect efficiency.