V-Model

V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC
must complete before the next phase starts. It follows a sequential design process same as the
waterfall model. Testing of the device is planned in parallel with a corresponding stage of
development.
Verification: It involves a static analysis method (review) done without executing code. It is the
process of evaluation of the product development process to find whether specified requirements
meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is done by

executing code. Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer expectations and
requirements.

So V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation process is joined by coding phase in V-shape. Thus it is known as V-
Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product requirements
understood from the customer's side. This phase contains detailed communication to
understand customer's expectations and exact requirements.
2. System Design: In this stage system engineers analyze and interpret the business of the
proposed system by studying the user requirements document.
3. Architecture Design: The baseline in selecting the architecture is that it should understand
all which typically consists of the list of modules, brief functionality of each module, their
interface relationships, dependencies, database tables, architecture diagrams, technology
detail, etc. The integration testing model is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks down into small modules.
The detailed design of the modules is specified, which is known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the requirements, a
suitable programming language is decided. There are some guidelines and standards for
coding. Before checking in the repository, the final build is optimized for better
performance, and the code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module
design phase. These UTPs are executed to eliminate errors 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.
 2. Integration Testing: Integration Test Plans are developed during the Architectural Design
Phase. These tests verify that groups created and tested independently can coexist and
communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike
Unit and Integration Test Plans, System Tests Plans are composed by the client?s business
team. System Test ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis
part. It includes testing the software product in user atmosphere. Acceptance tests reveal
the compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.

When to use V-Model?

o When the requirement is well defined and not ambiguous.

o The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical resources are available with
essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.

2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of the
software are produced.
4. If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.
Principles of V-Model:

• Large to Small: In V-Model, testing is done in a hierarchical perspective, For example,

requirements identified by the project team, create High-Level Design, and Detailed Design
phases of the project. As each of these phases is completed the requirements, they are
defining become more and more refined and detailed.
• Data/Process Integrity: This principle states that the successful design of any project
requires the incorporation and cohesion of both data and processes. Process elements must
be identified at each and every requirements.
• Scalability: This principle states that the V-Model concept has the flexibility to
accommodate any IT project irrespective of its size, complexity or duration.
• Cross Referencing: Direct correlation between requirements and corresponding testing
activity is known as cross-referencing.
Tangible Documentation: This principle states that every project needs to create a document.
This documentation is required and applied by both the project development team and the
support team. Documentation is used to maintaining the application once it is available in a
production environment

Why preferred?
• It is easy to manage due to the rigidity of the model. Each phase of V-Model has specific
deliverables and a review process.
• Proactive defect tracking – that is defects are found at early stage.

When to use?
• Where requirements are clearly defined and fixed.
• The V-Model is used when ample technical resources are available with technical
expertise.
• Small to medium-sized projects with set and clearly specified needs are recommended to
use the V-shaped model.
• Since it is challenging to keep stable needs in large projects, the project should be small.

Software Testing Life Cycle (STLC)

 The procedure of software testing is also known as STLC (Software Testing Life Cycle) which
includes phases of the testing process. The testing process is executed in a well-planned and
systematic manner. All activities are done to improve the quality of the software product.

Let's see, the different steps of STLC.

Software testing life cycle contains the following steps:

1. Requirement Analysis
2. Test Plan Creation
3. Environment setup
4. Test case Execution
5. Defect Logging
6. Test Cycle Closure

Requirement Analysis:

The first step of the manual testing procedure is requirement analysis. In this phase, tester analyses
requirement document of SDLC (Software Development Life Cycle) to examine requirements stated by
the client. After examining the requirements, the tester makes a test plan to check whether the software is
meeting the requirements or not.
 Entry Criteria Activities Deliverable

For the planning of test plan Prepare the list of all requirements List of all the necessary
requirement specification, and queries, and get resolved from tests for the testable
application architecture document Technical Manager/Lead, System requirements andTest
and well-defined acceptance Architecture, Business Analyst and environment details
criteria should be available. Client.
Make a list of all types of tests
(Performance, Functional and
security) to be performed.
Make a list of test environment
details, which should contain all the
necessary tools to execute test
cases.

