Notes of Unit -IV(SE)

Objectives of Software Testing

The main goal of software testing is to find bugs as early as possible and
fix bugs and make sure that the software is bug-free. The goals of software
testing may be classified into three major categories as follows:

1. Immediate Goals
2. Long-term Goals
3. Post-Implementation Goals

1. Immediate Goals: These objectives are the direct outcomes of testing.

These objectives may be set at any time during the SDLC process. Some of
these are covered in detail below:

● Bug Discovery: This is the immediate goal of software testing to

find errors at any stage of software development. The number of
bugs is discovered in the early stage of testing. The primary
purpose of software testing is to detect flaws at any step of the
development process. The higher the number of issues detected at
an early stage, the higher the software testing success rate.

● Bug Prevention: This is the immediate action of bug discovery,

that occurs as a result of bug discovery. Everyone in the software
development team learns how to code from the behavior and
 analysis of issues detected, ensuring that bugs are not duplicated
in subsequent phases or future projects.

2. Long-Term Goals: These objectives have an impact on product quality in

the long run after one cycle of the SDLC is completed. Some of these are
covered in detail below:

● Quality: This goal enhances the quality of the software product.

Because software is also a product, the user’s priority is its
quality. Superior quality is ensured by thorough testing.
Correctness, integrity, efficiency, and reliability are all aspects that
influence quality. To attain quality, you must achieve all of the
above-mentioned quality characteristics.
● Customer Satisfaction: This goal verifies the customer’s
satisfaction with a developed software product. The primary
purpose of software testing, from the user’s standpoint, is
customer satisfaction. Testing should be extensive and thorough if
we want the client and customer to be happy with the software
product.
● Reliability: It is a matter of confidence that the software will not
fail. In short, reliability means gaining the confidence of the
customers by providing them with a quality product.
● Risk Management: Risk is the probability of occurrence of
uncertain events in the organization and the potential loss that
could result in negative consequences. Risk management must be
 done to reduce the failure of the product and to manage risk in
different situations.

3. Post Implemented Goals: After the product is released, these objectives

become critical. Some of these are covered in detail below:

● Reduce Maintenance Cost: Post-released errors are costlier to fix

and difficult to identify. Because effective software does not wear
out, the maintenance cost of any software product is not the same
as the physical cost. The failure of a software product due to faults
is the only expense of maintenance. Because they are difficult to
discover, post-release mistakes always cost more to rectify. As a
result, if testing is done thoroughly and effectively, the risk of
failure is lowered, and maintenance costs are reduced as a result.
● Improved Software Testing Process: These goals improve the
testing process for future use or software projects. These goals
are known as post-implementation goals. A project’s testing
procedure may not be completely successful, and there may be
room for improvement. As a result, the bug history and
post-implementation results can be evaluated to identify stumbling
blocks in the current testing process that can be avoided in future
projects.

Types of Software Testing

● Difficulty Level : Easy
 ● Last Updated : 24 Jun, 2022

Read

Discuss

Testing is the process of executing a program to find errors. To make our

software perform well it should be error-free. If testing is done successfully
it will remove all the errors from the software.

Principles of Testing:-

(i) All the tests should meet the customer requirements.

(ii) To make our software testing should be performed by a third party.

(iii) Exhaustive testing is not possible. As we need the optimal amount of

testing based on the risk assessment of the application.

(iv) All the tests to be conducted should be planned before implementing it

(v) It follows the Pareto rule(80/20 rule) which states that 80% of errors
come from 20% of program components.
(vi) Start testing with small parts and extend it to large parts.

Types of Testing:-

1. Unit Testing

It focuses on the smallest unit of software design. In this, we test an

individual unit or group of interrelated units. It is often done by the
programmer by using sample input and observing its corresponding
outputs.

Example:

a) In a program we are checking if the loop, method, or

function is working fine
b) Misunderstood or incorrect, arithmetic precedence.

c) Incorrect initialization

2. Integration Testing

The objective is to take unit-tested components and build a program

structure that has been dictated by design. Integration testing is testing in
which a group of components is combined to produce output.
Integration testing is of four types: (i) Top-down (ii) Bottom-up (iii)
Sandwich (iv) Big-Bang

Example:

(a) Black Box testing:- It is used for validation.

In this, we ignore internal working mechanisms and
focus on what is the output?.

(b) White box testing:- It is used for verification.

In this, we focus on internal mechanisms i.e.

how the output is achieved?

3. Regression Testing

