What is Software Testing?

What is Software Testing? is quite interesting question. This

term software testing getting boom now a days. Many of you might
have these questions like what is software testing? , how do they do it?
Software testing is really needed? , how they test the software? And
many more.
If you googled what is software testing, you might have seen many
statement and many definitions like its test technique, its black box, its
white box, its a process which check completeness,correctness, quality
and security etc. these statements,these definitions will not clear the
concept of the software testing, especially for those people who want to
choose software testing as a career.

So, in this article I will try to clear the concept of software testing, how
do they do it and if you are planning to start the career as a software
tester. After reading this article you will get clear idea of software
testing.
Software testing is done to ensure that all the functionality and the
features of the software is working as per the clients requirements in
simple word software testing is an activity to check that the software is

bug free. For example, there is a person who want its own e-commerce
site like amazon, eBay etc. So he will contact any software company and
he will explains his all the requirement like he wants customer login,
customer can add their favorite product to cart, customer should able
to pay via online banking, credit debit card etc.To the software
company. So Software Company will write down all clients requirement
and according to that requirement Software developer develop the ecommerce site.
Then that developed software comes to Software Tester who test all the
functionalities and feature means software testers ensure that all the
functions and feature of software is working fine with all the possible
conditions and all the requirement which is given by the client is
included in software and working properly.
But the main question is how does the Software Tester test the
software? There are different technique, different ways to test the
software. Basically Testing starts with understanding the software
requirement. First tester understand all the requirement of the
software and its output. Then he writes the test cases to test each
requirement. For example, suppose one of the requirement of client is,
he wants that the customer should able to add product to cart or
bucket. So to test this functionality of software tester will write
following test cases.
1.
Verify ability of user to add the product to cart.
2.
Verify the ability of the user to add multiple product to the
cart/bucket.
3.
Verify the ability of the user to add different product from
different categories.
4.
Verify the description, price and quantity of added product in the
cart
5.
User should not be able to add duplicate product in the cart
6.
User should able to remove the product from cart
7.
User should able the increase quantity of the cart product
8.
And many more

Just imagine to test a single add to cart functionality testers have to

write so many test cases. It will help to find all major bugs/ errors
present in the software.
You might have one more question in your mind that do software
testers have to write test cases all the time. The answer is, it depends
on the testing technique they are using. In many testing techniques
they have to write the test cases but in Adhoc Testing testers do not
need to write the test cases.but to use Adhoc Testing technique tester
should have lots of knowledge about the software. This type of testing
technique is useful before the releasing of the software.There are
almost 150+ software testing techniques present.
There are lots of example available in history which shows the
important of proper software testing. Software bugs can cause money
loss and even loss of life. some of the incidence is shown below.

NASAs Mars Climate Orbiter was lost due to an issue in interfaces. The
communication with the spacecraft was lost as the spacecraft went into
orbital insertion. The issue was Ground based software was producing

data in the units of pound-seconds instead of producing data in

newton-seconds. The cost of the mission was almost $330 million. This
is very huge loss of money which could have been prevented if they
had found this bug during testing phase. There are many such a
incident happened , one of those is once Chine Airlines Airbus A300
had crashed on 26 April 1994 due to the software bug which killed 264
peoples present on the plane.

Such an incident shows us that how important Software Testing is. I

Hope You liked my article.
What is bug/ defect and why bugs arises in software Application?

This article will help you to understand what is bug and why do bug
arises in software. So First we are going to talks about bugs.
What is Bugs/ Defect?

In simple word, if any functionality of software is not working as per the

requirement then we can say that there is a bug in the software.in
other word if the software is not behaving as it is expected to behave. A
software bug is an error, failure, flaw or fault in a computer software
program or system that causes it to produce unexpected or an
incorrect or result.

For example : suppose you want to recharge your mobile so you goes
to a any recharge site and login your account and put your mobile
number , enters the recharge amount and clicks on next button. But
when you clicks on next button then nothing is happening you got stuck
on same page. So you will think why is this happening? This is because
of bugs in that software. Which is prevents you to go on to the next
page.
Suppose you are a Tester and your company is developing a software.
Before development they will finalize all the software requirement
Specifications. According to those requirement they developed a
software after development they sends this software with its
requirement document to you for testing. During testing you have
found that there is a functionality which is written in software
requirement specification but not present is software.at that time you
may think that is this a bug? Can we call a missing functionality as a
bug? Yes its a bug. a functionality which should be present in software
but actual not there is a bug. So you will might get one more question

in your mind. What if there is an extra functionality available in

software but that is not written in software requirement sheet. It is an
also a bug.
Bug :

A Functionality is not working as per the requirement sheet.

Missing functionality.

Extra functionality.
Why Bugs arises in Software?
We are humans, we are not a machines. So the things which we are
going to build is not gonna be 100% perfect.
The bugs start coming from the initial stage of the software
development life cycle. Let discuss each factor that can cause a bug in
software.

1) Requirements of Client : When any client/customer want to buildan

software then that client contact to any IT organization and tells his
requirement. But sometime that client dont know what actually he
wants. He is unclear about his requirement.

Clients tells an partial requirement or unclear requirement to the

company. So because of this any certain functionality not available or
partial available or it may not get developed as per the users
expectation.

Clients frequently changing requirement can also cause bugs.

2) Design complexity : A complex and sometime aunrealistic
requirement of the client can cause a big trouble in designing the
system. Such a complex requirement requires lot of research, R&D but
as software development is a time bound activity. Every clients want his
software on time. In such a situation they have to do some
compromise. Lack of patience and an urge to complete it as quickly as
possible may lead to errors. This effects on the performance of the
application.

3) Coding : In this phase development of the software actually start.

Here developer start the coding to build the software. In this phase lot
of bug can arises in software. There are many reasons which can
causes the bugs. Like if developer is not skilled and because of
developers poor skilled he is unable to develop software in good
manner.
Another reason that can cause bugs in this phases is continuous
changing requirements. Many time client dont have clear requirement
in his mind but as times goes on client get some ideas or clarification
then clients tell his new requirement to company. To fulfill clients
changed requirement or Requirement Company has to do some
adjustment. Later on this can effect on the softwares functionality.

Another main reason is less time for coding. This thing happens to
meet the dead line .this puts extra pressure on developer which can
effect on his productivity which result in poor coding and incorrect
coding output.

