SOFTWARE ENGINEERING & TESTING

PRACTICAL

Anmoldeep Singh
Class: B.Tech CSE 6th Semester
Roll no.: 17032001550

Submitted To: Dr. Amitpal Singh

 Verification and Validation

Overview
Software testing is a process of verification and Validation. These two
terms have entirely different dimensions to them. Verification is to ensure
that product quality is maintained. The product is free from defects,
whereas Validation is more about market research and acceptance. For
instance, the primary reason Google Lens failed was that Google lens was
a software integrated with many functionalities and was heavy on quality.
But, due to privacy concerns, many governments banned the product.
Hence, Google Lens was a verified product but didn't pass the validation
criteria.

Scope
This article will discuss the two important aspects of testing: verification and
Validation. Verification discusses building the product right, vs. Validation is
more about if the product is right. Verification is about technical challenges,
whereas Validation is about business aspects.

Introduction
Verification comes from the term verify. The main objective is to ensure
everyone is on the same page—developer, tester, and client. Everyone
knows the requirements, development steps, and the final product goal.
Validation is finding the supreme truth. That is finding if the process is right
and the approach is correct. That Validation comes from market research
and user acceptance.
 Verification Testing
1. Verification testing is involved in the requirement gathering phase,
product planning, and product development
2. Verification testing ensures the process is going correctly.
Requirements are correct, and development is going in accordance.
3. Verification helps to find the bugs and issues at the earlier stage of
development. Verification testing is cheaper.
4. The quality assurance team does verification testing.

Validation Testing
1. Validation testing is done in the testing phase of SDLC. Validation is
also done at the maintenance stage.
2. Validation testing is done to find the correct way of a process. And
also ensuring that the process chosen is the best.
3. Validation is a costlier affair. If process A is used, after that, process
B is found to be better. The validation testing took the duration of
finding the better approach.
4. The product team does validation testing.

Difference between Verification and Validation Testing

Criteria Verification Testing Validation Testing
Verification testing is done by the testers to ensure Validation testing is done by the product team
Definition
the SDLC process is correct. to ensure the correct product is being built.
Validation testing is done by the product and
User Verification testing is done by the testers.
marketing team
Validation testing is costlier than verification
Cost It is cheaper than validation testing
testing.
Stages Verification is done from requirement gathering, Validation testing is done at the testing phase
Covered product planning, and product development phase itself.
Validation testing is done to ensure the best
Purpose Verification ensures the process is going correctly.
process is used for the product.
Example of Verification and Validation
For instance, a new mobile application for cab booking has been built.
Ensuring each functionality is working fine. White box, black box, and gray
box testing come under verification testing. After the product is done and is
bug-free, the functionalities that have been built are useful for people, or
people find it tedious. The customer is getting a good chance to cancel the
ride, and customers finding the prices decent all come under the validation
testing of the application.

Conclusion
1. Verification testing ensures a bug-free product reaches the market.
2. Validation testing is done to ensure the public receives the product
well.
3. A well-developed and tester product can fail if the customer doesn't
accept the functionalities. And a validated product would only work if
it is a good product with no bugs.
4. Verification testing is cheaper compared to validation testing.
 Boundary Value Analysis

The basis of Boundary Value Analysis (BVA) is testing the boundaries at

partitions. BVA is an extension of equivalence partitioning. However, this is
useable only when the partition is ordered, consisting of numeric or
sequential data. The minimum and maximum values of a partition are its
boundary values.

We have seen that there are high chances of finding the defects at the
boundaries of a partition (E.g., A developer using >10 instead of >= 10 for a
condition). Equivalence partitioning alone was not sufficient to catch such
defects.

Therefore, a need to define a new technique that can detect anomalies at

the boundaries of the partition arose. It is how Boundary value analysis
came into the picture.

Boundary value analysis can perform at all test levels, and its primarily
used for a range of numbers, dates, and time.

How to Do Boundary Value Analysis?