Every time a new module is added leads to changes in the program. This
type of testing makes sure that the whole component works properly even
after adding components to the complete program.

Example

In school, record suppose we have module staff, students

and finance combining these modules and checking if on

integration of these modules works fine in regression testing

4. Smoke Testing
This test is done to make sure that the software under testing is ready or
stable for further testing

It is called a smoke test as the testing of an initial pass is done to check if it

did not catch the fire or smoke in the initial switch on.

Example:

If the project has 2 modules so before going to the module

make sure that module 1 works properly

5. Alpha Testing

This is a type of validation testing. It is a type of acceptance testing which

is done before the product is released to customers. It is typically done by
QA people.

Example:

When software testing is performed internally within

the organization

6. Beta Testing
The beta test is conducted at one or more customer sites by the end-user
of the software. This version is released for a limited number of users for
testing in a real-time environment

Example:

When software testing is performed for the limited

number of people

7. System Testing

This software is tested such that it works fine for the different operating
systems. It is covered under the black box testing technique. In this, we
just focus on the required input and output without focusing on internal
working.

In this, we have security testing, recovery testing, stress testing, and

performance testing

Example:

This includes functional as well as nonfunctional

testing

8. Stress Testing
In this, we give unfavorable conditions to the system and check how they
perform in those conditions.

Example:

(a) Test cases that require maximum memory or other

resources are executed
(b) Test cases that may cause thrashing in a virtual
operating system

(c) Test cases that may cause excessive disk requirement

9. Performance Testing

It is designed to test the run-time performance of software within the

context of an integrated system. It is used to test the speed and
effectiveness of the program. It is also called load testing. In it we check,
what is the performance of the system in the given load.

Example: Checking several processor cycles.

10. Object-Oriented Testing

This testing is a combination of various testing techniques that help to
verify and validate object-oriented software. This testing is done in the
following manner:

● Testing of Requirements,
● Design and Analysis of Testing,
● Testing of Code,
 ● Integration testing,
● System testing,
● User Testing.

11. Acceptance Testing

Acceptance testing is done by the customers to check whether the
delivered products perform the desired tasks or not, as stated in
requirements.

Functional testing|(Black-Box Testing)

The technique of testing without having any knowledge of the interior workings of
the application is called black-box testing. The tester is oblivious to the system
architecture and does not have access to the source code. Typically, while
performing a black-box test, a tester will interact with the system's user interface
by providing inputs and examining outputs without knowing how and where the
inputs are worked upon.

The following table lists the advantages and disadvantages of black-box testing.

Advantages Disadvantages

Well suited and efficient for large Limited coverage, since only a
code segments. selected number of test scenarios
is actually performed.

Code access is not required. Inefficient testing, due to the fact

that the tester only has limited
knowledge about an application.
 Clearly separates the user's Blind coverage, since the tester
perspective from the developer's cannot target specific code
perspective through visibly defined segments or error prone areas.
roles.

Large numbers of moderately The test cases are difficult to

skilled testers can test the design.
application with no knowledge of
implementation, programming
language, or operating systems.

Structural Testing(White-Box Testing)

White-box testing is the detailed investigation of internal logic and structure of
the code. White-box testing is also called glass testing or open-box testing. In
order to perform white-box testing on an application, a tester needs to know the
internal workings of the code.

The tester needs to have a look inside the source code and find out which
unit/chunk of the code is behaving inappropriately.

The following table lists the advantages and disadvantages of white-box testing.

Advantages Disadvantages

As the tester has knowledge of the Due to the fact that a skilled tester
source code, it becomes very easy is needed to perform white-box
to find out which type of data can testing, the costs are increased.
help in testing the application
effectively.
 It helps in optimizing the code. Sometimes it is impossible to look
into every nook and corner to find
out hidden errors that may create
problems, as many paths will go
untested.

Extra lines of code can be removed It is difficult to maintain white-box

which can bring in hidden defects. testing, as it requires specialized
tools like code analyzers and
debugging tools.

Due to the tester's knowledge

about the code, maximum coverage
is attained during test scenario
writing.

Grey-Box Testing
Gray-box testing is a technique to test the application with having a limited
knowledge of the internal workings of an application. In software testing, the
phrase the more you know, the better carries a lot of weight while testing an
application.

Mastering the domain of a system always gives the tester an edge over someone
with limited domain knowledge. Unlike black-box testing, where the tester only
tests the application's user interface; in grey-box testing, the tester has access to
design documents and the database. Having this knowledge, a tester can prepare
better test data and test scenarios while making a test plan.