4) Testing : This is a phase where all the major bugs should be detected
by the testing team. Ideally there is not any software with 100% bug
free. But it is expected from testing team to find all the major bugs.
There are some factors which can effect on testing.
One of the reason is less knowledge about the software. When testing
team do not have good knowledge about software then they are unable
to write effective test cases which result in poor testing and will be
unable to detect bugs. This happen when there is not proper
documentation or very less documentation.
Another reason is less time for testing. When testing team do not have
needed time for testing they prioritize the test cases and leave some
part untested which ultimately leave some bugs detected?

Some Companies do not take testing as a serious activity so they do not

invest time and resources on testing. Many small scale IT companies do
not hire tester their developers do testing of their own code. Developer

gets biased to test their own code which result leaving major bugs
undetected
5) Deployment : Every software made by considering its hardware and
software requirement. if any software is installed on unsupported or
lesser hardware and software then that software behave unexpectedly
which causes failure.

How to report a Bug?/ How to make

Incident Report?
The main work of software test engineer is to test the software and find
as many as possible bugs in software. If you dont know what is bug
then you should first read this article what is Bug?
Tester writes the test cases based on requirement and he execute the
test cases on the software. Below is the image of demo test case. if the
expected result is different than actual result thats mean functionality
is not working correctly.

(test cases may contains many other parameters apart from this there
are pre-requisite, test data, test step and remark etc.)
So to get this functionality fixed tester need to tell this bug ,defect to
the developer so developer can fix it, tester has to tell this in detail
under what scenario or under which situation software behaves
unexpected. Tester cant go to the developer and says that hey this is
not working properly, get this fixed for me. This is not proper way, then
what is the proper way to report the bug? Proper way is to write the
detail report about bug.
We Testers need to write detail description which should contain
needed information, using this information developer should be able to

re-create the bug. So how are we going to do that? Either we can use
defect management tools like BugZila , BugNetetc. or use can also use
Word or Excel file. This depends on the organization how are they
reporting their bug, most of the companies still prefer to use word or
excel file.

I am going to explain how to report a bug in Word File.Word file should

contain following fields for effecting bug reporting. You will find these
fields across all the defect management tools.
Bug ID : it is a unique id that we need to give to each bug. Giving
the different ids to bug help to identifying and tracking the bug. For
example if you have found bug related to User interface you may write
it as UI_1 and for any functional bug FN_1. You can write it with more
details like Login_UI_1 means you have found UI bug in login module.
Project Name : Software name on which we have found that bug.
There might be a situation in which you have allotted multiple testing
project at the same time. So this will help you and other team members
to know, this bug related to which project.
Module Name : Software is made of many module, we need to
specify in which module we have found the bug. For example an
institutional software will have Registration module, receipt module,
online test module, library module etc. and suppose we found the bug
in online test module then we need to write online test module.
Level or Phase : There are four level of testing and those are Unit
testing, Integration testing, System testing and UAT. Here we need to
specify when defect is found.
Defect Type : here we need to specify the type of defect.Means
whether that bug is related to functional bug, non-functional bug or any
necessary enhancement. If any module is hard to understand they
tester may give some suggestions to make that module user friendly.
Severity : Severity tell the impact of particular bug on the
software. We need to define the bugs severity as High, medium and
low. Severity will be high if we have found a bug and because of that
bug we cant continue our testing further. E.g. login functionality of
Facebook is not working this bug will marked as severity High. Low

Severity bugs are those bugs like spelling mistake in text contain or
there is a wrong icon to any button.
Priority : Priority is related to the time.Means urgency of fixing
the bug and we also define the priority of the bug as High, medium and
low. If the severity of the bug is high and we cant continue our testing
without fixing this bug then the priority of that bug would be mark as
High. And in incremental and iterative type software development cycle
the requirements are divided into small builds, if we have found a bug
in module which is included current build release then that bug is
marked as High and suppose we have found the bug is a module which
is not the part current build release then that is marked as Low priority.
Summary : Summary means one line statement that gives basic
idea of the defect. Like login functionality is not working fine,
registration page is not opening etc. it is not an details description just
one line statements.
Description : In this field we need to give a detail explanation
about the defect. We need to give step by step process to reproduce
the bug and if need we can add screenshot. Developer should easily
understand what the bug is and how to reproduce it.
Status: this is the last field, here we need to write the status of
the bug. Bug goes through different status. Like when tester finds a bug
then that bugs status is new. When assigned to developer then its
status will be assigned. Other status are Duplicate, Deferred, Fixed,
Closed etc. You will get detailed knowledge about this status in Defect
life cycle.

Incident report in word file is looks like as shown above.

Software Testing Life Cycle (STLC)

Software testing is not like taking the software and start testing it,
Software testing is not just a single activity its set of activities which
need to be performed step by step to ensure that the software is Bug,
Defect free.
Software testing has six different phases, we can also called it as the six
task or six activity that need to be performed. And those six tasks
areRequirement analysis, test planning, test design, test
environment set up, test case execution and test closure.
We are going to look each phase step by step and you get know about
the Software testing process.

Requirement Analysis : Here from the phase name you might have
got some idea about this phase. Here testing team gathers as much as
possible information about the software which they are going to test.
Its obvious if the testing team have good knowledge about the
software then they can test it very well.
So testing team collect the information from software specification
document (SRS) , business document and if testing team requires more
information then they contact to developer, Technical leads, business
analyst and even client also. The main aim of this phase is to get clear
requirement of the software.

After collecting all possible information about the software then

decides which type of testing is requires for this software and also
testing team check the testable requirement and automation testing
feasibility.
Test Plan : everyone knows the important of the planning. In testing
planning is also very important to ensure smooth progress and meet all
the deadlines. a senior manager or manager by considering all the
points/ artifacts create a plan. In that plan they specify many things like
when roles and responsibilities of testing team members, scheduling,
cost , which part of software is to be tested and which part of the
software has to leave, testing tools , etc. you will get more details on
test plans and its artifacts in next coming articles.
Test Design : third phase is test design, here tester actual develop the
test cases in case of manual testing and if they have to perform
automation testing then here tester creates the test script which then
executed against the software.
Tester after reading and understanding the software requirement,tester
writes the test scenarios based on requirements ,then tester write the
test cases and then at last tester creates the test data (test data can be
provided by the client also). To understand this let take a example,
suppose we are testing the software which consist the student creation
form so in this case adding the student is our test scenario and filling
the form with valid data, invalid data, trying to fill the form with digit,
trying to save the form empty etc would be our test cases and Test data
would be like name :chiragnbansod , mobile :900000***** etc would
be our test data.
Test Environment Setup : Every software is developed by considering
hardware and software requirement. You might have seen in