Now that we have got some idea on boundary value analysis let's
understand how to derive test conditions using this technique. We will refer
to the same example of gym form where we need to enter Age.
The first step of Boundary value analysis is to create Equivalence
Partitioning, which would look like below.

Now Concentrate on the Valid Partition, which ranges from 16-60. We have
a 3 step approach to identify boundaries:

 Identify Exact Boundary Value of this partition Class - which is 16 and

60.
 Get the Boundary value which is one less than the exact Boundary -
which is 15 and 59.
 Get the Boundary Value which is one more than the precise
Boundary - which is 17 and 61 . If we combine them all, we will get
below combinations for Boundary Value for the Age Criteria.
Valid Boundary Conditions : Age = 16, 17, 59, 60

Invalid Boundary Conditions : Age = 15 61,

It's straightforward to see that valid boundary conditions fall under Valid
partition class, and invalid boundary conditions fall under Invalid partition
class.

Can you figure out why we have not used 16.1, 15.9, 59.9, and 60.1 as the
boundary increment and decrement values? It's a concept that has an
insufficient explanation in most of the articles. Therefore, let's take another
example to explain this. Assume that you are entering your weight on a
website. Based on your weight and height, the site will tell you the Body
Mass Index (BMI). You can enter values from 30 to 150 kg in the weight
input field. The weight input field only allows natural numbers i.e., positive
integers!

In this case, if you will create the boundaries using the same method - you
will end up with

Valid Boundary Conditions : Age = 30, 31, 149, 150

Invalid Boundary Conditions : Age = 29, 151

Now consider the same scenario, but the weight input field allows decimal
numbers up to 1 decimal place. In this case, the boundary conditions will
come as:

Valid Boundary Conditions : Age = 30, 30.1, 149.9, 150

Invalid Boundary Conditions : Age = 29.9, 150.1

Did you see the difference? We take the minimal acceptable value on
either side of the boundary. If we take the value as 30.01, then we end up
testing the software for two decimals where the requirement is one decimal
place. It is a separate test condition and should not be mixed up with
Boundary value.

Measurement of the Boundary coverage for a partition can happen as the

number of boundary values tested divided by the total number of boundary
test values identified.

Pitfalls of BVA

Boundary value assume that the application will not allow you to enter any
other characters or values. Such characters, like @ or negative values or
even alphabets, will not be allowed to enter. This assumption is, however,
not valid for all applications, and it's essential to test these out before we
can say that the field value is completely working.

Apart from that, we can have situations where the input value depends on
the decision of another value. E.g., If the Gym form has another field Male
and Female, and the age limit will vary according to that selection.
Boundary value alone cannot handle such variations, and this leads us to
another black box technique called Decision Table Testing. We will discuss
that in detail in our next article. Stay tuned!
 The Debugging Process

Debugging occurs as a consequence of successful testing. That is, when a

test case uncovers an error, debugging is the process that results in the
removal of the error. Debugging is not testing but often occurs as a
consequence of testing. The debugging process begins with the execution
of a test case. Results are assessed and a lack of correspondence
between expected and actual performance is encountered. In many cases,
the non-corresponding data are a symptom of an underlying cause as yet
hidden. The debugging process attempts to match symptom with cause,
thereby leading to error correction.

During debugging, we encounter errors that range from mildly annoying

(e.g., an incorrect output format) to catastrophic (e.g., the system fails,
causing serious economic or physical damage). As the consequences of an
error increase, the amount of pressure to find the cause also increases.
Often, pressure forces a software developer to fix one error and at the
same time introduce two more.

Debugging Strategies
Regardless of the approach that is taken, debugging has one overriding
objective—to find and correct the cause of a software error or defect. The
objective is realized by a combination of systematic evaluation, intuition,
and luck. In general, three debugging strategies have been proposed: brute
force, backtracking, and cause elimination

