Software Testing is necessary because we all make mistakes.

Some of those mistakes are

unimportant, but some of them are expensive or dangerous. We need to check everything
and anything we produce because things can always go wrong – humans make mistakes all
the time.
time.

Since we assume that our work may have mistakes, hence we all need to check our own
work. However some mistakes come from bad assumptions and blind spots, so we might
make the same mistakes when we check our own work as we made when we did it. So we
may not notice the flaws in what we have done.

 deally, we should get someone else to check our work because another person is more
likely to spot the flaws.

There are several reasons which clearly tells us as why Software Test
esting
ing is important and
what are the ma!or things that we should consider while testing of any product or
application.

Software testing is very important because of the following reasons"

#. Softwa
Software
re testin
testing
g is really
really re$
re$uire
uired
d to point
point out
out the
the defects
defects and
and errors
errors that
that were
were made
made
during the development phases.
%. t&s essen
essential
tial sinc
since
e it makes sure of the
the 'ustom
'ustomer&s
er&s reliab
reliability
ility and their sati
satisfact
sfaction
ion in
in
the application.
(. t is
is very
very imp
import
ortant
ant to ensur
ensure
e the
the )ualit
)uality
y of the pro
produc
duct.
t. )ua
)ualit
lity
y produc
productt deliv
delivere
ered
d to
the customers helps in gaining their confidence.
*. Testi
sting
ng is nece
necessa
ssary
ry in orde
orderr to provid
provide
e the faci
facilit
lities
ies to
to the cust
custome
omers
rs like
like the
the
delivery of high $uality product or software application which re$uires lower
maintenance cost and hence results into more accurate, consistent and reliable
results.
+. Testi
sting
ng is re$uir
re$uired
ed for an effe
effecti
ctive
ve perfor
performan
mance
ce of softw
software
are appli
applicat
cation
ion or produ
product.
ct.
. t&s
t&s import
important
ant to
to ensure
ensure that
that the
the applica
applicatio
tion
n should
should not
not result
result into
into any
any failu
failures
res
because it can be very expensive in the future or in the later stages of the
development.
-. t&s
t&s re
re$u
$uir
ired
ed to st
stay
ay in th
the
e bus
busin
ines
ess.
s.
Software Testing has different goals and ob!ectives.The ma!or ob!ectives of Software testing
are as follows"

 inding defects which may get created by the programmer while developing the
software.
 /aining confidence in and providing information about the level of $uality.
 To prevent defects.
 To make sure that the end result meets the business and user re$uirements.
 To ensure that it satisfies the 01S that is 0usiness 1e$uirement Specification and
S1S that is System 1e$uirement Specifications.
 To gain the confidence of the customers by providing them a $uality product.
Software testing helps in finali2ing the software application or product against business and
user re$uirements. t is very important to have good test coverage in order to test the
software application completely and make it sure that it&s performing well and as per the
specifications.

While determining the coverage the test cases should be designed well with maximum
possibilities of finding the errors or bugs. The test cases should be ver y effective. This
ob!ective can be measured by the number of defects reported per test cases. Higher the
number of the defects reported the more effective are the test cases.

3nce the delivery is made to the end users or the customers they should be a ble to operate
it without any complaints. n order to make this happen the tester should know as how the
customers are going to use this product and accordingly they should write down the test
scenarios and design the test cases. This will help a lot in fulfilling all the customer&s
re$uirements.

Software testing makes sure that the testing is being done prope rly and hence the system is
ready for use. /ood coverage means that the testing has been done to cover the various
areas like functionality of the application, compatibility of the application with the 3S,
hardware and different types of browsers, performance testing to test the performance of
the application and load testing to make sure that the system is reliable and should not
crash or there should not be any blocking issues. t also determines that the application can
be deployed easily to the machine and without any resistance. Hence the application is
easy to install, learn and use.
f under certain environment and situation defects in the application or product get executed
then the system will produce the wrong results causing a failure.

4ot all defects result in failures, some may stay inactive in the code and we may never 
notice them. 5xample" 6efects in dead code will never result in failures.

t is not !ust defects that give rise to failure. ailures can also be caused because of the
other reasons also like"

 0ecause of the environmental conditions as well like a radiation burst, a strong

magnetic field, electronic field or pollution could cause faults in hardware or firmware.
Those faults might prevent or change the execution of software.
 ailures may also arise  because of human error in interacting with the software,
perhaps a wrong input value being entered or an output being misinterpreted.
 inally failures may also be caused by someone deliberately trying to cause a failure
in the system.
Difference between Error, Defect and Failure in software testing:

Error: The mistakes made by programmer is knowns as an 75rror&. This could happen
because of the following reasons"

8 0ecause of some confusion in understanding the functionality of the software

8 0ecause of some miscalculation of the values

8 0ecause of misinterpretation of any value, etc.

Defect: The bugs introduced by programmer inside the code are known as a defect. This
can happen because of some programatical mistakes.

Failure: f under certain circumstances these defects get executed by the tester during the
testing then it results into the failure which is known as software failure.

