JAI ENTERPRISES

SOFTWARE TESTING

Software
Software is a set of instructions, data or programs used to operate computers and
execute specific tasks.

Application software. The most common type of software, application software is a

computer software package that performs a specific function for a user, or in some
cases, for another application.
graphics software, databases and database management programs, web browsers,
word processors, software development tools, image editors and communication
platforms.
System software. These software programs are designed to run a computer's
application programs and hardware. System software coordinates the activities and
functions of the hardware and software.
The OS is the best example of system software; it manages all the other computer
programs.
The OS is the best example of system software; it manages all the other computer
programs.

Driver software. Also known as device drivers, this software is often considered a
type of system software. Device drivers control the devices and peripherals connected
to a computer, enabling them to perform their specific tasks. Every device that is
connected to a computer needs at least one device driver to function. Examples
include software that comes with any nonstandard hardware, including special game
controllers, as well as the software that enables standard hardware, such as USB
storage devices, keyboards, headphones and printers.

Middleware. The term middleware describes software that mediates between

application and system software or between two different kinds of application
software. For example, middleware enables Microsoft Windows to talk to Excel and
Word. It is also used to send a remote work request from an application in a computer
 JAI ENTERPRISES
that has one kind of OS, to an application in a computer with a different OS. It also
enables newer applications to work with legacy ones.

Programming software. Computer programmers use programming software to write

code. Programming software and programming tools enable developers to develop,
write, test and debug other software programs. Examples of programming software
include assemblers, compilers, debuggers and interpreters.

What is Testing
Testing is the process of determining how effective something is.

What is Software Testing

Software testing is a process, to evaluate the functionality of a software
application with an intent to find whether the developed software met the
specified requirements or not and to identify the defects to ensure that the
product is defect-free in order to produce a quality product.

Let’s see the standard definition, testing types such as manual

testing and automation testing, testing methods, testing approaches, and
types of black-box testing.

What are the different types of Software

Testing?

#1. Manual Testing

Manual testing is the process of testing the software by hand to learn more
about it, to find what is and isn’t working.
This usually includes verifying all the features specified in requirements
documents, but often also includes the testers trying the software with the
perspective of their end user’s in mind.
Manual test plans vary from fully scripted test cases, giving testers detailed
steps and expected results, through to high-level guides that steer
exploratory testing sessions.
There are lots of sophisticated tools on the market to help with manual
testing,
 JAI ENTERPRISES
#2. Automation Testing
Automation testing is the process of using automation testing tools to
control the execution of tests and compare the results against expected
outcomes and to find the defects.
In this process, testers execute the test scripts and generate the test
results automatically by using automation tools.
Some of the famous automation testing tools for functional testing include
Selenium, testRigor, and Katalon Studio.
Selenium is no longer a strange name for web application testers. It offers
powerful capabilities like cross-browser testing but is difficult to learn for
those new to automation or with limited programming experience.
That’s why most QAs freshers and manual testers start out with Selenium
Alternatives.
testRigor is one of the best alternatives to selenium.

WHAT IS SOFTWARE QUALITY

Portability: A software device is said to be portable, if it can be freely made to

work in various operating system environments, in multiple machines, with other
software products, etc.

Usability: A software product has better usability if various categories of users

can easily invoke the functions of the product.

Reusability: A software product has excellent reusability if different modules of

the product can quickly be reused to develop new products.

Correctness: A software product is correct if various requirements as specified

in the SRS document have been correctly implemented.

Maintainability: A software product is maintainable if bugs can be easily

corrected as and when they show up, new tasks can be easily added to the
product, and the functionalities of the product can be easily modified, etc.

A product is anything that can be offered to a market to solve a problem, or to satisfy a

want or need. Products have a cycle that consists of multiple stages. First, the product is
conceived, then developed, then introduced and managed in the market, and finally, the
product is retired when the need for it diminishes. Products are usually developed by a
product team.

A project is a temporary endeavor that is undertaken to create a unique product or

service. With a project, there is a clear definition of what needs to be delivered by a
 JAI ENTERPRISES
specified date in time. As in the previous item, projects are usually carried out by a project
team.

Software testing is very important because of the following reasons:

1. Software testing is really required to point out the defects and

errors that were made during the development phase

o Example: Programmers may make a mistake during the

implementation of the software. There could be many reasons
for this like lack of experience of the programmer, lack of
knowledge of the programming language, insufficient
experience in the domain, incorrect implementation of the
algorithm due to complex logic or simply human error.

2. It’s essential since it makes sure that the customer finds the
organization reliable and their satisfaction in the application is
maintained.

o If the customer does not find the testing organization reliable

or is not satisfied with the quality of the deliverable, then they
may switch to a competitor organization.

o Sometimes contracts may also include monetary penalties

with respect to the timeline and quality of the product. In
such cases, if proper software testing may also prevent
monetary losses.

3. It is very important to ensure the Quality of the product. Quality

product delivered to the customers helps in gaining their
confidence

o As explained in the previous point, delivering good quality

product on time builds the customers confidence in the team
and the organization.

4. Testing is necessary in order to provide the facilities to the

customers like the delivery of high quality product or software
application which requires lower maintenance cost and hence
results into more accurate, consistent and reliable results.
 JAI ENTERPRISES
o High quality product typically has fewer defects and requires
lesser maintenance effort, which in turn means reduced costs.

5. Testing is required for an effective performance of software

application or product.
6. It’s important to ensure that the application should not result into
any failure because it can be very expensive in the future or in the
later stages of the development.

o Proper testing ensures that bugs and issues are detected

early in the life cycle of the product or application.

o If defects related to requirements or design are detected late

in the life cycle, it can be very expensive to fix them since this
might require redesign, re-implementation and retesting of
the application.

7. It’s required to stay in the business.

o Users are not inclined to use software that has bugs. They
may not adopt a software if they are not happy with the
stability of the application.

o In case of a product organization or startup which has only

one product, poor quality of software may result in lack of
adoption of the product and this may result in losses which
the business may not recover from.