government sites at the bottom there sometime a message it written

like this site is based viewed in internet explorer and resolution of
something like 136 x 768. Or in many heavy applications they indicate
the minimum hardware and software requirement like Photoshop,
heavy games etc.
In this phase, according to requirement they configure required
hardware and software. Tester may or may not involve in setting the
configuration. Sometime client provide the configuration.
Test Case Execution : when a software or a part of the software is
made available for testing then tester has to execute his written test
cases against the software which they have written during the Test case
design phase. Tester execute the test cases, check the response of the
software and verify the response of software whether is it as expected
or not.

After executing each test cases tester verify the output and if that
output is not as expected then it means that the test case has failed and
a bug has found then tester report that bug to team lead. Then bugs
will be reported back to the development team for correction and
retesting will be performed.
Test Closure : this is the last phase of software testing life cycle. This
meeting is conducted after testing and releasing of the software.

Here during this phase, all the testing team meet and discuss about the
software and the issues those they faced during the testing. Also they
collect all the testing artifacts (documents). This meet up will help the
testing team to improve the testing process and if they get same kind of
software for testing then they may refer this artifacts which have
collected.

Software Development Life Cycle

Software Development Life Cycle (SDLC) contains different phases /
step that need to be followed to develop a quality software. Means in
simple word if you want to develop quality software then you need to
follow these steps. IT farms follow such type of model to develop their
software, it guides from start to end.
It has six phases and each phase is depends on its previous phase.
Means this need to be executed in sequence, we cannot take any
random phase and start working on it. This phases should be followed
sequentially.
There are six phases

Requirements Gathering

Analysis and Design

Implementation

Testing

Deployment

Maintenance

Requirement Gathering :

Requirement means the information about the features and functions

of the software. You will rarely find any software that has no use or a
software that do nothings. Each and every software has some work to
do.
When client wants any software then he will have some basic idea
about what is he wants in his software. for example if client want to
build the shopping site then his requirement would be like there should
be login option, there should be search option to search the product ,
there should be online payment option etc. these all are the
requirements.
Analysis and Design :
In this phase of SDLC,Development team start designing the software.
they decides all the things which are going to needed in this
development process like which language would be efficient,
database ,architectural design etc. all this things decide in this phase.
They do high level and low level design in this phase.
High level design means basically designing the overall architecture,
database, required flow charts,and data flow all this is done under high
level design.
Low Level design is like component level design. Detail design and logic
of each and every component of the software is done under low level
design.
Implementation (Coding) :
Actual coding start in this phase. Developer develop the logic as per the
requirement and other things like selection of the programming
language and databases are already done in previous phase that is
Analysis and Design. Development is done module by module.
Development work is divided among the all developer. This is longest
and important phase of SDLC.
Testing :

After the coding, testing is done to ensure that software is developed as

per the requirement and behaving as expected. Here Test team test the
software application against the requirement. Test team need not to
wait until all the software get developed test team start testing module
wise. When one single module is developed then that comes to tester
for the testing. If you dont know the term module, a then module is
like a part of software. it is also called as the build. E.g. in e-commerce
site, there are many module like login module, cart module, searching
module etc. if login module is ready then they send module for testing.
They do not wait for all the module.
When Test Team get a two, three modules for testing then test team
performs Integration Testing. When test team get whole software for
testing then they performs System Testing.

Testing has its full life cycle which is known as Software Testing Life
Cycle (STLC).STCL has six phase, first is requirement, here they gathers
all the information about the software, then second phases is planning,
test team need to plan everything so that they will have a specific goal
to achieve, third phase is Test Design where test team writes the test
cases, fourth phases in Environment Set-Up, the hardware and software
on which test team is going to install Software for testing. Then fifth
phases in Test execution, test team execute written test cases, and the
last phase is Test Closure where all the document is collected for the
future reference.
Deployment :
Once the Software is developed and tested and found working as
expected then client check the software. Whether all the requirement is
implemented in software or not and it should fulfill all the business
requirement of the client. This thing is tested by client and real world
user. Basically this all happen in last phase of testing which is known as

User Acceptance Testing (UAT) then that software has to Deploy at the
clients side or need to release in market as per the type of the
Software. This deployment process is done in this phase.
Maintenance :
This Phases is for following purposes

Sometime client forget some requirement then that requirement

is implement in software during maintenance.

Some extra feature that client wants in his software that is also
done in maintenance phase.

Sometime major/minor bugs are not found during testing phase

and those bugs if found by clients end then that bugs fixing is also done
in this phase.
Note: For any queries, corrections or any improvement.Please feel free
to comment below.

What is verification?
Verification is also known as static testing. General flow of software
development is, developer develop the software as per the requirement
document. But what if there is an ambiguities in requirement
documents? What if the requirement is not complete? There are many
possibilities. If by ignoring all the possibilities. And developer keeps on
developing the software according to these documents then more likely
there will be a lots of bugs in software. These bugs will be discovered
in testing phase and they report it to developer. As we know that bug
found is lateral phases is more costly to fix and more time consuming.
If we do verification early in development life cycle then it would not
bring so many bugs in software. It will reduce the number of bugs.
If there is a bug in requirement specification then that will definitely
bug reflects in developed software. likes its an cycle if there is
ambiguities in business requirement then that will come to
requirement specification then that will further come in developed
software. And there ambiguities may arise different issues in software.
So it is very needed to do verification testing / static testing.as I said if
there is an ambiguities in business requirement then that will come in

requirement. But it is not necessary that the ambiguities or defect

always present in business requirement. Sometime even business
requirement is correct and does not have any issues then also in
specification requirement there is chance of ambiguities and defect. So
it is necessary to do a verification testing on each phases of
development.
The code, function, logic written by developer is also need to be verified
means verification testing needed there also.
As a basic idea about verification, a verification is like asking your
colleagues, youre senior to verify the documents, code that you have
made. Then your colleagues, senior provides a comment on your
document which could help is improving the document, code that you
have written. There are different type of verification. Some of the type
of verification requires planning and some of them doesnt require
planning.
There are two categories of verification testing / static testing.

Static analysis

Review - Formal Review, Informal Review.

Static Analysis :
In static analysis the code written by the developer is analyzed for the
structural defect which may lead to defect in future.
They analysis the code try to find out : variable with undefined value,
variable that is defined but never used, dead code, commented code
and also check the whether the code is written as per the industrial
standards or not etc.

Review : Formal Review

Lets first understand who involves in formal review (Participant of
formal review).

Moderator : This is a person who is responsible for meeting and

scheduling.