Advantages Disadvantages
 Offers combined benefits of Since the access to source code is
black-box and white-box testing not available, the ability to go over
wherever possible. the code and test coverage is
limited.

Grey box testers don't rely on the The tests can be redundant if the
source code; instead they rely on software designer has already run a
interface definition and functional test case.
specifications.

Based on the limited information Testing every possible input stream

available, a gray-box tester can is unrealistic because it would take
design excellent test scenarios an unreasonable amount of time;
especially around communication therefore, many program paths will
protocols and data type handling. go untested.

The test is done from the point of

view of the user and not the
designer.

A Comparison of Testing Methods

The following table lists the points that differentiate black-box testing, grey-box
testing, and white-box testing.

Black-Box Testing Grey-Box Testing White-Box Testing

The internal workings The tester has limited Tester has full
of an application need knowledge of the knowledge of the
not be known. internal workings of the internal workings of
application. the application.

Also known as Also known as Also known as

closed-box testing, translucent testing, as clear-box testing,
data-driven testing, or the tester has limited structural testing, or
functional testing. knowledge of the code-based testing.
insides of the
application.

Performed by Performed by end-users Normally done by

end-users and also by and also by testers and testers and
testers and developers. developers.
developers.

Testing is based on Testing is done on the Internal workings are

external expectations - basis of high-level fully known and the
Internal behavior of the database diagrams and tester can design
application is data flow diagrams. test data accordingly.
unknown.

It is exhaustive and the Partly time-consuming The most exhaustive

least time-consuming. and exhaustive. and time-consuming
type of testing.

Not suited for Not suited for algorithm Suited for algorithm
algorithm testing. testing. testing.
 This can only be done Data domains and Data domains and
by trial-and-error internal boundaries can internal boundaries
method. be tested, if known. can be better tested.

Software Testing – Boundary Value

Analysis(used for test stubs)
Functional testing is a type of software testing in which the system is
tested against the functional requirements of the system. It is conducted to
ensure that the requirements are properly satisfied by the application.
Functional testing verifies that each function of the software application
works in conformance with the requirement and specification. Boundary
Value Analysis(BVA) is one of the functional testing methods.

Boundary Value Analysis

Boundary Value Analysis is based on testing the boundary values of valid

and invalid partitions. The behavior at the edge of the equivalence partition
is more likely to be incorrect than the behavior within the partition, so
boundaries are an area where testing is likely to yield defects.

It checks for the input values near the boundary that have a higher chance
of error. Every partition has its maximum and minimum values and these
maximum and minimum values are the boundary values of a partition.

Note:
 ● A boundary value for a valid partition is a valid boundary value.
● A boundary value for an invalid partition is an invalid boundary
value.
● For each variable we check-
○ Minimum value.
○ Just above the minimum.
○ Nominal Value.
○ Just below Max value.
○ Max value.

Example: Consider a system that accepts ages from 18 to 56.

Boundary Value Analysis(Age accepts 18 to 56)

Valid
Invalid
Invalid

(min, min + 1,
(max +
(min-1) nominal, max – 1,
1)
max)
 17 18, 19, 37, 55, 56 57

Valid Test cases: Valid test cases for the above can be any value entered
greater than 17 and less than 57.

● Enter the value- 18.

● Enter the value- 19.
● Enter the value- 37.
● Enter the value- 55.
● Enter the value- 56.

Invalid Test Cases: When any value less than 18 and greater than 56 is
entered.

● Enter the value- 17.

● Enter the value- 57.

Single Fault Assumption: When more than one variable for the same
application is checked then one can use a single fault assumption. Holding
all but one variable to the extreme value and allowing the remaining
variable to take the extreme value. For n variable to be checked:

Maximum of 4n+1 test cases

Problem: Consider a Program for determining the Previous Data.

Input: Day, Month, Year with valid ranges as-

1 ≤ Month≤12

1 ≤ Day ≤31

1900 ≤ Year ≤ 2000

Design Boundary Value Test Cases.

Solution: Taking the year as a Single Fault Assumption i.e. year will be
having values varying from 1900 to 2000 and others will have nominal
values.

Test Mont Da Yea

Output
Cases h y r
 14 June
1 6 15 1990
1990

14 June
2 6 15 1901
1901

14 June
3 6 15 1960
1960

14 June
4 6 15 1999
1999

14 June
5 6 15 2000
2000