What is a bug?
In software testing , a bug is the informal name of defects, which means that
software or application is not working as per the requirement. When we have
some coding error, it leads a program to its breakdown, which is known as a bug.
The test engineers use the terminology Bug.

If a QA(quality analyst) detect a bug, they can reproduce the bug and record it
with the help of the bug report template.
 JAI ENTERPRISES
What is a Defect?
When the application is not working as per the requirement is knows as defects.
It is specified as the aberration from the actual and expected result of the
application or software.

In other words, we can say that the bug announced by the programmer and
inside the code is called a defect.

What is Error?
The Problem in code leads to errors, which means that a mistake can occur due
to the developer's coding error as the developer misunderstood the requirement
or the requirement was not defined correctly. The developers use the
term error.

Why software has bugs

 Miscommunication of requirements introduces error in code
 Unrealistic time schedule for development
 Lack of designing experience
 Lack of coding practices experience
 Human factors introduces errors in code
 Lack of version control
 Buggy third-party tools
 Last minute changes in the requirement introduce error
 Poor Software testing skill
 JAI ENTERPRISES
The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

Business analyst and Project organizer set up a meeting with the client to gather
all the data like what the customer wants to build, who will be the end user, what
is the objective of the product. Before creating a product, a core understanding or
knowledge of the product is very necessary.

For Example, A client wants to have an application which concerns money

transactions. In this method, the requirement has to be precise like what kind of
operations will be done, how it will be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the
feasibility of the growth of a product. In case of any ambiguity, a signal is set up
for further discussion.

Once the requirement is understood, the SRS (Software Requirement

Specification) document is created. The developers should thoroughly follow this
document and also should be reviewed by the customer for future reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent
and document the software requirements and get them accepted from the
project stakeholders.
 JAI ENTERPRISES
This is accomplished through "SRS"- Software Requirement Specification
document which contains all the product requirements to be constructed and
developed during the project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements,
analysis, and design of the software project.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is
built. The implementation of design begins concerning writing code. Developers
have to follow the coding guidelines described by their management and
programming tools like compilers, interpreters, debuggers, etc. are used to
develop and implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to make sure
that the products are solving the needs addressed and gathered during the
requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance
testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is
deployed.

Then based on the assessment, the software may be released as it is or with

suggested enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues
come up and requirements to be solved from time to time.

This procedure where the care is taken for the developed product is known as
maintenance.

TYPES OF MODEL:-
 JAI ENTERPRISES
WATERFALL MODEL

 Requirement Gathering and analysis − All possible requirements

of the system to be developed are captured in this phase and
documented in a requirement specification document.
 System Design − The requirement specifications from first phase
are studied in this phase and the system design is prepared. This
system design helps in specifying hardware and system requirements
and helps in defining the overall system architecture.
 Implementation − With inputs from the system design, the system
is first developed in small programs called units, which are integrated
in the next phase. Each unit is developed and tested for its
functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the
implementation phase are integrated into a system after testing of
each unit. Post integration the entire system is tested for any faults
and failures.
 Deployment of system − Once the functional and non-functional
testing is done; the product is deployed in the customer environment
or released into the market.
 Maintenance − There are some issues which come up in the client
environment. To fix those issues, patches are released. Also to
enhance the product some better versions are released. Maintenance
is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases. The next phase is
started only after the defined set of goals are achieved for previous phase and it
is signed off, so the name "Waterfall Model". In this model, phases do not overlap.
 JAI ENTERPRISES
APPLICATION:-
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the
product.
 The project is short.

ADVATAGES:-
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well
understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

DISADVATAGES:-

 No working software is produced until late during the life cycle.

 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to
high risk of changing. So, risk and uncertainty is high with this process
model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't
allow identifying any technological or business bottleneck or
challenges early.

SPIRAL MODEL:-

Spiral Model
It implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of
incremental releases. During the early iterations, the additional release may be a
 JAI ENTERPRISES
paper model or prototype. During later iterations, more and more complete
versions of the engineered system are produced.

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of
purpose for that cycle, the various alternatives that are possible for achieving the
targets, and the constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate
these various alternatives based on the goals and constraints. The focus of
evaluation in this stage is located on the risk perception for the project.

Development and validation: The next phase is to develop strategies that

resolve uncertainties and risks. This process may include activities such as
benchmarking, simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice
made whether to continue with a further period of the spiral. If it is determined to
keep, plans are drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if

performance or user-interface risks are treated more essential than the program
development risks, the next phase may be an evolutionary development that
includes developing a more detailed prototype for solving the risks.
 JAI ENTERPRISES
The risk-driven feature of the spiral model allows it to accommodate any
mixture of a specification-oriented, prototype-oriented, simulation-oriented, or
another type of approach. An essential element of the model is that each period
of the spiral is completed by a review that includes all the products developed
during that cycle, including plans for the next cycle. The spiral model works for
development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.
o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages
o High amount of risk analysis
o Useful for large and mission-critical projects.

Disadvantages
o Can be a costly model to use.
o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

V-Model
V-Model also referred to as the Verification and Validation Model. In this, each
phase of SDLC must complete before the next phase starts. It follows a sequential
design process same as the waterfall model. Testing of the device is planned in
parallel with a corresponding stage of development.
 JAI ENTERPRISES

Verification: It involves a static analysis method (review) done without

executing code. It is the process of evaluation of the product development
process to find whether specified requirements meet.

Validation: It involves dynamic analysis method (functional, non-functional),

testing is done by executing code. Validation is the process to classify the
software after the completion of the development process to determine whether
the software meets the customer expectations and requirements.

So V-Model contains Verification phases on one side of the Validation phases on

the other side. Verification and Validation process is joined by coding phase in V-
shape. Thus it is known as V-Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product

requirements understood from the customer's side. This phase contains
detailed communication to understand customer's expectations and exact
requirements.
2. System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements
document.
 JAI ENTERPRISES