ew points that are important to know"

 When tester is executing a test he9she may observe some difference in the behavior
of the feature or functionality, but this not because of the failure. This may happen
because of the wrong test data entered, tester may not be aware of the feature or
functionality or because of the bad environment. 0ecause of these reasons incidents
are reported. They are known as incident report. The condition or situation which
re$uires further analysis or clarification is known as incident. To deal with the incidents
the programmer need to to the analysis that whether this incident has occurred
because of the failure or not.
 t&s not necessary that defects or bugs introduced in the product are onl y by the
software. To understand it further let&s take an example. : bug or defect can also be
introduced by a business analyst. 6efects present in the specifications like
re$uirements specification and design specifications can be detected during the
reviews. When the defect or bug is caught during the review cannot result into failure
because the software has not yet been executed.
 These defects or bugs are reported not to blame the developers or any people but to
 !udge the $uality of the product. The $uality of product is of utmost importance. To gain
the confidence of the customers it&s very important to deliver the $uality product on
time.

 0ecause of the following reasons the software defects arise"

 8 The person using the software application or product may not have enough
knowledge of the product.

 8 ;aybe the software is used in the wrong way which leads to the defects or failures.

 8 The developers may have coded incorrectly and there can be defects present in the
design.

 8 ncorrect setup of the testing environments.

 To know when defects in software testing arise, let us take a small example with a
diagram as given below.

 We can see that Requirement 1 is implemented correctly – we understood the

customer&s re$uirement, designed correctly to meet that re$uirement, built correctly
to meet the design, and so deliver that re$uirement with the right attributes"
 functionally, it does what it is supposed to do and it also has the right non8functional
attributes, so it is fast enough, easy to understand and so on.

 With the other 

re$uirements, errors have been made at different stages. Requirement 2 is fine until
the software is coded, when we make some mistakes and introduce defects.
<robably, these are easily spotted and corrected during testing, because we can see
the product does not meet its design specification.

 The defects introduced in Requirement 3 are harder to deal with= we built exactly
what we were told to but unfortunately the designer made some mistakes so there
are defects in the design. >nless we check against the re$uirements definition, we
will not spot those defects during testing. When we do notice them they will be hard
to fix because design changes will be re$uired .

 The defects in Requirement 4 were introduced during the definition of the

re$uirements= the product has been designed and built to meet that flawed
re$uirements definition. f we test the product meets its re$uirements and design, it
will pass its tests but may be re!ected by the user or customer. 6efects reported by
the customer in acceptance test or live use can be very costly. >nfortunately,
re$uirements and design defects are not rare= assessments of thousands of pro!ects
 have shown that defects introduced during re$uirements and design make up close
to half of the total number of defects.

6efect life cycle is a cycle which a defect goes through during its lifetime. t starts when
defect is found and ends when a defect is closed, after ensuring it&s not reproduced. 6efect
life cycle is related to the bug found during testing.

The bug has different states in the ?ife 'ycle. The ?ife cycle of the bu g can be shown
diagrammatically as follows"

Bug or defectlife cycle includes following stes or status:

#. !ew: When a defect is logged and posted for the first time. t&s state is given as new.
%. "ssigned: :fter the tester has posted the bug, the lead of the tester approves that
the bug is genuine and he assigns the bug to corresponding developer and the
developer team. t&s state given as assigned.
(. #en:  :t this state the developer has started analy2ing and working on the defect
fix.
*. Fi$ed: When developer makes necessary code changes and verifies the changes
then he9she can make bug status as 7ixed& and the bug is passed to testing team.
+. %ending retest: :fter fixing the defect the developer has given that particular code
for retesting to the tester. Here the testing is pending on the testers end. Hence its
status is pending retest.
. Retest: :t this stage the tester do the retesting of the changed code which
developer has given to him to check whether the defect got fixed or not.
-. &erified: The tester tests the bug again after it got fixed by the developer. f the bug
is not present in the software, he appro ves that the bug is fixed and changes the status
to @verifiedA.
B. Reoen: f the bug still exists even after the bug is fixed by the developer, the tester 
changes the status to @reopenedA. The bug goes through the life cycle once again.
C. 'losed: 3nce the bug is fixed, it is tested by the tester. f the tester feels that the
bug no longer exists in the software, he changes the status of the bug to @closedA. This
state means that the bug is fixed, tested and approved.
#D. Dulicate: f the bug is repeated twice or the two bugs mention the same concept of
the bug, then one bug status is changed to @duplicate()
##. Re*ected: f the developer feels that the bug is not genuine, he re!ects the bug. Then
the state of the bug is changed to @re!ectedA.
#%. Deferred: The bug, changed to deferred state means the bug is expected to be fixed
in next releases. The reasons for changing the bug to this state have many factors.
Some of them are priority of the bug may be low, lack of time for the release or the bug
may not have ma!or effect on the software.
#(. !ot a bug: The state given as @4ot a bugA if there is no change in the functionality
of the application. or an example" f customer asks for some change in the look and
field of the application like change of colour of some text then it is not a bug but !ust
some change in the looks of the application.