Test Plan Creation:

Test plan creation is the crucial phase of STLC where all the testing strategies are defined. Tester
determines the estimated effort and cost of the entire project. This phase takes place after the successful
completion of the Requirement Analysis Phase. Testing strategy and effort estimation documents
provided by this phase. Test case execution can be started after the successful completion of Test Plan
Creation.

Entry Criteria Activities Deliverable

Requirement Define Objective as well as the scope of Test strategy document.

Document the software. Testing Effort estimation documents are the
List down methods involved in testing. deliverables of this phase.
Overview of the testing process.
Settlement of testing environment.
Preparation of the test schedules and
control procedures.
Determination of roles and
responsibilities.
List down testing deliverables, define
risk if any.

Environment setup:

Setup of the test environment is an independent activity and can be started along with Test Case
Development. This is an essential part of the manual testing procedure as without environment testing is
not possible. Environment setup requires a group of essential software and hardware to create a test
environment. The testing team is not involved in setting up the testing environment, its senior developers
who create it.
Entry Criteria Activities Deliverable

Test strategy and test Prepare the list of software and hardware by analyzing requirement Execution
plan document. specification. report.
Test case document. After the setup of the test environment, execute the smoke test cases Defect report.
Testing data. to check the readiness of the test environment.
AD

Test case Execution:

Test case Execution takes place after the successful completion of test planning. In this phase, the testing
team starts case development and execution activity. The testing team writes down the detailed test cases,
also prepares the test data if required. The prepared test cases are reviewed by peer members of the team
or Quality Assurance leader.

RTM (Requirement Traceability Matrix) is also prepared in this phase. Requirement Traceability Matrix
is industry level format, used for tracking requirements. Each test case is mapped with the requirement
specification. Backward & forward traceability can be done via RTM.

Entry Criteria Activities Deliverable

Requirement Creation of test cases. Test execution result.

Document Execution of test cases. List of functions with the detailed explanation
Mapping of test cases according to of defects.
requirements.

Defect Logging:

Testers and developers evaluate the completion criteria of the software based on test coverage, quality,
time consumption, cost, and critical business objectives. This phase determines the characteristics and
drawbacks of the software. Test cases and bug reports are analyzed in depth to detect the type of defect
and its severity.

Defect logging analysis mainly works to find out defect distribution depending upon severity and types.If
any defect is detected, then the software is returned to the development team to fix the defect, then the
software is re-tested on all aspects of the testing.

Once the test cycle is fully completed then test closure report, and test metrics are prepared.
Entry Criteria Activities Deliverable

Test case It evaluates the completion criteria of the software based on test coverage, Closure
execution report. quality, time consumption, cost, and critical business objectives. report
Defect report Defect logging analysis finds out defect distribution by categorizing in types Test metrics
and severity.

Test Cycle Closure:

The test cycle closure report includes all the documentation related to software design, development,
testing results, and defect reports.

This phase evaluates the strategy of development, testing procedure, possible defects in order to use these
practices in the future if there is a software with the same specification.

Entry Criteria Activities Deliverable

All document and Evaluates the strategy of development, testing procedure, possible Test closure
reports related to defects to use these practices in the future if there is a software with report
software. the same specification

Stages of Testing
levels of software testing.
As we learned in the earlier section of the software testing tutorial that testing any application or software,
the test engineer needs to follow multiple testing techniques.

In order to detect an error, we will implement software testing; therefore, all the errors can be removed to
find a product with more excellent quality.

What are the levels of Software Testing?

Testing levels are the procedure for finding the missing areas and avoiding overlapping and repetition
between the development life cycle stages. We have already seen the various phases such as Requirement
collection, designing, coding testing, deployment, and maintenance of SDLC (Software Development
Life Cycle).

In order to test any application, we need to go through all the above phases of SDLC. Like SDLC, we
have multiple levels of testing, which help us maintain the quality of the software.
Different Levels of Testing
The levels of software testing involve the different methodologies, which can be used while we
are performing the software testing.

In software testing, we have four different levels of testing, which are as discussed below:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