3. Architecture Design: The baseline in selecting the architecture is that it
should understand all which typically consists of the list of modules, brief
functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology detail, etc. The
integration testing model is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks down into
small modules. The detailed design of the modules is specified, which is
known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the
requirements, a suitable programming language is decided. There are some
guidelines and standards for coding. Before checking in the repository, the
final build is optimized for better performance, and the code goes through
many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during
the module design phase. These UTPs are executed to eliminate errors at
code level or unit level. A unit is the smallest entity which can
independently exist, e.g., a program module. Unit testing verifies that the
smallest entity can function correctly when isolated from the rest of the
codes/ units.
2. Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created and
tested independently can coexist and communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design
Phase. Unlike Unit and Integration Test Plans, System Tests Plans are
composed by the client ?s business team. System Test ensures that
expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business
requirement analysis part. It includes testing the software product in user
atmosphere. Acceptance tests reveal the compatibility problems with the
different systems, which is available within the user atmosphere. It
 JAI ENTERPRISES
conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.

When to use V-Model?

o When the requirement is well defined and not ambiguous.
o The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical resources are
available with essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall
model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.
2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of
the software are produced.
4. If any changes happen in the midway, then the test documents along with the
required documents, has to be updated.

What is Static Testing?

Static Testing is a type of software testing in which software application is tested
without code execution. Manual or automated reviews of code, requirement documents
and document design are done in order to find the errors. The main objective of static
testing is to improve the quality of software applications by finding errors in early stages
of software development process.
 JAI ENTERPRISES
Static testing involves manual or automated reviews of the documents. This review is
done during an initial phase of testing to catch Defect early in STLC. It examines work
documents and provides review comments. It is also called Non-execution testing or
verification testing.

Examples of Work documents-

 Requirement specifications
 Design document
 Source Code
 Test Plans
 Test Cases
 Test Scripts
 Help or User document
 Web Page content

What is Dynamic Testing?

Under Dynamic Testing, a code is executed. It checks for functional behaviour of
software system, memory/CPU usage and overall performance of the system. Hence the
name “Dynamic”

The main objective of this testing is to confirm that the software product works in
conformance with the business requirements. This testing is also called an Execution
technique or validation testing.

Dynamic testing executes the software and validates the output with the expected
outcome. Dynamic testing is performed at all levels of testing and it can be either black
or white box testing.

Differences between Black Box Testing vs White Box Testing:

S.
No. Black Box Testing White Box Testing

It is a way of software testing in which the It is a way of testing the software in which
internal structure or the program or the the tester has knowledge about the internal
code is hidden and nothing is known structure or the code or the program of the
1. about it. software.
 JAI ENTERPRISES
S.
No. Black Box Testing White Box Testing

Implementation of code is not needed for Code implementation is necessary for

2. black box testing. white box testing.

3. It is mostly done by software testers. It is mostly done by software developers.

No knowledge of implementation is
4. needed. Knowledge of implementation is required.

It can be referred to as outer or external It is the inner or the internal software

5. software testing. testing.

6. It is a functional test of the software. It is a structural test of the software.

This testing can be initiated based on the This type of testing of software is started
7. requirement specifications document. after a detail design document.

No knowledge of programming is It is mandatory to have knowledge of

8. required. programming.

9. It is the behaviour testing of the software. It is the logic testing of the software.

It is applicable to the higher levels of It is generally applicable to the lower

10. testing of software. levels of software testing.

11. It is also called closed testing. It is also called as clear box testing.

12. It is least time consuming. It is most time consuming.

It is not suitable or preferred for algorithm

13. testing. It is suitable for algorithm testing.

Can be done by trial and error ways and Data domains along with inner or internal
14. methods. boundaries can be better tested.
 JAI ENTERPRISES
S.
No. Black Box Testing White Box Testing

Example: Search something on google by Example: By input to check and verify

15. using keywords loops

Black-box test design techniques-

 Decision table testing White-box test design techniques-
 All-pairs testing  Control flow testing
 Equivalence partitioning  Data flow testing
16.  Error guessing  Branch testing

Types of Black Box Testing: Types of White Box Testing:

 Functional Testing  Path Testing
 Non-functional testing  Loop Testing
17.  Regression Testing  Condition testing

It is less exhaustive as compared to white It is comparatively more exhaustive than

18. box testing. black box testing.

1. Walkthrough:

 It is not a formal process

 It is led by the authors
 Author guide the participants through the document according to his or her
thought process to achieve a common understanding and to gather
feedback.
 Useful for the people if they are not from the software discipline, who are
not used to or cannot easily understand software development process.
 Is especially useful for higher level documents like requirement
specification, etc.
The goals of a walkthrough:

 To present the documents both within and outside the software discipline
in order to gather the information regarding the topic under
documentation.
 To explain or do the knowledge transfer and evaluate the contents of the
document
 JAI ENTERPRISES
 To achieve a common understanding and to gather feedback.
 To examine and discuss the validity of the proposed solutions
2. Technical review:

 It is less formal review

 It is led by the trained moderator but can also be led by a technical expert
 It is often performed as a peer review without management participation
 Defects are found by the experts (such as architects, designers, key users)
who focus on the content of the document.
 In practice, technical reviews vary from quite informal to very formal
The goals of the technical review are:

 To ensure that an early stage the technical concepts are used correctly
 To access the value of technical concepts and alternatives in the product
 To have consistency in the use and representation of technical concepts
 To inform participants about the technical content of the document
3. Inspection:

 It is the most formal review type

 It is led by the trained moderators
 During inspection the documents are prepared and checked thoroughly by
the reviewers before the meeting
 It involves peers to examine the product
 A separate preparation is carried out during which the product is examined
and the defects are found
 The defects found are documented in a logging list or issue log
 A formal follow-up is carried out by the moderator applying exit criteria
The goals of inspection are:

 It helps the author to improve the quality of the document under inspection
 It removes defects efficiently and as early as possible
 It improve product quality
 It create common understanding by exchanging information
 It learn from defects found and prevent the occurrence of similar defects

Quality Assurance (QA) Quality Control (QC)

It focuses on providing assurance that the It focuses on fulfilling the quality

quality requested will be achieved. requested.
 JAI ENTERPRISES
