V Model to W Model | W Model in SDLC

Simplified
You will find out this is a great model!

V-model is the basis of structured testing

• The left side shows the classic software life cycle & Right side shows the
verification and validation for Each Phase
Analyze User requirements
End users express their whish for a solution for one or more problems they have. In testing
you have to start preparation of your user tests at this moment!

You should do test preparation sessions with your acceptance testers. Ask them what cases
they want to test. It might help you to find good test cases if you interview end users about
the every day cases they work on. Ask them for difficulties they meet in every days work now.

Give feedback about the results of this preparation (hand the list of real life cases, the
questions) to the analyst team. Or even better, invite the analyst team to the test preparation
sessions. They will learn a lot!

System requirements
One or more analysts interview end users and other parties to find out what is really wanted.
They write down what they found out and usually this is reviewed by Development/Technical
Team, end users and third parties.
In testing you can start now by breaking the analyses down into 'features to test'. One
'feature to test' can only have 2 answers: 'pass' or 'fail'. One analysis document will have a
number of features to test. Later this will be extremely useful in your quality reporting!

Look for inconsistency and things you don't understand in the analysis
documents. There’s a good chance that if you don't understand it, neither will the
developers. Give Feedback your questions and remarks to the analyst team. This is a second
review delivered by testing in order to find the bug as early as possible!

Lets discuss Left side of V Model:

- Global and detailed design
Development translates the analysis documents into technical design.

- Code / Build
Developers program the application and build the application.

- Note: In the classic waterfall software life cycle testing would be at the end of the life cycle.
The V-model is a little different. We already added some testing review to it.

The right side shows the different testing levels :

- Component & Component integration testing

These are the tests development performs to make sure that all the issues of the technical and
functional analysis is implemented properly.

- Component testing (unit testing)

Every time a developer finishes a part of the application he should test this to see if it works
properly.

- Component integration testing

Once a set of application parts is finished, a member of the Development team should test
to verify whether the different parts do what they have to do.

Once these tests pass successfully, system testing can start.

- System and System integration testing

In this testing level we are going to check whether the features to test, destilated from the
analyses documents, are realised properly.

Best results will be achieved when these tests are performed by professional testers.
- System testing
In this testing level each part (use case, screen description) is tested apart.

- System integration testing

Different parts of the application now are tested together to examine the quality of the
application. This is an important (but sometimes difficult) step.

Typical stuff to test: navigation between different screens, background processes started in
one screen, giving a certain output (PDF, updating a database, consistency in GUI,...).

System integration testing also involves testing the interfacing with other systems. E.g. if you
have a web shop, you probably will have to test whether the integrated Online payment
services works.

These interface tests are usually not easy to realise, because you will have to make
arrangements with parties outside the project group.

- Acceptance testing
Here real users (= the people who will have to work with it) validate whether this application
is what they really wanted.

This comic explains why end users need to accept the application:

This is what actually Client Needs :-(

During the project a lot off interpretation has to be done. The analyst team has to translate
the wishes of the customer into text. Development has to translate these to program code.
Testers have to interpret the analysis to make features to test list.

Tell somebody a phrase. Make him tell this phrase to another person. And this person to
another one... Do this 20 times. You'll be surprised how much the phrase has changed!

This is exactly the same phenomenon you see in software development!

Let the end users test the application with the real cases you listed up in the test preparation
sessions. Ask them to use real life cases!

And - instead of getting angry - listen when they tell you that the application is not doing
what it should do. They are the people who will suffer the applications shortcomings for the
next couple of years. They are your customer!

V-model is the basis of structured testing. However there are few problems with V
Model. V Model Represents one-to-one relationship between the documents on the left hand
side and the test activities on the right. This is not always correct. System testing not only
depends on Function requirements but also depends on technical design, architecture also.
Couple of testing activities is not explained in V model. This is a major exception and the V-
Model does not support the broader view of testing as a continuously major activity
throughout the Software development lifecycle.

Paul Herzlich introduced the W-Model. In W Model, those testing activities are covered
which are skipped in V Model.

The ‘W’ model illustrates that the Testing starts from day one of the of the project initiation.

If you see the below picture, 1st “V” shows all the phases of SDLC and 2nd “V” validates the
each phase. In 1st “V”, every activity is shadowed by a test activity. The purpose of the test
activity specifically is to determine whether the objectives of that activity have been met and
the deliverable meets its requirements. W-Model presents a standard development lifecycle
with every development stage mirrored by a test activity. On the left hand side, typically, the
deliverables of a development activity (for example, write requirements) is accompanied by a
test activity test the requirements and so on.
Fig 1: W Model
Fig 2: Each phase is verified/validated. Dotted arrow shows that every phase in brown is
validated/tested through every phase in sky blue.

Now, in the above figure,

• Point 1 refers to - Build Test Plan & Test Strategy.

• Point 2 refers to - Scenario Identification.
• Point 3, 4 refers to – Test case preparation from Specification document and
design documents
• Point 5 refers to – review of test cases and update as per the review comments.

So if you see, the above 5 points covers static testing.

• Point 6 refers to – Various testing methodologies (i.e. Unit/integration testing,

path testing, equivalence partition, boundary value, specification based testing,
security testing, usability testing, performance testing).
• After this, there are regression test cycles and then User acceptance testing.

Conclusion - V model only shows dynamic test cycles, but W models gives a broader view of
testing. the connection between the various test stages and the basis for the test is clear with
W Model (which is not clear in V model).