The brute force category of debugging is probably the most common and
least efficient method for isolating the cause of a software error. Memory
dumps are taken, run-time traces are invoked, and the program is loaded
with output statements. You hope that somewhere in the morass of
information that is produced you’ll find a clue that can lead us to the cause
of an error.
Backtracking is a fairly common debugging approach that can be used
successfully in small programs. Beginning at the site where a symptom has
been uncovered, the source code is traced backward (manually) until the
cause is found.

Cause elimination is manifested by induction or deduction and introduces

the concept of binary partitioning. Data related to the error occurrence are
organized to isolate potential causes. A “cause hypothesis” is devised and
the aforementioned data are used to prove or disprove the hypothesis.
Alternatively, a list of all possible causes is developed and tests are
conducted to eliminate each. If initial tests indicate that a particular cause
hypothesis shows promise, data are refined in an attempt to isolate the
bug.

Automated Debugging
Each of these debugging approaches can be supplemented with debugging
tools that can provide you with semi-automated support as debugging
strategies are attempted. A wide variety of debugging compilers, dynamic
debugging aids (“tracers”), automatic test-case generators, and cross-
reference mapping tools are available. However, tools are not a substitute
for careful evaluation based on a complete design model and clear source
code.

Correcting the Error

Once a bug has been found, it must be corrected. Van Vleck suggests
three simple questions that you should ask before making the “correction”
that removes the cause of a bug:

1. Is the cause of the bug reproduced in another part of the program?

2. What “next bug” might be introduced by the fix I'm about to make?

3. What could we have done to prevent this bug in the first place?
 Selenium Tool

Selenium is a free, open-source automation testing suite for web

applications across different browsers and platforms. Selenium focuses on
automating web-based applications. Testing done using Selenium is
usually referred to as Selenium testing. Remember, only testing web
applications is possible with Selenium. You cannot use it to test desktop
applications or mobile applications.

Since Selenium is an open-source tool, there is no licensing cost involved,

which is a significant benefit over other testing tools. Other benefits are as
follows:

 Test scripts are often written in any of these programming languages—

Java, Python, C#, PHP, Ruby, Perl, and .Net.
 Tests can be carried out in any of these operating systems—Windows,
Mac, or Linux.
 Tests can be carried out using any of these browsers—Mozilla Firefox,
Internet Explorer, Google Chrome, Safari, or Opera.
 It can be integrated with tools such as TestNG in selenium and JUnit
for managing test cases and generating reports.
 It is integrated with Maven, Jenkins, and Docker to achieve continuous
testing.
What is Selenium Used For?

Most programmers and developers who build website applications and

wish to test them every now and then use Selenium. Any individual who
creates web programs can use Selenium to test the code and applications.
Further, professionals can debug and perform visual regression. In most
organizations, it is the job of quality analyst (QA) engineers to test web
applications by using Selenium. They are required to write scripts that can
help in maximizing accuracy and test coverage to make changes in the
project and maintain the infrastructure of the test. QA engineers are
responsible for developing test suites that can identify bugs.

Selenium Tools

Selenium is not simply one tool but a collection of software:

Selenium IDE: IDE stands for Integrated Development Environment,

which is a plug-in of Firefox, a browser. This is the simplest framework and,
therefore, requires developers to switch to Selenium RC for advanced test
cases.
Selenium RC: RC stands for Remote Control, and it permits
developers to code in the language of their preference. Selenium RC

supports multiple programming languages such as Java, C#, Python, etc.

Selenium WebDriver: WebDriver automates and controls activities

undertaken by a web browser. It does not typically depend on JavaScript
but communicates with the browser to control its actions. Like RC,
WebDriver additionally supports programming languages such as Java, C#,
Python, Ruby, etc. Now, the different types of WebDrivers are:

 FirefoxDriver
 InternetExplorerDriver
 ChromeDriver
 SafariDriver
 OperaDriver
 AndroidDriver
 IPhoneDriver
 HTMLUnitDriver

Selenium Grid: Grid is employed, along with RC, to execute parallel

tests across multiple browsers.