Answers were Sorted based on User's Feedback
Answer / muthuraman
V-model is nothing but test approach based on
the way the software should be build.In v-model testing
pahse is done parallely with the
SRS user acceptance
ANALYSIS system testing
HLD Integration testing
LLD Unit Testing
In V-model, testing phase start as soon as get the SRS.
|Is This Answer Correct ?||25 Yes||2 No|
Answer / shailu
The first step in development is a business investigation
followed by a "Business Case" produced by the customer for
a system. This outlines a new system, or change to an
existing system, which it is anticipated will deliver
business benefits, and outlines the costs expected when
developing and running the system.
The next broad step is to define a set of "Requirements",
which is a statement by the customer of what the system
shall achieve in order to meet the need. These involve both
functional and non-functional requirements. Further details
are in the requirements article.
"Requirements" are then passed to developers, who produce
a "System Specification". This changes the focus from what
the system shall achieve to how it will achieve it by
defining it in computer terms, taking into account both
functional and non-functional requirements.
Other developers produce a "System Design" from the "System
Specification". This takes the features required and maps
them to various components, and defines the relationships
between these components. The whole design should result in
a detailed system design that will achieve what is required
by the "System Specification".
Each component then has a "Component Design", which
describes in detail exactly how it will perform its piece
Finally each component is built, and then is ready for the
Types of Testing
The level of test is the primary focus of a system and
derives from the way a software system is designed and
built up. Conventionally this is known as the "V" model,
which maps the types of test to each stage of development.
Starting from the bottom the first test level is "Component
Testing", sometimes called Unit Testing. It involves
checking that each feature specified in the "Component
Design" has been implemented in the component.
In theory an independent tester should do this, but in
practise the developer usually does it, as they are the
only people who understand how a component works. The
problem with a component is that it performs only a small
part of the functionality of a system, and it relies on co-
operating with other parts of the system, which may not
have been built yet. To overcome this, the developer either
builds, or uses special software to trick the component
into believing it is working in a fully functional system.
As the components are constructed and tested they are then
linked together to check if they work with each other. It
is a fact that two components that have passed all their
tests, when connected to each other produce one new
component full of faults. These tests can be done by
specialists, or by the developers.
Interface Testing is not focussed on what the components
are doing but on how they communicate with each other, as
specified in the "System Design". The "System Design"
defines relationships between components, and this involves
What a component can expect from another component in terms
How these services will be asked for.
How they will be given.
How to handle non-standard conditions, i.e. errors.
Tests are constructed to deal with each of these.
The tests are organised to check all the interfaces, until
all the components have been built and interfaced to each
other producing the whole system.
Once the entire system has been built then it has to be
tested against the "System Specification" to check if it
delivers the features required. It is still developer
focussed, although specialist developers known as systems
testers are normally employed to do it.
In essence System Testing is not about checking the
individual parts of the design, but about checking the
system as a whole. In effect it is one giant component.
System testing can involve a number of specialist types of
test to see if all the functional and non-functional
requirements have been met. In addition to functional
requirements these may include the following types of
testing for the non-functional requirements:
Performance - Are the performance criteria met?
Volume - Can large volumes of information be handled?
Stress - Can peak volumes of information be handled?
Documentation - Is the documentation usable for the system?
Robustness - Does the system remain stable under adverse
There are many others, the needs for which are dictated by
how the system is supposed to perform.
Acceptance Testing checks the system against
the "Requirements". It is similar to systems testing in
that the whole system is checked but the important
difference is the change in focus:
Systems Testing checks that the system that was specified
has been delivered.
Acceptance Testing checks that the system delivers what was
The customer, and not the developer should always do
acceptance testing. The customer knows what is required
from the system to achieve value in the business and is the
only person qualified to make that judgement. To help them
courses and training are available.
The forms of the tests may follow those in system testing,
but at all times they are informed by the business needs.
Even if a system meets all its requirements, there is still
a case to be answered that it will benefit the business.
The linking of "Business Case" to Release Testing is looser
than the others, but is still important.
Release Testing is about seeing if the new or changed
system will work in the existing business environment.
Mainly this means the technical environment, and checks
concerns such as:
Does it affect any other systems running on the hardware?
Is it compatible with other systems?
Does it have acceptable performance under load?
These tests are usually run the by the computer operations
team in a business. The answers to their questions could
have significant a financial impact if new computer
hardware should be required, and adversely affect
the "Business Case".
It would appear obvious that the operations team should be
involved right from the start of a project to give their
opinion of the impact a new system may have. They could
then make sure the "Business Case" is relatively sound, at
least from the capital expenditure, and ongoing running
costs aspects. However in practise many operations teams
only find out about a project just weeks before it is
supposed to go live, which can result in major problems.
With modern systems one person's system, becomes somebody
else's component. It follows that all the above types of
testing could be repeated at many levels in order to
deliver the final value to the business. In fact every time
a system is altered.
|Is This Answer Correct ?||21 Yes||7 No|
Answer / roshini
In v-model testing pahse is done parallely with the
|Is This Answer Correct ?||16 Yes||9 No|
Answer / pavan
The V model gets its name from the fact that the graphical representation of the different test process activities involved in this methodology resembles the letter 'V'. The basic steps involved in this methodology are more or less the same as those in the waterfall model. However, this model follows both a 'top-down' as well as a 'bottom-up' approach (you can visualize them forming the letter 'V'). The benefit of this methodology is that in this case, both the development and testing activities go hand-in-hand. For example, as the development team goes about its requirement analysis activities, the testing team simultaneously begins with its acceptance testing activities. By following this approach, time delays are minimized and optimum utilization of resources is assured.
|Is This Answer Correct ?||6 Yes||3 No|
Answer / arulselvi.a
Development starts with information gathering. After the
requirements gathering BRS/CRS/URS will be prepared. This
is done by the Business Analyst.
During the requirements analysis all the requirements are
analyzed. at the end of this phase S/wRS is prepared. It
consists of the functional (customer requirements) + System
Requirements (h/w + S/w) requirements. It is prepared by the
During the design phase two types of designs are done. HLDD
and LLDD. Tech Leads will be involved.
During the coding phase programs are developed by programmers.
During unit testing, they conduct program level testing with
the help of WBT techniques.
During the Integration Testing, the testers and programmers
or test programmers integrating the modules to test with
respect to HLDD.
During the system and functional testing the actual testers
are involved and conducts tests based on S/wRS.
During the UAT customer site people are also involved, and
they perform tests based on the BRS.
From the above model the small scale and medium scale
organizations are also conducts life cycle testing. But they
maintain separate team for functional and system testing.
|Is This Answer Correct ?||3 Yes||1 No|
What is qualification testing?
Here is a topic for me to give a seminar "Web and Window based Testing".I didnt understand,which testing this topic comes under.can you give clear information and ralted urls,so that it will help me a lot.
What is assertion testing?
what you do when your reported defect rejected?
Explain monkey testing?
What is dependency testing?
i am a PG science(chemistry),now am working test engineer in small organization,now i will decide to move better organization please send model cv and advises
what is testing , why will be testing ,what is responsibilities of tester
Given alone a functional specification docs if a test plan is to be prepared without any prototype and the product or the appli is to be delivered within 10 days ..How to prepare test plan and prepare test cases ? Cheers, Amar.gp
What is failure?
When is rtm (requirement traceability matrix) prepared?
What the main use of preparing a traceability matrix?