Author : Author is a person who created the documents, codes

etc.

Scribe : The defect logging work is done by the Scribe.

Reviewer : Check the document under review.

Manager : Manager is a project manager.

These all persons take a park is formal review.

Process of formal review is as follows:

Planning :
The review process being with a request of Review which is
made by the author to the moderator.
Then moderator do an entry check to insure that the document is
ready so that the time will not waste of reviewer.
If the document found ready Then moderator has to arrange the
review meeting, moderator is the person who have to take care of
scheduling like date ,time , place and invitation.
Kickoff :
In This phase the reviewer get the short introduction on the
objective of the Document under review.

And the relationship between the document under review and

other document is also explained.
Preparation :
This is step where reviewer individually review the document
under review using the related document, procedure and check list that
is provided to them provided.
While reviewing the document , they identifies the defects ,
questions and comments on the document accordingly there
understanding of the document and roles.
After this they log all the issues in the logging form.
Review Meeting :
This Review Meeting is further divided into three phases.
Logging Phase : In this Phase, the Defect identified and
comments in Preparation step is logged this is phase. This logging of
defect and comments is done by author or scribe
Discussion Phase : this is a second phase of Review Meeting step,
here in this phase if there is any part of the document that need to be
discussed that part is discussed in this Discussing Phase and the
reviewer can take part into the discussion by bring forward there
comments and the reasons, and the outcome of the discussion is
documented for the further reference.
Decision Phase : this is the last phase of the Review Meeting, in
this Phase reviewer has to take the decision on the Document under
review, and this Decision is based on the Major defect found in the
document for e.g. if there is more than three major / critical defects are
there then this document has to reviewed again after rework.
Rework :
If the defect that has identified during the review crosses the
certain level then that document has to be reworked by the author to
resolve the defect.
Author not necessarily solve the all the defect, its authors
responsibility to judge which defect should solve and which defect
should leave.
Follow Up :

In this step the moderator check whether author has taken

necessary action on all the known defect.

After rework of author finishes then it moderators responsibility

to circulate updated document to the participant and collect feedback
from them.

It is moderators responsibility to ensure that the information is

correct and stored for the future analysis.
Review : informal Review
Second type of review is informal review.

Main different between formal review and informal review is,

informal review is not a planned review. Here an author go to their
colleagues and ask for review on document. The author listen the
review and comment from their colleagues and if they have valid point
then the author consider the suggestion.

Advantages of Software Verification :

Verification helps in lowering down the count of the defect in the

later stages of development .because most of the bugs come from
incomplete requirement or incorrect requirement.

Verifying the product at the starting phase of the development will

help in understanding the product in a better way.

It reduces the chances of failures in the software application or

product.

It helps in building the product as per the customer specifications

and needs.

V-Model (Verification and Validation

Model)
V-Model is software development model and V-model is also known as
Verification and Validation model. It is basically extension of waterfall
model but unlike water fall model here in V-model, testing is done
simultaneously with the development phase. The main disadvantage of
water fall model i.e. the Testing Starts after Development ends. But in
V-model the testing start early in life cycle.

The left arm is known as verification and Right arm is known as

validation and the whole diagram is looks like V shape so it is called as
V-Model. The V-Model phases are as per follows.
It is also called as Left arm is static and right arm is dynamic arm.
Business Requirement Specification (BRS) :

This is the first phase in the development cycle where the product
requirements are understood from the customer perspective.

This phase involves detailed communication with the customer to

understand his expectations and exact requirement.

This is a very important activity and need to be managed well, as

most of the customers are not sure about what exactly they need.

The acceptance test design planning is done at this stage as

business requirements can be used as an input for acceptance testing.

Software Requirement Specification (SRS) :

A Software requirement specification is a document that capture

complete description about how the system is expected to perform.

And it is a detailed requirement of the application.

This is also a very important part because most of the bugs in

software is due to incomplete or inaccurate functional requirements.
The software code does not matter how well its written, cant do
anything if there are ambiguities in requirements.
The team studies and investigates on how the requirements could
be implemented.
The System test design planning is done at this stage as Software
requirement can be used as an input for System testing.
Once you have the clear and detailed product requirements, its
time to design the complete system.
This Phase focuses on system architecture and design.

It provide overview of solution, platform, system, product and

service/process. An integration test plan is created in this phase as well
in order to test the pieces of the software systems ability to work
together.

With this phase integration test planning is done.

Low Level Design (LLD) :

Phase is where the actual software components are designed. It

defines the actual logic for each and every component of the system.
Class diagram with all the methods and relation between classes comes
under LLD. Component tests are created in this phase as well.

Simultaneously unit test design planning is done.

Coding :

Till this phase all the planning has been done. Here the developer
start building the application according to requirements.
Unit testing :

This unit testing is performed by the developer.

Here developer test their program code, functions, classes,

procedures, to verify that they are all are working as expected.

The unit test cases which are created during the low level design
is executed.

These tests are executed by the developer to validate the

functions developed by him.

And to locate a bug developer uses a debugging technique.

Bug fixing is less costly and easy in this phase.

If developer eliminates or do unit testing in a proper way then
there is a less chances of bug in his developed module.
If testing team found a bug in lateral stage then the bug fixing
would be more costly time consuming so this thing can be avoidable if
developer do unit testing properly.
Integration testing :
The module, component tested alone should be also work when
they connected together.
Sometime the module work fine when tested alone but when we
integrate it, its shows error so we need to ensure that the module when
integrates together should also work fine.
Basically we need to test the data transfer between the several
modules. To ensure that the data transfer between this modules is
happening in proper way.
There four type of integration testing.
1.
Bottom up Integration testing.
2.
Top down Integration testing.
3.
Critical Part First.
4.
Big Bang.

System Testing :
The actual and full fledge testing of the application takes place
here in system testing
In system testing the behavior of whole system/product is tested
and find out whether system is working as expected or not.
In this phase all the system test cases, functional test cases and
nonfunctional test cases are executed.
System testing is carried out by specialists testers or independent
testers.
System testing is most often the final test to verify that the system
to be delivered meets the specification and its purpose.
The system testing comes under black box software testing. So,
the knowledge of internal design or structure or code is not required
for this type of software testing.
There are different testing techniques are used in the System testing :
1.
Functional testing.
2.
GUI testing/Usability testing.
3.
Security testing.
4.
Performance testing.
User Acceptance Testing :
UAT testing is performed after the system testing and UAT testing
happens before releasing the software in a real environment.
User acceptance is a type of testing performed by the Client to
check if the system is built to match the business requirements of the
organization.
UAT testing is important Because, Developer read the
Requirement Document and based on his own understanding
developer develop the software which may not actually be what the
client needs from the software.
UAT testing happens before releasing the software in a real
environment.
There are two types of UAT testing - Alpha Testing and Beta
Testing.

