You are on page 1of 20

SOFTWARE TESTING

BY,
NEHA

TOPICS TO BE COVERED(UNIT1):
Error, fault and failure

Limitations of testing

shaped model

WHAT IS AN ERROR?
Error may also be termed as a mistake. It may either be a
syntactical error or misunderstanding of specifications. It
is deviation from actual and expected value. There may
be logical errors as well. The errors in coding are termed
as bugs. Errors propagate from one phase to another
with higher severity. A requirement error may be
magnified during design,and amplified still more during
coding.An error may lead to one or more faults..

FAULT
A Fault is the representation of an error,where representation is
the mode of expression,such as narrative text,data flow
diagrams,ER diagrams,source code..etc.. Fault is incorrect step,
process or data definition in a computer program which causes
the program to behave in an unintended or unanticipated
manner.
It is the result of the error.
A failure occurs when a fault executes.

FAILURE
A Failure occurs when a fault executes.It is the departure of the output of
program from the expected output.
Failure is dynamic.
Failure may also be termed as the inability of a system or a component to
perform its required functions within specified requirements.
Failure occurs when fault excecutes.

ERROR,FAULT AND FAILURE

DEFECT
A defect is an error in coding or logic that causes
a program to malfunction or to produce
incorrect/unexpected results.
A defect is said to be detected when a failure is
observed.

WHAT EXACTLY IS TESTING?


Testing is the process of excecuting a program with the intent of finding
errors. Testing requires the developers to find errors from their software. We
should test the programs responses to every possible input.
Types of testing are: White box testing, black box,unit ,integration system
testing,alpha testing and many more..
We should excecute all possible paths of the program. But this cannot be
possible..So,we next come to the limitations..

LIMITATIONS OF TESTING
Complete or exhaustive testing is not possible. We cannot test each and
every statement and path of the program. Testing requires the below
objectives to be fulfilled but these are next to impossible to achieve due to
time and resource constraints.
Execute every true and false condition
Execute every condition of a decision node
Execute every possible path
Execute the program with all valid inputs
Execute the program with all invalid inputs.

LIMITATIONS OF
TESTING(CONTD..)
Testing is destructive process because we are not creating anything but are
attempting to break it.
Testing is expensive process over one third of the resources allocated are
given for testing process.
Testing cannot establish that a product functions properly under all
conditions but can only establish that it does not function properly under
specific conditions.

V SHAPED MODEL

V MODEL(CONTD..)

V MODEL
TheV-model represents asoftware development process(also applicable to
hardware development) which may be considered an extension of
thewaterfall model. Instead of moving down in a linear way, the process
steps are bent upwards after thecodingphase, to form the typical V shape.
The V-Model demonstrates the relationships between each phase of the
development life cycle and its associated phase oftesting.
The horizontal and vertical axes represents time or project completeness
(left-to-right) and level of abstraction (coarsest-grain abstraction uppermost),
respectively.

VERIFICATION PHASES
In therequirements analysisphase, the first step in the verification process,
therequirementsof the system are collected by analyzing the needs of
theuser(s).
Systems designis the phase where system engineers analyze and understand
the business of the proposed system by studying the user requirements
document. They figure out possibilities and techniques by which the user
requirements can be implemented.
The phase of the design ofcomputer architectureandsoftware
architecturecan also be referred to as high-level design. The baseline in
selecting the architecture is that it should realize all which typically consists of
the list of modules, brief functionality of each module,
theirinterfacerelationships,dependencies,databasetables, architecture
diagrams, technology details etc. The integration testing design is carried out
in the particular phase.

VALIDATION PHASES
In the V-Model, Unit Test Plans (UTPs) are developed during module design phase. These
UTPs are executed to eliminate bugs 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 .

Integration Test Plans are developed during the Architectural Design Phase. These tests
verify that units created and tested independently can coexist and communicate among
themselves. Test results are shared with customer's team.
System Tests Plans are developed during System Design Phase. Unlike Unit and Integration
Test Plans, System Test Plans are composed by client's business team. System Test ensures
that expectations from application developed are met. The whole application is tested for its
functionality, interdependency and communication. System Testing verifies that functional
and non-functional requirements have been met. Load and performance testing, stress
testing, regression testing, etc., are subsets of system testing.

User Acceptance Test (UAT) Plans are developed during the Requirements Analysis
phase. Test Plans are composed by business users. UAT is performed in a user
environment that resembles the production environment, using realistic data. UAT
verifies that delivered system meets user's requirement and system is ready for use in
real time.

ADVANTAGES
These are the advantages V-model offers in front of other systems
development models:
This model brings the quality into the development of our
products. The encouragement of writing test cases and test plans
in the earlier phases of the software development life cycle is the
real strength of this model.
The users of the V-model participate in the development and
maintenance of the V-model. A change control board publicly
maintains the V-Model. The change control board meets anywhere
from every day to weekly and processes all change requests
received during system development and test.
The V-model provides concrete assistance on how to implement an
activity and its work steps, defining explicitly the events needed to
complete a work step: each activity schema contains instructions,
recommendations and detailed explanations of the activity

LIMITATIONS OF THIS
MODEL
It is too simple to accurately reflect the software development process, and can
lead managers into a false sense of security. The V-Model reflects a project
management view of software development and fits the needs of project
managers, accountants and lawyers rather than software developers or users.
The organization and execution of operation, maintenance, repair and disposal of
the system are not covered by the V-model. However, planning and preparation of
a concept for these tasks are regulated in the V-model.
The V-model addresses software development within a project rather than a whole
organization.
We require more resources to implement this model as compared to the waterfall
model.
This model also suffers from many disadvantages of the waterfall model like nonavailability of a working version of the product until late in the life cycle, difficulty
in accommodating any change, etc.
This model has also limited applications in todays interactive software processes.

REFERENCES:
Software testing, Yogesh singh
Wikipedia
Google.com

THANK YOU!!!!!!!!!

You might also like