As we can see in the above image that all of these testing levels have a specific objective which
specifies the value to the software development lifecycle.

Level 1: Unit Testing

Unit testing

Is the first level of software testing, which is used to test if software modules are satisfying the
given requirement or not.

The first level of testing involves analyzing each unit or an individual component of the
software application.

Unit testing is also the first level of functional testing. The primary purpose of executing unit
testing is to validate unit components with their performance.
A unit component is an individual function or regulation of the application, or we can say that it is
the smallest testable part of the software. The reason of performing the unit testing is to test the
correctness of inaccessible code.

Unit testing will help the test engineer and developers in order to understand the base of code that
makes them able to change defect causing code quickly. The developers implement the unit.

Level 2: Integration Testing

The second level of software testing is the integration testing. The integration testing process
comes after unit testing.

It is mainly used to test the data flow from one module or component to other modules.

In integration testing, the test engineer tests the units or separate components or modules of the
software in a group.

The primary purpose of executing the integration testing is to identify the defects at the interaction
between integrated components or units.

When each component or module works separately, we need to check the data flow between the
dependent modules, and this process is known as integration testing.

We only go for the integration testing when the functional testing has been completed successfully
on each application module.

In simple words, we can say that integration testing aims to evaluate the accuracy of
communication among all the modules.

Level 3: System Testing

The third level of software testing is system testing, which is used to test the software's functional
and non-functional requirements.

It is end-to-end testing where the testing environment is parallel to the production environment.
In the third level of software testing, we will test the application as a whole system.

To check the end-to-end flow of an application or the software as a user is known as System
testing.

In system testing, we will go through all the necessary modules of an application and test if the
end features or the end business works fine, and test the product as a complete system.

In simple words, we can say that System testing is a sequence of different types of tests to
implement and examine the entire working of an integrated software computer system against
requirements.

Level 4: Acceptance Testing

 The last and fourth level of software testing is acceptance testing, which is used to evaluate
whether a specification or the requirements are met as per its delivery.

The software has passed through three testing levels (Unit Testing, Integration Testing, System
Testing). Some minor errors can still be identified when the end-user uses the system in the actual
scenario.

In simple words, we can say that Acceptance testing is the squeezing of all the testing processes
that are previously done.

The acceptance testing is also known as User acceptance testing (UAT) and is done by the
customer before accepting the final product.

Usually, UAT is done by the domain expert (customer) for their satisfaction and checks whether
the application is working according to given business scenarios and real-time scenarios.

Conclusion

In this tutorial, we have learned all the levels of testing. And we can conclude that tests are grouped
based on where they are added in the Software development life cycle.

A level of software testing is a process where every unit or component of a software or system is
tested.

The main reason for implementing the levels of testing is to make the software testing process
efficient and easy to find all possible test cases at a specific level.

To check the behavior or performance of software testing, we have various testing levels. The
above-described software testing levels are developed to identify missing areas and understanding
between the development life cycle conditions.

All these SDLC models' phases (requirement gathering, analysis, design, coding or execution,
testing, deployment, and maintenance) undergo the process of software testing levels.

Program Correctness and Verification

This being a book on software testing, one may wonder why we need to talk about program
correctness. There are several reasons and some of them are as follows:

• The focus of software testing is to run the candidate program on selected input data and check
whether the program behaves correctly with respect to its specification. The behavior of the
 program can be analyzed only if we know what is a correct behavior; hence the study of
correctness is an integral part of software testing.
• The study of program correctness leads to analyze candidate programs at arbitrary levels of
granularity; in particular, it leads to make assumptions on the behavior of the program at specific
stages in its execution and to verify (or disprove) these assumptions; the same assumptions can
be checked at run-time during testing, giving us valuable information as we try to diagnose the
program or establish its correctness. Hence the skills that we develop as we try to prove program
correctness enable us to be better/more effective testers.
• It is common for program testers and program provers to make polite statements about testing
and proving being complementary and then to assiduously ignore each other (each other’s
methods). But there is more to complementarity than meets the eye. Very often, what makes a
testing method or a proving method ineffective is not an intrinsic attribute of the method, but
rather the fact that the method is used against the wrong ...