Quality Assurance (QA) Quality Control (QC)

It is the technique of managing quality. It is the technique to verify quality.

It is not included during the

It is involved during the development phase. development phase.

It does not include the execution of the It always includes the execution of
program. the program.

It is process oriented. It is product oriented.

The aim of quality assurance is to prevent The aim of quality control is to identify
defects. and improve the defects.

It is a preventive technique. It is a corrective technique.

It is responsible for the entire software It is responsible for the software

development life cycle. testing life cycle.

It pays main focus is on the intermediate

process. Its primary focus is on final products.

All team members of the project are Generally, the testing team of the
involved. project is involved.

Example: Verification Example: Validation

Quality engineer(QE) -it is automation tester .he writes the code to test
system automatically.

Software engineer(SE)- It is an engineer who writes the code to develop

the software.
 JAI ENTERPRISES
Integration testing
What Is Incremental Testing
Incremental Testing, also known as Incremental Integration Testing, is one of the
approaches of Integration Testing and incorporates its fundamental concepts.

In this testing, we test each module individually in unit testing phase, and then
modules are integrated incrementally and tested to ensure smooth interface and
interaction between modules.

In this approach, every module is combined incrementally, i.e., one by one till all
modules or components are added logically to make the required application, instead
of integrating the whole system at once and then performing testing on the end
product. Integrated modules are tested as a group to ensure successful integration
and data flow between modules.

As in integration testing, the primary focus of doing this testing is to check interface,
integrated links, and flow of information between modules. This process is repeated
till the modules are combined and tested successfully.

Ex:-software and they have sub module

Incremental Integration testing approach

 Each Module i.e. M1, M2, M3, etc. are tested individually as part of unit
testing
 Modules are combined incrementally i.e. one by one and tested for
successful interaction
 In Fig2, Module M1 & Module M2 are combined and tested
 In Fig3, Module M3 is added and tested
 JAI ENTERPRISES
 In Fig4, Module M4 is added and testing is done to make sure everything
works together successfully
 Rest of the Modules are also added incrementally at each step and
tested for successful integration

Fig2

Fig3

Fig4

#1) Top Down

As the name suggests, testing takes place from top to bottom, i.e., from the central
module to sub module. Modules framing the top layer of application are tested first.
 JAI ENTERPRISES

Top down Incremental Integration Testing Approach

Following test cases will be derived:
Test Case1: Module L and Module O will be integrated and tested
Test Case2: Module L, O and P will be integrated and tested
Test Case3: Module L, O, P and R will be integrated and tested.
#2) Bottom-up
In this approach, testing takes place from bottom to top, i.e., modules at bottom
layer are integrated and tested first and then sequentially other modules are
integrated as we move up.
 JAI ENTERPRISES

Bottom up Incremental Integration testing approach

Following test cases will be derived:
Test Case1: Unit testing of module Practical and Theory
Test Case2: Integration and testing of Modules Marks-Practical-theory
Test Case3: Integration and testing of Modules Percentage-Marks-Practical-Theory
Test Case4: Unit testing of Module Sports Grade
Test Case5: Integration and testing of Modules Rank-Sports Grade-Percentage-
Marks-Practical-Theory
#3) Sandwich Testing
This approach is a hybrid of top-down and bottom-up methodology. Stub and drivers
are used for incomplete or not developed modules.

Testing Approach
 A middle layer is identified from which bottom-up and top-down testing
are done. This middle layer is also known as target layer
 Target layer is identified as per Heuristic approach, i.e., select a layer
which allows minimal use of Stubs and drivers
 Top-down testing starts from middle layer and moves downwards
towards lower level modules. This layer below middle layer is known as
Bottom layer
 JAI ENTERPRISES
 Bottom-up testing also starts from middle layer and move up towards
top layer modules. This layer above middle layer is known as Top layer
 With use of stubs and drivers, user interface and functions of lower level
modules are tested respectively
 In the end, only middle layer is left for the execution of the final test

Following test cases can be derived with Sandwich Testing Strategy:

Test Case1: Test A, X, Y, and Z individually – where Test A comes under Top layer
test and Test X, Y and Z comes under Bottom layer tests
Test Case2: Test A, G, H and I
Test Case3: Test G, X, and Y
Test Case4: Test Hand Z
Test Case5: Test A, G, H, I, X, Y, and Z

Stubs and Drivers

Stubs and Drivers are the dummy programs in Integration testing used to facilitate the
software testing activity. These programs act as a substitutes for the missing models in
the testing. They do not implement the entire programming logic of the software
module but they simulate data communication with the calling module while testing.
Stub: Is called by the Module under Test.

Driver: Calls the Module to be tested.

System testing
 JAI ENTERPRISES
What is GUI Testing?
GUI Testing is a software testing type that checks the Graphical User Interface of the
Software. The purpose of Graphical User Interface (GUI) Testing is to ensure the
functionalities of software application work as per specifications by checking screens
and controls like menus, buttons, icons, etc.

Functional Testing Non-functional Testing

It verifies the operations

and actions of an It verifies the behavior of
application. an application.

It is based on
requirements of It is based on expectations
customer. of customer.

It helps to enhance the It helps to improve the

behavior of the performance of the
application. application.

Functional testing is It is hard to execute non-

easy to execute functional testing
manually. manually.

It tests what the product It describes how the

does. product does.

Functional testing is Non-functional testing is

based on the business based on the performance
requirement. requirement.

Examples: Examples:
1. Unit Testing 1. Performance
2. Smoke Testing Testing
3. Integration 2. Load Testing
Testing 3. Stress Testing
4. Regression 4. Scalability
Testing Testing
 JAI ENTERPRISES

Retesting vs Regression Testing

REGRESSION TESTING RE-TESTING

REGRESSION TESTING IS CARRIED OUT RE-TESTING IS CARRIED OUT TO CONFIRM THE

TO CONFIRM WHETHER A RECENT TEST CASES THAT FAILED
PROGRAM OR CODE CHANGE HAS NOT
ADVERSELY AFFECTED EXISTING IN THE FINAL EXECUTION ARE PASSING AFTER
FEATURES THE DEFECTS ARE FIXED