Waterfall Model
Waterfall model was the first software development model. It was used
by many software organization to ensure the quality development of
software. Now a days not many companies use this model. It has its
own advantages and some disadvantages. There are many models
which is just improved version of the waterfall model.
Waterfall model has six phases and which should be followed in
sequential order means next phase cannot be started before current
phases is completed. This put the company in trouble if clients changes
his requirement in later phase. So they need to make change in each
phase to overcome this there are other client oriented Software
development models are there like iterative, incremental, agile etc.
those model are more client oriented and very compatible to
requirement changes.
Water fall model is as shown below:

It has six phase: requirement analysis, system design, and

implementation, Testing, Deployment and Maintained. You might have
seen these phases in other development life cycles. Those are just
revision of waterfall model, just some improvement is there.
Let me explain you each phases one by one:
Requirement Analysis :

Requirement analysis means the requirement of client is listened

here and document here. What client want what are their exact
expectation this everything is listened here and documented here.
This phase is important, here all the clients requirement should
be noted well. Many client does not know what he wants. Client has
only basic idea of the software.
This requirement gathering from client is basically done by
business analyst.
System Design :
Once first phase is completed then we need to proceed for
second phase which is System Design.
Here the Requirement which is gathered in first phase is usedas a
input and system is designed as per the requirements.
High level design and low level design is done in this phase
basically architecture, data base design, component level design is
done in this phase.
Implementation :
Coding of the software is done in this phase and System design
phases is taken as a input for this phase.
Developer apply his logic to satisfy and fulfill the requirement.
Testing :
Once the development is done then its time for testing the
software. Here testing of the application is take places.
Here required testing done, it may be functional testing, security
testing or performance testing etc. depending on the scope of the
application tester performs testing activity in this phase.
Discovered bugs is reported and then retesting is done.
Deployment :
Once the software is developed and functional and non-functional
testing is done and found well working then its time for delivering that
software to the client or making that software live and made available
for the user.
Maintenance :

Maintenance is the phase which comes after deployment. Here

the bugs found at the clients end is resolved

Sometime clients wants new change to its software or client want

to add new functionality to his software then that is also done in this
phase.
In this way waterfall model works. Top down like water falls and it is
also called linear-sequential model. Each phase need to be completed
to start next phase. Unlike other model here testing start after the
development completed so tester have to wait till software completion.
Which is not good for company as tester dont have any work to do.
Advantages :

This is simple model no complexity is there so it is easy to

understand.

Each phase is well planned. And has specific goal to achieve.

It is good for little project but not good for bigger once.

Easy to manage.
Disadvantage :

Not good for the bigger projects because changed requirement

effect on each phase.

Testing is started after development.

Not compatible for continuously changing requirement projects.

Not a client oriented model.

Integration Testing and Its Types

You might have heard about Integration Testing in V-MODEL, right arm
is dynamic arm which have level of testing phase those are Unit Testing,
Integration Testing, System Testing and UAT. Many of you might have
these questions like what is integration testing, who performs
integration testing and what is difference between integration testing
and other type of the testings. After reading these article you will have
clear idea about integration testing.
Any Software has many module in it for example an ecommerce site
have these modules: login module, searching module, cart module,

invoice module and payment module. another example if we take

suppose for education site it has login module, Enquiry module,
Registration Module, Receipt Module, Library module etc. so while
building these software the organization does not build every module
simultaneously they build it step by step but if organization have a
bigger development team then they distribute the developer on
different modules. In education site they build login module first then
they build enquiry module then registration module like that.
So every built module is tested alone in unit testing but they need to
integrate with other module and there is a chances that the module
which is tested alone can show error when integrated with other
module. You may have question here why we need to integrate it with
other module? So to answer this question lets take an example, one
student came and we made his Enquiry in our education software after
few days his joined our class then that created enquiry marked as
converted that data should come in registration for the registration
process, so here Enquiry and Registration are different modules but
there is data transfer between these module if you found this example
tough then other can be suppose you create a mail and sent it then that
mail goes to intended recipient and also goes to oursent module also.
So data transfer between mails creation module and sent module.

What we basically try to test in Integration Testing is, one module

sending data to other module and logical dependency also need to be
tested like some module depends on other module, some module cant
start before other module completes. Integration Testing is also be

done between software under test and external devices like printer, fax
machine etc.

Types of Integration Testing :

Bottom Up Integration Testing.

Top Down Integration Testing.

Critical Part First.

Big Bang Integration Testing.

Sometime the module who are bottom in the hierarchy that gets ready
but the top module is still in development phase or vice versa situation
can be there if you dont understand this let a example, top module
means starting module or the first module like in ecommerce site login
module will be top module and cart module, payment module etc. are
the bottom module, so in this cases we cant wait still the module get
ready. They need to start testing as early as possible. So in such a
situation these integration testing types areuseful.
Bottom Up Integration Testing :
When bottom module is ready but top module is not ready then we use
Bottom Up Integration Testing. Here we make a dummy temporary top
module and we called it as a Driver module.And this module calls
bottom modules so it is also called calling module and call means
nothing but sending data. For example if we have registration module
but enquiry module is in development phase then we make dummy
driver module which will work as an enquiry module.

Top Down Integration Testing :

When top module is created but bottom module is in development

phase, at such a situation we use Top down integration testing. So in
place of bottom module we need to create a temporary called module
which we called Stub. Called module means another module send the
data to this module. The module who sends a data or any request is
called calling module and those who called by other module is called
calling module.

Critical Part First :

In this type of Integration testing, the module which are related to core
functionality of the Application only tested. Because some time we
dont have much time for the testing then we need to prioritize the Test.
For example, ecommerce sites core module would be search module,
add to cart module. and payment module are the few core modules
and updating display picture , editing the hobbies these are the less
required fields for the ecommerce site.

Big Bang Integration Testing :

In this type of integration testing, all the modules integrated once and
testing is done on the modules. There are some disadvantages of this
type of integration testing, sometime if we find a bug then it is difficult
to find the module on which the bug is present.