Taking Day as Single Fault Assumption i.e. Day will be having values
varying from 1 to 31 and others will have nominal values.
 Test Mont Da Yea
Output
Case h y r

6 6 1 1960 31 May 1960

7 6 2 1960 1 June 1960

29 June
8 6 30 1960
1960

9 6 31 1960 Invalid day

Taking Month as Single Fault Assumption i.e. Months will have values
varying from 1 to 12 and others will have nominal values.
 Test Mont Da Yea
Output
Case h y r

10 1 15 1960 14 Jan 1960

14 Feb
11 2 15 1960
1960

14 Nov
12 11 15 1960
1960

14 Dec
13 12 15 1960
1960

For the n variable to be checked Maximum of 4n + 1 test case will be

required. Therefore, for n = 3, the maximum test cases are-

4 × 3 + 1 =13
The focus of BVA: BVA focuses on the input variable of the function. Let’s
define two variables X1 and X2, where X1 lies between a and b and X2 lies
between c and d.

Showing legitimate domain

The idea and motivation behind BVA are that errors tend to occur near the
extremes of the variables. The defect on the boundary value can be the
result of countless possibilities.

Typing of Languages: BVA is not suitable for free-form languages such as

COBOL and FORTRAN, These languages are known as weakly typed
languages. This can be useful and can cause bugs also.

PASCAL, ADA is the strongly typed language that requires all constants or
variables defined with an associated data type.

Limitation of Boundary Value Analysis:

● It works well when the product is under test.

● It cannot consider the nature of the functional dependencies of
variables.
● BVA is quite rudimentary.
Equivalence Partitioning

It is a type of black-box testing that can be applied to all levels of software

testing. In this technique, input data are divided into the equivalent
partitions that can be used to derive test cases-

● In this input data are divided into different equivalence data

classes.
● It is applied when there is a range of input values.

Example: Below is the example to combine Equivalence Partitioning and

Boundary Value.

Consider a field that accepts a minimum of 6 characters and a maximum of

10 characters. Then the partition of the test cases ranges 0 – 5, 6 – 10, 11 –
14.

Test Scenario Test Description Expected Outcome

Enter value 0 to 5
1 Not accepted
character
 2 Enter 6 to 10 character Accepted

3 Enter 11 to 14 character Not Accepted

Why Combine Equivalence Partitioning and Boundary Analysis Testing:

Following are some of the reasons why to combine the two approaches:

● In this test cases are reduced into manageable chunks.

● The effectiveness of the testing is not compromised on test cases.
● Works well with a large number of variables.

Static Testing is a type of a Software Testing method which is performed to

check the defects in software without actually executing the code of the
software application. Whereas in Dynamic Testing the code is executed to
detect the defects.

Static testing is performed in the early stage of development to avoid errors

as it is easier to find sources of failures and it can be fixed easily. The
errors that can’t not be found using Dynamic Testing, can be easily found
by Static Testing.

Static Testing Techniques:

There are mainly two type techniques used in Static Testing:

1. Review:

In static testing review is a process or technique that is performed to find

the potential defects in the design of the software. It is a process to detect
and remove errors and defects in the different supporting documents like
software requirements specifications. People examine the documents and
sort out errors, redundancies and ambiguities.

Review is of four types:

● Informal:
In informal review the creator of the documents put the contents in
front of the audience and everyone gives their opinion and thus
defects are identified in the early stage.
 ● Walkthrough:
It is basically performed by an experienced person or expert to
check the defects so that there might not be problems further in
the development or testing phase.
● Peer review:
Peer review means checking documents of one-another to detect
and fix the defects. It is basically done in a team of colleagues.
● Inspection:
Inspection is basically the verification of documents by higher
authority like the verification of software requirement
specifications (SRS).

2. Static Analysis:

Static Analysis includes the evaluation of the code quality that is written by
developers. Different tools are used to do the analysis of the code and
comparison of the same with the standard.

It also helps in following identification of following defects:

(a) Unused variables

(b) Dead code

(c) Infinite loops

(d) Variable with undefined value

 (e) Wrong syntax

Static Analysis is of three types:

● Data Flow:
Data flow is related to stream processing.
● Control Flow:
Control flow is basically how the statements or instructions are
executed.
● Cyclomatic Complexity:
Cyclomatic complexity is the measurement of the complexity of
the program that is basically related to the number of independent
paths in the control flow graph of the program.

Note:- Exhaustive testing is not possible.