THE PURPOSE OF REGRESSION TESTING

IS THAT NEW CODE CHANGES SHOULD RE-TESTING IS DONE ON THE BASIS OF THE
NOT HAVE ANY SIDE EFFECTS TO DEFECT FIXES
EXISTING FUNCTIONALITIES

DEFECT VERIFICATION IS NOT THE PART

DEFECT VERIFICATION IS THE PART OF RE-TESTING
OF REGRESSION TESTING

BASED ON THE PROJECT AND

AVAILABILITY OF RESOURCES, PRIORITY OF RE-TESTING IS HIGHER THAN REGRESSION
REGRESSION TESTING CAN BE CARRIED TESTING, SO IT IS CARRIED OUT BEFORE REGRESSION T
OUT PARALLEL WITH RE-TESTING

YOU CAN DO AUTOMATION FOR

REGRESSION TESTING, MANUAL YOU CANNOT AUTOMATE THE TEST CASES
TESTING COULD BE EXPENSIVE AND FOR RETESTING
TIME-CONSUMING

REGRESSION TESTING IS KNOWN AS A

RE-TESTING IS A PLANNED TESTING
GENERIC TESTING

REGRESSION TESTING IS DONE FOR

RETESTING IS DONE ONLY FOR FAILED TEST CASES
PASSED TEST CASES

REGRESSION TESTING CHECKS FOR RE-TESTING MAKES SURE THAT THE ORIGINAL
UNEXPECTED SIDE-EFFECTS FAULT HAS BEEN CORRECTED

REGRESSION TESTING IS ONLY DONE RE-TESTING EXECUTES A DEFECT WITH THE SAME
WHEN THERE IS ANY MODIFICATION OR
 JAI ENTERPRISES
CHANGES BECOME MANDATORY IN AN DATA AND THE SAME ENVIRONMENT
EXISTING PROJECT WITH DIFFERENT INPUTS WITH A NEW BUILD

TEST CASES FOR REGRESSION TESTING

CAN BE OBTAINED FROM THE
FUNCTIONAL SPECIFICATION, USER TEST CASES FOR RETESTING CANNOT BE OBTAINED
TUTORIALS AND MANUALS, AND DEFECT BEFORE START TESTING.
REPORTS IN REGARDS TO CORRECTED
PROBLEMS
JAI ENTERPRISES
 JAI ENTERPRISES
End To End Testing
End To End Testing is a software testing method that validates entire software from
starting to the end along with its integration with external interfaces. The purpose of
end-to-end testing is testing whole software for dependencies, data integrity and
communication with other systems, interfaces and databases to exercise complete
production like scenario.
Along with the software system, it also validates batch/data processing from other
upstream/downstream systems. Hence, the name “End-to-End”. End to End Testing is
usually executed after functional and System Testing.

Positive Testing
Positive testing ensures that software performs as it is expected to do. When writing test
cases for positive testing, only legitimate (valid) inputs are provided as inputs.
In other words, positive testing is the process of evaluating a system or application using
accurate input data.
The primary goal of positive testing is to validate if a software program does what it is
intended to do.
Simply put, a positive test is conducted by providing an expected set of values as inputs to
the test cases.

Negative Testing
It is vice versa for positive testing. In Negative testing, a software program is evaluated
against false or incorrect data.
Negative testing is also known as error path testing or failure.
It is best to check if the computer program reacts as expected to false or invalid user inputs.
Negative testing ensures the software program does not crash and continues running even
with wrong data inputs.
A software tester most likely starts by considering the positive inputs when considering the
test scenarios. Still, it is equally important to know that understanding the importance of
negative tests is always crucial. It is seen as being essential to the execution of test cases.
Negative testing ensures that the software program displays an error when it should and
does not display an error when it should not. Additionally, it helps software developers find
more flaws and improve the software program being tested.
 JAI ENTERPRISES
Non functional
testing is just as important as functional testing. Both ensure that your product is working as
it should. But non functional testing checks aspects of your product that aren’t covered in
functional tests. And it helps ensure a high level of product quality, performance, and
usability - all of which lead to higher user satisfaction.

In this blog post we'll define what non-functional testing is, look at some examples of non
functional tests, and show you the best way to manage all types of non-functional testing.

Continue reading or jump ahead to the section that interests you most:

• What is Non Functional Testing?

• 7 Non Functional Test Types

• Non Functional Testing Tools

• How to Manage All Types of Non Functional Testing

What is Non Functional Testing?

Non functional testing is a type of software testing that verifies non functional aspects of the
product, such as performance, stability, and usability. Whereas functional testing verifies
whether or not the product does what it is supposed to, non functional testing verifies how
well the product performs.

7 Non Functional Test Types

There are several different types of non functional tests. The most common ones are:

1. Performance Tests

2. Load Tests

3. Stress Tests

4. Volume Tests
 JAI ENTERPRISES
5. Security Tests

6. Upgrade & Installation Tests

7. Recovery Tests

All of these non functional test types help to ensure that your product is fast, stable, scalable,
reliable, and secure.

1. Performance Tests
Performance testing checks how well software components work. These tests can find issues
in software design and architecture performance.

This is typically done by:

• Measuring response times

• Identifying bottlenecks

• Locating failure points

Performance tests ensure several elements of software quality. They validate that it’s fast,
scalable, stable, and reliable.

2. Load Tests
Load testing checks how the software behaves under both normal and peak conditions. This is
done to determine how much work load the software can handle before performance is
negatively affected.

You can perform load tests by running multiple applications simultaneously, subjecting a
server to a high amount of traffic, or downloading a large quantity of files.

Load tests are used to ensure fast and scalable software.

3. Stress Tests
Stress testing checks how the software behaves under abnormal conditions. This determines
the limit at which the software will break.
 JAI ENTERPRISES
It’s important to find out what happens when the system is under stress. Does the right error
message display? Does the system fail? How will it recover?

Stress tests help testers analyze what happens when a system fails. This ensures that
software is recoverable, stable, and reliable.