System Testing
We know that in unit Testing a single program, single function, single
module is tested and after that a integration testing is comes where We
Testers test the integration between several modules and we need to
ensure that there is proper data transmission and proper
communication happening between the modules. And after integration
testing we performs System Testing.
When whole Software is ready and integrated together then we need to
perform the System Testing on the software and ensure that everything
is working as per the requirements. Here not only the functional
requirement is tested but also the non-functional requirements are
tested. System testing is carried out by the testing team and to test the
non-functional requirement testing a specialized testing team is
needed. For example to perform a performance testing then
performance testers are needed. Same with security testing, to perform
a security testing a security testers are needed.

Understand one thing, in system testing we do not perform all the

functional testing types. We only perform functionality Testing,
Regression Testing, Retesting and smoke and sanity testing, dont get
confused with the diagram. And in case of non-functional testing, we
always not need to perform all these shown testing types, its totally
depends on the clients requirement, but like a eCommerce site it is
needed to perform a performance testing on it, because when there is
a special offer or any sell is going on eCommerce site then a heavy
traffic is expected. and other types of non-functional testing like
security testing is need to be conducted on Banking software, because
in banking application data of user should be secured, data loss from
banking application can cause a huge money loss so it is needed to
perform a security testing on banking application.
First step of system testing is making a Test plan for the system testing.
Here all the planning is done like resources, roles and responsibility of
every testing team mates, then type of testing that is need to be
performed (both functional and non-functional), scheduling the test
activity etc. all things need to be planned.
Once System test plan is ready then second step is to write the test
cases, unlike v-model we dont write the test cases parallel to the
development phase. Test cases is written against the requirement and if
any functionality is difficult to understand then the tester may
approach the developer, business analyst or the manager or even client

also, to get the answer of all the queries. Once the Test cases writing
work is done then its time to execute them against the Software. Here
tester need to write the test cases for each and every requirement.
Here we are going to test whole software not a particular part like unit
or integration testing. And if there is a scope of automation testing then
that the test script is created as per the scenarios and requirements.
After writing the test cases to all test cases are executed against the
software. The bugs found during testing of whole software are reported
to developer. After bug fixing sanity, retesting and regression testing is
done.
There are also test cases written for the non-functional requirement
also .for example, for eCommerce site suppose there is one
requirement say software should able to handle 5000 concurrent user
simultaneously for 1 hour. So to evaluate this requirement testers need
to perform different performance testing type example:Load Testing :
here the software is subjected a 5000 concurrent user for an 1 hour,
and in Endurance Testing : the Software is subjected to the 5000
concurrent user but the time is extended form 1 hour to server hour
even whole day. And in Stress Testing : here the main aim is to break
the system, tester increase the user limit from 5000 to 7-8000 even till
the break point and time is also increased in this performance testing
type and lastlyVolume Testing : when the database is almost full or
have lot of data then that might affect the system and it make slow
down the system so that is also need to test how system performs
under the heavy data. With the similar way the security and other nonfunctional types of testing is conducted by the specialized Testers.
Based on the scope.
Main Points :

System Testing is performs after the integration testing.

System Testing is performed on fully integrated Software.

In System Testing Functional and Non-functional both the aspect

is tested.

To perform non-functional testing a Specialized Testers are

requires.

What is Retesting and Regression

Testing?
When I started learning Testing at that time I was often get confused
between these two terms Retesting and Regression testing. So many of
you who are new or just started their career in testing field may be
going through the same situation.in this article I am going to explain
these two terms like when to use them and how to use them. You will
get all your answer after reading this article. Lets start with Retesting.

RETESTING :
Some of you may get confuse with the name Retesting. You may think
testing means testing the software first time and Retesting means
Testing same Software for second or multiple times. If you think in this
way then you are completely Wrong.

So to understand about Retesting lets consider one scenario. You are

working in a company as a Software Test Engineer and you have to test
one software so you wrote say 1000 Test Cases and you executed all.
Out of 1000 suppose 50 test cases failed (failed means actual output of
the software doesnt matched with expected output). So you will
repost 50 bugs to Team Lead and Team Lead verify it and assign that
bugs to developer and developer will resolve all the bugs by making
some code fixes.
Once the bug is resolved from developers end then that software again
comes to you to verify whether developer really fixed those 50 bugs
which you have reported. So how will verify that those 50 bugs really
solved by developer? Obviously you will execute all those 50 failed test
cases again. This is known as retesting. In other word Retesting
means executing those failed test cases again to verify that the
bug is really fixed.
In short, total 1000 test cases. 950 passed test cases and 50 failed test
cases in this situation Retesting means testing those 50 failed test cases
again.
REGRESSION TESTING :
There are many occasions where we need to use Regression Testing.
Basically when any changes are made in the software we need to
perform Regression Testing. So there are many types of changes that
can be done in software. Lets consider one by one and how to perform
regression testing in that situation.
Scenario one : take above example. You have 1000 cases and you
executed all and out of those 50 failed and 950 passed. When
developer fixes the code then you perform Retesting on those failed
test cases. But what about those passed 950 test cases? We need to
execute those again also to check that there is not any bug arises due
to code fixes. What developer do when they get a bugs, they make
some adjustment in code change some logic and try to fix bugs. But this
can cause a bug in other working functionality. Means any passed test
cases may fail due to this code fixes so we need to do regression testing
to ensure that there is not any impact of code fixing on the

software.Overall: we have 1000 test cases, 50 are failed, on failed test

cases we performretesting after bug fixing, and 950 passed test cases
we performs regression testing after bug fixes.
Scenario two : when client want to add new functionality to his predeveloped software, at that time new functionality need to be
integrated with the software these may cause any bad impact on the
software so we need to perform integration testing on overall software.
Scenario three: as we know client may change his requirement at any
given point of time. So to satisfy the new changes made client
developer has to change their logic and their code. After developer
change the code we need to perform regression testing on all
previously passed test cases.
Scenario four: when client want to delete any functionality from his
software. So accomplish this developer team have to face many
changes like in software many modules are interdepended. Means they
are interconnected to each other. If any such interconnected module
has to be removed from the software then the module which are
depended on it may behave unexpectedly.so after removal of particular
feature we need to check whether all remaining features are working
fine or not.so we perform regression testing on those modules.
In short: we use Regression Testing in following occasions:
Bugs Fixes.

New Functionality addition.

Any functionality removal.

Any Requirement changes.

Performance enhancement.
On all above situations we need to perform integration testing.
In regression testing we know that we executed all passed test cases
but do we execute all the pass test cases? well there are many criterias
which help to decide the test cases means whether we have to execute

all the test cases or we are going to execute the test cases which are
related to core functionality or a test cases for a particular modules.
Retesting means checking affected part and Regression Testing means
checking unaffected part affected.

