Waterfall and V Model in Software Development Life Cycle Video Lecture | Software Testing Tutorials

Hi, this video is on the testing cycle. Here, we will go through the Waterfall SDLC and the V Model.
This video is also part two of the manual testing training.
So let us start with the Waterfall SDLC.
SDLC stands for software development life cycle.
What is the requirement of following a software development life cycle when developing software?
Well, most software is quite complex.
So it is not simple to go directly from the requirements to the software and be able to use it.
So obviously, the problem has to be broken down into simpler parts.
Any SDLC gives us a way in which we can divide up the activities of software development
into individual activities, and those activities are done one after the other OR in parallel, as the case may be.
So, the software development life cycle is really a
sequence or a set of activities that have to be done one after the other.
Or maybe, with a bit of an overlap so that
the software can be developed with quality and meeting the requirements.
Sometimes,
instead of SDLC, people refer to it as the model.
So you may have heard about the Waterfall model or the hybrid model or the agile model.
A model really means that it is a simplification of the overall process.
So instead of specifying the entire software development process in detail,
the process is
abstracted so that only the major activities in the process are shown.
So let us start with understanding the Waterfall SDLC.
Well,
the very first activity
it is done in the Waterfall SDLC is the requirements analysis.
Now requirements are obtained from the users and
there are many different ways in which
requirements can be elicited from the users like asking them questions, or
asking them to fill up a form or
maybe, look at
the high level requirements that they may have as part of the project business requirements.
Or to show them
some mocked-up screens
and ask their inputs on those.
A very popular way of capturing the requirements is with the help of use cases,
which walk through a typical scenario of what the users would like to achieve in the system.
So in the case of... for example,
an e-commerce enabled website so there can be the major requirements around searching the products in that website,
the shopping cart functionality of the website, then some administrative
functionality in the website. So all the requirements are analyzed and
documented and
the reason is to find out
each and every requirement that is supposed to be there in the system and also to make sure that the requirements are
unambiguous (that means the requirements are very clear).
There are no conflicting requirements and also the requirements are testable meaning that it should be possible to
test out the requirement. There should be no ambiguity.
For example, it should not say that
the
display has to be "pleasant".
It has to say that the display has to be simple with no more than 10 controls in any one single screen.
So the output of
the requirement analysis phase is the requirements document.
This is the main requirements document of the entire system.
the next task in
the Waterfall SDLC is a system design.
So earlier phase of requirement analysis resulted in the requirements document.
Now, the team goes about the task of designing the overall system.
So what is going to be... just at a high level... What will be the system?
What will be the different major parts of the system? That means what will be the
software architecture?
What will be the main parts of the user interface of the system?
What kind of data structures it will use? For example, will it use a database?
Or will it get data from web services?
What kind of major reports are required from the system?
The system design can also be
shown in the form of an entity relationship diagram. An ERD, which shows the major entities
in the system. For example,
in the case of the e-commerce shopping website, the main entities can be
the visitor to the website, the customer of the website,
it can be product, it can be an order. So these are the main entities in the system.
Those
are designed in the system design phase.
So the system design phase produces the entire software architecture and the software architecture is not only a diagram.
But it is also a description and that description is called the system specification. It is a kind of a high level design.
Now, once the design is complete,
then coding can start.
So the coding is based on the software architecture that has been designed and coding the actual software code is written
so
the software
itself will follow whatever software architecture has been decided and whatever system
specification has been decided,
along with database
structures required, database tables required, UI specification required, report specification required etc.
And coding is done with by the developers. The developers look at the system specification and create the software.
So the major tasks in coding are the implementation of interfaces. For example,
a particular module
in the software for example, the Shopping Cart module has to interact with
the Order module so how they are going to interact with each other? What kind of data
they will pass? All this is implemented in code.
Also, the logic of
the process is implemented in the code.
The user interface specification that is already there... The code is written to interact with the
user interface. That means how to populate the user interface to show to the user? The code is written for that and how to understand
the users' data given in the user interface and use it in the application?
Similarly,
code is also written to interact with the database.
So, whether it is fetching some data from the database or writing the users data to the database, that code is written.
Also, the code
includes
error messages, in case the user has performed any incorrect or
operation that is not allowed.
And the output of the coding phase is the software.
Next is testing. Once the software is
created,
The software is tested and there are different kinds of tests that are there.
Some of the tests for example, the unit tests are done by the developers. So, the developers test the logic of their functions.
How the functions interact with other functions?
And so on. Then there is integration testing in which
the developers test how one module
interacts with another module. And then there are some tests done by the testers such as
system testing in which they take the system specification and
they test against the system specification and
also, there is acceptance testing in which the users (or representatives of users)
actually
take the entire system and test it from the original requirements document (that was created in the requirements analysis phase).
So, this is the overall
Waterfall SDLC.
Now, let us look at the V Model. The V Model is an extension of the Waterfall SDLC.
It gives
some more details. In the V-Model, it is
important to remember that the activities of the SDLC or
the
software development process are from left to right.
So first, we have the requirements analysis, then there is system design then there is coding.
And all these activities are the activities of
development.
So, the requirement
analysis Produces the requirements document.
The system design produces the system specification and the coding produces the software.
Now, continuing on... Once the coding is complete, the developers do the unit testing. So they test out
each and every unit of the work. The unit is the smallest testable part that
they have written. So, it can be a function or it can be a class.
It's basically a small piece of code and the idea is to test out each and every statement
of that piece of code and also to see that the data
that is passed into the unit it is
accepted correctly by the unit. And the output of the unit is correct. For example, if there is a function
to add the items in the shopping cart.
So, the unit can be the function. It requires the inputs.
The inputs are going to be the line items of different items in the shopping cart, and it produces the output of the
total price and
the addition of all the line items prices' should be correct.
All this is validated by the developers in the unit testing.
Once the unit testing is successfully complete,
The next step is for the integration testing.
So, in integration testing the focus is on testing the interfaces between the units.
So, for example, if there is the Shopping Cart unit and the
and the Order unit, so whether the Shopping Cart unit
transmits the correct data to the
Orders unit and
the Orders unit gives back the correct acknowledgment to the shopping cart unit.
All this integration is tested between the units.
Once the integration testing is successfully complete, next comes the system testing and
system testing, if you remember from the slide on the Waterfall SDLC,
produces the system specification so system testing is done by the testers. The testers use the system
specification to write the test cases for system testing and
those test cases are executed on the
software which has successfully completed
integration testing.
So, one
important thing to keep in mind
is that unit testing and integration testing are more technical types of testing and that is the reason
commonly developers do unit testing and integration testing.
System testing and subsequent test levels like acceptance testing are done by testers or other people.
So, after the system testing is successfully complete,
we just move on in the process. If not, then the defects are fixed and the system test is repeated.
So, after system testing we have the acceptance testing. The acceptance testing is based on the original
requirements document
that was created.
So acceptance testing is either done by testers or users.
When testers do the acceptance testing, they act on behalf of the end-users. So this is the overall V Model.
On the left hand side, we can see... these are the activities of development.
Requirement analysis,
system design and coding and on the right hand side, we have the testing activities.
Unit testing, integration testing, system testing and acceptance testing.
Overall, it is in the shape of a V that is why it is called a V model and
the activities of the V model are from left to right.
So first, requirements analysis is done. Then system design and coding is done.
Then unit testing, integration testing system testing and acceptance testing.
The coding is at the level of unit testing because the unit testing is done on the code that is created.
The integration testing is on the level of system design because the system design is where the
interfaces between the units are
decided.
The system testing is also at the level of system design because system testing is done with respect to the system specification.
And then we have acceptance testing. Acceptance testing is at the level of requirements analysis because acceptance testing is
based on the requirements document.
So this is the overall V Model.
We move from left to right. Requirements analysis, system design, coding unit testing, integration testing,
system testing and acceptance testing.
And also, you can see that there is an overlap between the phases.
Requirements analysis and system design
It is not that once the requirements analysis is complete for each and every requirement, only then the system design can begin. No.
There can be overlap once the requirements analysis
is complete for a particular part of the system. That particular part of the system design can begin.
So it is really an overlapping process and
same holds true for
system design and coding. As soon as some system design is ready, coding can
begin on that particular part of the system.
Coding and unit testing is one after the other. And here in unit testing, we can see unit testing and integration testing
can overlap. So, the units that are complete and
whose unit testing is successfully complete, integration testing can be done on those.
And same for the overlap between system testing and
acceptance testing.
So that is about the Waterfall SDLC and the V Model.
So I hope, it is clear to you. What is an SDLC (software development life cycle)?
Basically, it is a set of activities that
defines or guides us. What are the major activities that we should perform in order to build
quality software and
it is also called a model because it is an abstraction or a simplification of the activities that we are supposed to perform.
We saw the Waterfall SDLC. Waterfall SDLC has four major activities - requirements analysis,
system design, coding and testing.
And V Model really extends
the Waterfall SDLC by showing the activities and the relationship between them.
So in V model, we can see there is relationship between coding and unit testing.
There is a relationship between system design and integration testing, system design and system testing and also requirements
analysis and acceptance testing.
So that is all for this video. I hope it was useful to you. See you in the next video. Thank you.