4. Volume Tests
Volume testing serves to verify what happens to system performance when a huge volume of
data is added to the database. This is done to identify what problems may occur with
increasing volumes of data. It’s also known as flood testing.

You can use volume tests to check if there’s any data loss, warning or error messages, or data
storage issues when massive amounts of data are added to the product.

Volume tests verify that systems respond as expected to certain volumes of data. This is
important for ensuring performance and stability.

5. Security Tests
Security testing checks software to find flaws or vulnerabilities that may compromise data.
The goal of security testing is to identify any potential security risks or threats and to ensure
that the product is not vulnerable to hacking, data breaches, or other types of security issues.

Common security tests include:

• Vulnerability scans

• Security scans

• Penetration testing

• Risk assessment

• Security audits

• Posture assessment

• Ethical hacking

Running these tests is important to developing a secure, stable system.

 JAI ENTERPRISES
6. Upgrade and Installation Tests
Upgrade testing and installation testing verify that software will work properly on everyone’s
machines. So, upgrade testing is done for existing users. And installation testing is done for
new users.

Both of these types of functional tests are important for user satisfaction. After all, no matter
how great your product is, if a user runs into problems installing or upgrading it, they'll never
know how good it is!

7. Recovery Tests
Recovery tests determine how quickly software can rebound after a crash or failure. This is
done by forcing the system to fail.

This type of testing is done to see what happens to the software:

• If you unplug the hardware.

• If you disconnect from the network during a data transfer.

• When you restart the system unexpectedly.

Boundary Value Analysis (BVA)

Boundary value analysis is based on testing at the boundaries between partitions. It
includes maximum, minimum, inside or outside boundaries, typical values and error
values.

It is generally seen that a large number of errors occur at the boundaries of the defined
input values rather than the center. It is also known as BVA and gives a selection of test
cases which exercise bounding values.

This black box testing technique complements equivalence partitioning. This software
testing technique base on the principle that, if a system works well for these particular
values then it will work perfectly well for all values which comes between the two
boundary values.

Guidelines for Boundary Value analysis

 JAI ENTERPRISES
 If an input condition is restricted between values x and y, then the test cases
should be designed with values x and y as well as values which are above and
below x and y.
 If an input condition is a large number of values, the test case should be
developed which need to exercise the minimum and maximum numbers. Here,
values above and below the minimum and maximum values are also tested.
 Apply guidelines 1 and 2 to output conditions. It gives an output which reflects
the minimum and the maximum values expected. It also tests the below or above
values.

Example:
Input condition is valid between 1 to 10

Boundary values 0,1,2 and 9,10,11

Equivalence Class Partitioning

Equivalent Class Partitioning allows you to divide set of test condition into a partition
which should be considered the same. This software testing method divides the input
domain of a program into classes of data from which test cases should be designed.

The concept behind this Test Case Design Technique is that test case of a representative
value of each class is equal to a test of any other value of the same class. It allows you to
Identify valid as well as invalid equivalence classes.

Example:

Input conditions are valid between

1 to 10 and 20 to 30
Hence there are five equivalence classes
--- to 0 (invalid)
1 to 10 (valid)
11 to 19 (invalid)
20 to 30 (valid)
31 to --- (invalid)
You select values from each class, i.e.,
-2, 3, 15, 25, 45
 JAI ENTERPRISES
Decision Table Based Testing
A decision table is also known as to Cause-Effect table. This software testing technique
is used for functions which respond to a combination of inputs or events. For example, a
submit button should be enabled if the user has entered all required fields.

The first task is to identify functionalities where the output depends on a combination
of inputs. If there are large input set of combinations, then divide it into smaller subsets
which are helpful for managing a decision table.

For every function, you need to create a table and list down all types of combinations of
inputs and its respective outputs. This helps to identify a condition that is overlooked by
the tester.

Following are steps to create a decision table:

 Enlist the inputs in rows

 Enter all the rules in the column
 Fill the table with the different combination of inputs
 In the last row, note down the output against the input combination.

Example: A submit button in a contact form is enabled only when all the inputs are
entered by the end user.
 JAI ENTERPRISES
State Transition
In State Transition technique changes in input conditions change the state of the
Application Under Test (AUT). This testing technique allows the tester to test the
behaviour of an AUT. The tester can perform this action by entering various input
conditions in a sequence. In State transition technique, the testing team provides
positive as well as negative input test values for evaluating the system behaviour.

Guideline for State Transition:

 State transition should be used when a testing team is testing the application for
a limited set of input values.
 The Test Case Design Technique should be used when the testing team wants to
test sequence of events which happen in the application under test.

Example:

In the following example, if the user enters a valid password in any of the first three
attempts the user will be able to log in successfully. If the user enters the invalid
password in the first or second try, the user will be prompted to re-enter the password.
When the user enters password incorrectly 3rd time, the action has taken, and the
account will be blocked.
 JAI ENTERPRISES
State Transition Diagram

In this diagram when the user gives the correct PIN number, he or she is moved to
Access granted state. Following Table is created based on the diagram above-

State Transition Table

Correct PIN Incorrect PIN

S1) Start S5 S2

S2) 1st attempt S5 S3

S3) 2nd attempt S5 S4

S4) 3rd attempt S5 S6

S5) Access Granted – –

S6) Account blocked – –

 JAI ENTERPRISES
In the above-given table when the user enters the correct PIN, the state is transitioned
to Access granted. And if the user enters an incorrect password, he or she is moved to
next state. If he does the same 3rd time, he will reach the account blocked state.

Error Guessing
Error Guessing is a software testing technique based on guessing the error which can
prevail in the code. The technique is heavily based on the experience where the test
analysts use their experience to guess the problematic part of the testing application.
Hence, the test analysts must be skilled and experienced for better error guessing.
The technique counts a list of possible errors or error-prone situations. Then tester
writes a test case to expose those errors. To design test cases based on this software
testing technique, the analyst can use the past experiences to identify the conditions.

Guidelines for Error Guessing:

 The test should use the previous experience of testing similar applications
 Understanding of the system under test
 Knowledge of typical implementation errors
 Remember previously troubled areas
 Evaluate Historical data & Test results