How to create a test plan for software

testing
Before the testing activities start, we need to have some goal in our
mind so that we can achieve them. Product testing, product
development both are time bound activities and we need to ensure that
the activities should complete in time. And more time means more
cost. So planning plays very important role to complete the activities in
time.
Test Plan is a documents which is plans all the testing related activities
like when to start testing, when to stop testing, and roles and
responsibility of each and every testing team member and many more
things.it also tells us the effort needed to validate the software. So lets
look one by one each activities.

Test Plan Identifier / ID : here something unique name is given

to the test plan so that it will become easy to identify. And also version
number. When there is some change made in test plan, version of test
plan is also need to be changed.

Introduction : here the description of the software is mentioned.

The idea behind the software the domain to which software is related.

Test Objective : Here the guideline which is helpful for testing

process is mentioned. Like testing strategies and the tools used for
testing the software.

Test Scope : here the extent of testing is defined. Like which

feature are to be tested and which are out of scope
1.
Features to be tested : here always we tester need not to test
each and every functionality of the application. Sometime some feature
is not need to test now they may need to test in future but not now.
Here the list of the feature, modules are provided so we only test these
features and modules.

2.
Features not to be tested : here the features that is out of scope
is mentioned here means the feature which we need not to test is
mentioned here.
Roles and Responsibilities : here description about the tester
and their task is mentioned. So that each team member know what he
has to do.it makes clear vision.
Risk Analysis : Risk Analysis mean analyzing the future risks that
may occur and effect on testing activities.in simple word, while testing
which problems can occurs and how to face if any particular problem is
occurred. But it is not necessary that the problem will occur. Its just a
probability.
Test Strategy : Here which type of testing need to be performed
is mentioned here. Like which method is need to be used to test this
particular software whether it should be Black box testing or white box
testing or a combination testing required. Which level of testing is
required like unit, integration or system etc. this depends on software
completion. If software is partially completed then integration testing in
performed and if full software is ready then system testing is
performed.Other thing mentioned here is how many number of test
execution cycles need to be executed and data collection and creation.
Entry Criteria : When to start the testing is mentioned here, like
when the test data , test cases and test environment and software
under test is ready then we can start the testing. such a condition is
mentioned here.
Exit Criteria : When testing need to be stop is mentioned here.
Like when all the test cases is executed. Such a condition is mentioned
here.
Suspension Criteria : when a major bug is found and because of
that bug further testing cant be continued then testing activity need to
be stopped. so such a suspension criteria are mentioned here.
Resumption Criteria : Here after Suspension of Testing when we
need to resume testing is mentioned here. For example, if testing is
suspended because of the major bug was found while testing then
Resumption Criteria will be, Testing can start after fixing of the major
bug. In short when all the suspension criteria are resolved then we can
continue with testing process.

Test Environment : the Hardware and Software requirement of

the software under test is mentioned here.
These are the fields in the Test Plan. You may find some more field or
some less field, this fields vary organization to organizations.
Performance Testing of Web Application

Performance testing is very important especially when its come to the

business point of view. You may have seen these things when you surf
the internet, like you click on the site and the site is continuously
loading and loading, you searched something and the result take 5-10
minutes to display on the page, sometime an error page occurs that the
connection time out or the server is busy please try after sometime.
So these things make you irritated and force you to switch other similar
kind of websites.

Under performing application can cost your business loss also, consider
a scenario, you want to buy a book which is available on X Website as
well as on Y Website with the same price so you visited X

Website first and searched the book and it taking so much time to show
the result. Meanwhile you opened Y Website and searched the book
name and it shown you result within the seconds and you added
the book in cart and purchased it whereas the X Website is still loading
the result. Here the person who thought to buy a book from the X
Website but because of the poor speed and response it forced him to
switch Y Website means there is a business loss for the X Website. This
tell us how important performance testing is.
In application not only the functions, UI and features are important but
also
the
other
aspect
like
Performance
has
equal
important.Performance testing the non-functional testing type. In
performance we do not find the bugs. We test the speed, response,
scalability and stability under changing workload.
Main focus of Performance Testing is on following aspects:
Speed of Application Under varying Workload : Traffic on Application
is some time low sometime high, under these changing workload
application should not get slow. On low traffic application may run fast
and on high traffic it may get slow.so this things are tested and try to
eliminate the causes.

Scalability of the Application : Scalability means the maximum user

workload that can application handler. Every application has its
limitation. In scalability we test the maximum number of concurrent
user that can application easily handle without losing its speed and
response.
Stability of Application Under varying Workload : Application may
behave unexpectedly under changing user load. Application should
behave expectedly under changing work load. Once the X
Website announced the big billion day, on that day the traffic was huge
on X Website and it was continuously varying due to this many user
faced many problems. And X Website site started crashing due to the
heavy user load. Application should not get crashed, should remain
stable under such a varying load.

These are the key aspect which need to consider while testing the
Application. There are many reasons which can make application slow
like badly written code, sometime developer user a heavy which are not
need that cause the time delay in producing the output and other
response are hard issues which can also effect on softwares
performance.

There are many types of Performance testing, some of those are

explained below.
Load Testing : If Application is supposed to handle 10000 concurrent
users for hour. Then load testing means subjecting 10000 concurrent
user for hour and verifying the behaviors of the application.
Endurance Testing : Our application is supped to handle 10000
concurrent user for hour, so in endurance testing, an application is
subjected to 10000 concurrent user but the time duration is increases
from one hour to many hour. To verify the whether application can
handle expected load for longer duration. Main difference between
Load and Endurance testing is time duration.
Stress Testing : Our application is supped to handle 10000 concurrent
user for hour, so the Stress testing would be exceeding the user limit
from 10000 to its break point and the duration is also increase till the
break point of the application. Here main aim is to break the system
and find max user load that the application can handle.
Volume Testing : When there is lot of data in database then software
may slow down because fetching and searching from heavy flooded
database take time. In volume testing the database is full filled with
data and then we check the speed and response of the application.

Spike Testing : We cant predict the user load on application, it may 10

user to it may 10000 of user on application. In spike testing, we rapidly
rise the user count and we rapidly decrease the user count and check
the behaviors of the application.
The tools that is useful for performance testing are Jmeter,
Roadrunner, HTTP load, Proxy snifer and Silk performer etc.

User Acceptance Testing (UAT)