STLC Phases
There are following six major phases in every Software Testing Life Cycle Model (STLC
Model):

STLC Model Phases

 JAI ENTERPRISES
1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure

Each of these stages has a definite Entry and Exit criteria, Activities & Deliverables
associated with it.

What is Entry and Exit Criteria in STLC?

 Entry Criteria: Entry Criteria gives the prerequisite items that must be completed
before testing can begin.
 Exit Criteria: Exit Criteria defines the items that must be completed before
testing can be concluded

You have Entry and Exit Criteria for all levels in the Software Testing Life Cycle (STLC)

In an Ideal world, you will not enter the next stage until the exit criteria for the previous
stage is met. But practically this is not always possible. So for this tutorial, we will focus
on activities and deliverables for the different stages in STLC life cycle. Let’s look into
them in detail.

Requirement Phase Testing

Requirement Phase Testing also known as Requirement Analysis in which test team
studies the requirements from a testing point of view to identify testable requirements
and the QA team may interact with various stakeholders to understand requirements in
detail. Requirements could be either functional or non-functional. Automation
feasibility for the testing project is also done in this stage.
Activities in Requirement Phase Testing

 Identify types of tests to be performed.

 Gather details about testing priorities and focus.
 Prepare Requirement Traceability Matrix (RTM).
 Identify test environment details where testing is supposed to be carried out.
 Automation feasibility analysis (if required).
 JAI ENTERPRISES
Deliverables of Requirement Phase Testing

 RTM
 Automation feasibility report. (if applicable)

Test Planning in STLC

Test Planning in STLC is a phase in which a Senior QA manager determines the test
plan strategy along with efforts and cost estimates for the project. Moreover, the
resources, test environment, test limitations and the testing schedule are also
determined. The Test Plan gets prepared and finalized in the same phase.
Test Planning Activities

 Preparation of test plan/strategy document for various types of testing

 Test tool selection
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement

Deliverables of Test Planning

 Test plan /strategy document.

 Effort estimation document.

Test Case Development Phase

The Test Case Development Phase involves the creation, verification and rework of
test cases & test scripts after the test plan is ready. Initially, the Test data is identified
then created and reviewed and then reworked based on the preconditions. Then the QA
team starts the development process of test cases for individual units.
Test Case Development Activities

 Create test cases, automation scripts (if applicable)

 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)

Deliverables of Test Case Development

 Test cases/scripts
 JAI ENTERPRISES
 Test data

Test Environment Setup

Test Environment Setup decides the software and hardware conditions under which a
work product is tested. It is one of the critical aspects of the testing process and can be
done in parallel with the Test Case Development Phase. Test team may not be involved
in this activity if the development team provides the test environment. The test team is
required to do a readiness check (smoke testing) of the given environment.
Test Environment Setup Activities

 Understand the required architecture, environment set-up and prepare hardware

and software requirement list for the Test Environment.
 Setup test Environment and test data
 Perform smoke test on the build

Deliverables of Test Environment Setup

 Environment ready with test data set up

 Smoke Test Results.

Test Execution Phase

Test Execution Phase is carried out by the testers in which testing of the software build
is done based on test plans and test cases prepared. The process consists of test script
execution, test script maintenance and bug reporting. If bugs are reported then it is
reverted back to development team for correction and retesting will be performed.
Test Execution Activities

 Execute tests as per plan

 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure

Deliverables of Test Execution

 Completed RTM with the execution status

 Test cases updated with results
 JAI ENTERPRISES
 Defect reports

Test Cycle Closure

Test Cycle Closure phase is completion of test execution which involves several
activities like test completion reporting, collection of test completion matrices and test
results. Testing team members meet, discuss and analyze testing artifacts to identify
strategies that have to be implemented in future, taking lessons from current test cycle.
The idea is to remove process bottlenecks for future test cycles.
Test Cycle Closure Activities

 Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software,

Critical Business Objectives, Quality
 Prepare test metrics based on the above parameters.
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to the
customer.
 Test result analysis to find out the defect distribution by type and severity.

Deliverables of Test Cycle Closure

 Test Closure report

 Test metrics

Test Plan
A test plan is a detailed document which describes software testing areas and
activities. It outlines the test strategy, objectives, test schedule, required
resources (human resources, software, and hardware), test estimation and test
deliverables.

The test plan is a base of every software's testing. It is the most crucial activity
which ensures availability of all the lists of planned activities in an appropriate
sequence.

The test plan is a template for conducting software testing activities as a defined
process that is fully monitored and controlled by the testing manager. The test
plan is prepared by the Test Lead (60%), Test Manager(20%), and by the test
engineer(20%).
 JAI ENTERPRISES
How to write a Test Plan
Making a test plan is the most crucial task of the test management process.
According to IEEE 829, follow the following seven steps to prepare a test plan.

o First, analyze product structure and architecture.

o Now design the test strategy.
o Define all the test objectives.
o Define the testing area.
o Define all the useable resources.
o Schedule all activities in an appropriate manner.
o Determine all the Test Deliverables.

Test plan components or attributes

The test plan consists of various parts, which help us to derive the entire testing
activity.

What is Use Case?

o In software testing, a use case is a graphic representation of business needs
explaining how the end-user will cooperate with software or an application. And
 JAI ENTERPRISES
the use cases allow us all the possible techniques of how the end-user uses the
application.
o In simple words, we can express that with the help of use cases; we can define
how to use the system for executing a precise task.
o The use case is not a part of execution which means that it is only a graphic
demonstration of a document that explains how to implement a particular task.
o With the help of the use case, we get to know how the product should work.

What is Test Case?

o A test case is defined as a group of conditions under a test engineer concludes
whether a software application is working as per the customer's requirements or
not.
o The test case designing includes preconditions, case name, input conditions,
and expected result.
o These are derived from the test scenarios, and it is a first-level action.
o Mainly, test cases are used to validate the developed software by test engineers
that the particular software is working as per requirement or not.
o A test Caseis described as a group of various testing activities like test inputs,
execution conditions, and expected results that additionally lead to evolving
a particular test objective.
o Writing test cases is a one-time attempt that can be used in the future at the time
of regression testing.