User Acceptance Testing is done before Software goes live or is ready to
go to the real environment. Means User Acceptance Testing is done at
the last stage and this testing is done by client or real user who are
going to use the software as in V-model first phase is Business
requirements and corresponding testing phase is UAT testing. Means
business requirement is taken as the input for this testing and check
whether all documented business requirements satisfied by the
software or not.

User Acceptance Testing is done at the last stage means it is done after
unit testing, integration testing, System Testing then User Acceptance
Testing is Performed. You may think that what is the need of the UAT
testing? If we have performing unit testing, integration testing, system
testing then why UAT testing is needed and one more thing we Testers
are professionals we know how to test the software. But the aim of UAT
testing is not to find the bugs but just check the software against the
business requirements, business flow. And who can tell us better than
the client itself.
Means the client and user check the software for Business flow. They
check whether all business requirements are satisfied or not. While
performing the UAT testing they neglect all small bug like UI bugs,
spelling mistakes.

Why UAT is needed? Below are few points which tells

us the importance of UAT testing?
Software Building process starts from requirements gathering, our
companies business analyst goes to the client and listen the client
requirements and write them down as per the business analysts
understanding. There is a chances that the business analyst
understanding and the actual requirements of the clients are May
differs. And further process is totally based on requirement documents.
This may affect the business requirements.
Even if the Business analyst documented the requirement properly
then it is depends on developers understanding of the requirement,
developer may misunderstand the requirement and develop the
software. This is also interrupt the proper business flow of the
Software.And same thing may happens with the testing team also. At
the initial stage client may be confused about what he actually wants.
So once client get some idea or when any requirements comes to his
mind then client contacts to the organization and tells his requirement
means clients sometime changes his requirements very frequently. And
if those requirements are not communicated properly with developer

then this may

requirements.

cause

difference

in

business

flow/

business

When to perform UAT Testing?

At the last stage before the software goes live or made available
for users

UAT performs after Unit, integration, System testing.

UAT testing is performed when all the measure bugs are fixed

UAT Testing is performed when fully integrated and bug fixed

software is available.

Types

of

User

Acceptance

Testing

There are two types of UAT testing

1.

Alpha

Testing

Alpha testing is done at developers environment where developers are

present during the Alpha Testing. Alpha testing is performed by real
users / clients and developer or QA team may or may not involve in
Alpha testing, when user are using the software then developer looks
they activities and if user has some Queries then developer explain
them. After the testing user gives feedback about the software. And
suggest changes. If developer think any change is require then change
that particular functionality to make it more user friendly and correct.

2. Beta Testing
After the alpha testing beta testing is performed. Main difference
between the Alpha and Beta testing is Beta testing is performed at
clients side in clients environment (which is the real environment). Few
real user test the software in real environment without any help of
developer. Means there are not any developer or QA member involve in
Beta testing. It is fully performed by users. This testing is usefully to get
market response of the software. And the issues that the user faces
during beta testing is communicated with the developer and if needed
they make the changes in the software.

Bug Severity and Priority and their

examples
Severity and Priority are related to the defect like when a tester finds a
bug, the bug may be the huge bug of small bug. As a tester we should
be able to find out whether bug has major impact or small impact on
the system so that as per the impact of the bug, developer can consider
which bug solve first , many tester are get confused while selecting the
Severity and Priority. The Severity is selected by the Tester and Priority
is selected by the project manager or developer and sometime tester
also involved in it this activity.
Lets understand the meaning of the Severity and Priority one by one
and how to find out the severity and priority of the bugs/defects.

Severity :
Severity means the impact of particular bug on the software. Impact
may be small one or major one. How that particular bug, impacts on
the functionality of the Software is tells us the Severity of the bug. For
example. Lets say you are testing a social networking site and first is
login when you tries to login in by entering the password and username
then software crashes this mean the impact of bug is major on the
system so severity will be high and say you have found a spelling
mistake then severity of that bug will be low.

Severity of the defect can be marked in five types

Critical

Major

Medium/Moderate

Low

Cosmetic
1.)
Critical
:
A bug can be marked as a critical when software is not installing or
software data is getting corrupted. Such a huge issue which has a very
critical
issue
in
software.
2.)
Major
:
A bug can be marked as Major when there are issues like majors part
showing issues because of that we are unable to proceed testing
further. Issues like login is not working, after doing anything we are
redirected to a blank page. Means an issue which has a major impact
on the software and normal working flow is getting interrupted be that
bug.

3.)
Medium/Moderate
:
We can mark a bug as a Medium or Moderate when a functionality of
the software is working but generating a wrong result, working but
working as unexpected. The output is not matching with the expected
input but system is generating some result.such a type of bug can have
Medium
/
Moderate
Severity.
4.)
Low/Minor
:
A bug which does not cause any termination of the system, which does
not cause any undesired or wrong result generation is called a low or
minor bug. Means bug is there but the impact of the bug on the system
is not high. Example of such a bug is a small spelling mistake in content
or any small UI mistake is there such a bug can be marked as low /
minor severity bug.
5.)
Cosmetic
:
Basically this is a part of enhancement where tester suggest the
enhancement needed in the software that too only related to UI ,
Graphical
and
Text
field
changes.

Priority :
As the Severity is related to impact but priority is all about time. A time
to fix a bug whether the bug is need to fix now or in future. In simple
word priority means deciding when to fix the bug. Priority decision
depends on many factors like impact of the bug, release build
requirements.
There are three levels of priority and those are High, Medium and Low.
This
High Priority :
Means the bug which has a high priority need to be fixed as soon as
possible. A bug without which we cannot proceed our testing further
such a type of bug can have high priority, and bug is a part of current
software release and software release or build release date is far closer
then it need to be fixed as soon as possible.

Usually a bug with high severity is marked as high priority, for

example. A login system of ecommerce site is not working then that
bug is marked as high severity and high priority bug. But its not
necessary that a bug which has a high severity always have high
priority, such an example can be like there is a spelling mistake in the
companys logo. Impact of this bug is not high because it do not affect
the features or work flow but so it may give as a low severity bug but it
affect the companys image which can cause loss of revenue or
companies reputation so the priority is high for such a bug.
In simple word, High priority bugs need to be fixed as soon as possible.
Medium Priority :
A bug can be marked as a medium priority bug when which does not
affect other part of software and does not result into the termination of
the software. And to solve this bug we can wait till next build or we can
wait till next release. Like its not urgent to solve this bug. So the bug is
marked as medium priority bug.
Low Priority :

A bug which has very negligible impact on software, if its a not a part of
current release its a part of future release and does not affect any
feature of the software, like a bug which related to UI , small spelling
mistakes , grammatical mistakes.