What is Test Scenarios?

It is a detailed document of test cases that cover end to end functionality of a
software application in liner statements. The test scenario is a high-level
classification of testable requirements. Before performing the test scenario, the
test engineer needs to consider the test cases for each scenario.

What is a Test Suite?

Test suite is a container that has a set of tests which helps testers in executing
and reporting the test execution status. It can take any of the three states
namely Active, Inprogress and completed.
 JAI ENTERPRISES
A Test case can be added to multiple test suites and test plans. After creating a
test plan, test suites are created which in turn can have any number of tests.
Test suites are created based on the cycle or based on the scope. It can contain
any type of tests, viz - functional or Non-Functional.

Test Suite - Diagram:

What is Traceability Matrix?

Requirement Traceability Matrix (RTM) is used to trace the
requirements to the tests that are needed to verify whether the
requirements are fulfilled.
 JAI ENTERPRISES

What is a Test Environment?

A testing environment is a setup of software and hardware for the testing teams to
execute test cases. In other words, it supports test execution with hardware, software
and network configured.

Test bed or test environment is configured as per the need of the Application Under
Test. On a few occasion, test bed could be the combination of the test environment and
the test data it operates.

Setting up a right test environment ensures software testing success. Any flaws in this
process may lead to extra cost and time to the client.

What is Test Execution?

Test execution is the process of executing the code and comparing the expected
and actual results. Following factors are to be considered for a test execution
process:
 Based on a risk, select a subset of test suite to be executed for this
cycle.
 Assign the test cases in each test suite to testers for execution.
 Execute tests, report bugs, and capture test status continuously.
 Resolve blocking issues as they arise.
 Report status, adjust assignments, and reconsider plans and priorities
daily.
 Report test cycle findings and status.
 1. Error or Mistake:
 Error is a human action that produces an incorrect result. It is
deviation from actual and expected value. The mistakes made by
programmer is known as an ‘Error’.
 JAI ENTERPRISES
 2. Bug:
 A Bug is the result of a coding Error or Fault in the program which
causes the program to behave in an unintended manner.
 3. Defect or Fault:
 A Defect is a deviation from the Requirements. A Software Defect
is a condition in a software product which does not meet a software
requirement or end-user expectations.
 Bug vs. Defect
 A Bug is the result of a coding Error and A Defect is a deviation
from the Requirements. A defect does not necessarily mean there
is a bug in the code,
 5. Failure:
 If an end-user detects an issue in the product, then that particular
issue is called a failure.

 A Sample Defect report or Bug report:

 Defect ID – Every bug or defect has it’s unique identification

number
 Defect Description – This includes the abstract of the issue.
 Product Version – This includes the product version of the
application in which the defect is found.
 Detail Steps – This includes the detailed steps of the issue with the
screenshots attached so that developers can recreate it.
 Date Raised – This includes the Date when the bug is reported
 Reported By – This includes the details of the tester who reported
the bug like Name and ID
 Status – This field includes the Status of the defect like New,
Assigned, Open, Retest, Verification, Closed, Failed, Deferred, etc.
 Fixed by – This field includes the details of the developer who fixed
it like Name and ID
 Date Closed – This includes the Date when the bug is closed
 Severity – Based on the severity (Critical, Major or Minor) it tells us
about impact of the defect or bug in the software application
 JAI ENTERPRISES
 Priority – Based on the Priority set (High/Medium/Low) the order of
fixing the defect can be made.

Defects are classified from the QA team perspective as Priority and from the
development perspective as Severity (complexity of code to fix it). These are
two major classifications that play an important role in the timeframe and the
amount of work that goes in to fix defects.

What is Priority?
Priority is defined as the order in which the defects should be resolved. The
priority status is usually set by the QA team while raising the defect against the
dev team mentioning the timeframe to fix the defect. The Priority status is set
based on the requirements of the end users.
For example, if the company logo is incorrectly placed in the company's web
page then the priority is high but it is of low severity.

Priority Listing
A Priority can be categorized in the following ways −
 Low − This defect can be fixed after the critical ones are fixed.
 Medium − The defect should be resolved in the subsequent builds.
 High − The defect must be resolved immediately because the defect
affects the application to a considerable extent and the relevant
modules cannot be used until it is fixed.
 Urgent − The defect must be resolved immediately because the
defect affects the application or the product severely and the product
cannot be used until it has been fixed.
What is Severity?
Severity is defined as the impishness of defect on the application and complexity
of code to fix it from development perspective. It is related to the development
aspect of the product. Severity can be decided based on how bad/crucial is the
defect for the system. Severity status can give an idea about the deviation in the
functionality due to the defect.
Example − For flight operating website, defect in generating the ticket number
against reservation is high severity and also high priority.

Severity Listing
Severity can be categorized in the following ways −
 Critical /Severity 1 − Defect impacts most crucial functionality of
Application and the QA team cannot continue with the validation of
 JAI ENTERPRISES
application under test without fixing it. For example, App/Product
crash frequently.
 Major / Severity 2 − Defect impacts a functional module; the QA
team cannot test that particular module but continue with the
validation of other modules. For example, flight reservation is not
working.
 Medium / Severity 3 − Defect has issue with single screen or
related to a single function, but the system is still functioning. The
defect here does not block any functionality. For example, Ticket# is a
representation which does not follow proper alpha numeric characters
like the first five characters and the last five as numeric.
 Low / Severity 4 − It does not impact the functionality. It may be a
cosmetic defect, UI inconsistency for a field or a suggestion to
improve the end user experience from the UI side. For example, the
background colour of the Submit button does not match with that of
the Save button.

Defect Resolution
Defect Resolution in software testing is a step by step process of fixing the defects.
Defect resolution process starts with assigning defects to developers, then developers
schedule the defect to be fixed as per priority, then defects are fixed and finally
developers send a report of resolution to the test manager. This process helps to fix and
track defects easily.