1. Fundamental of testing.

● Software testing is performed, once software engineers have written the source
code. Software testing is the process of finding defects in the software so that these
can be debugged and the defect-free software can meet the customer needs and
expectations.
● The intension of the software testing process is to produce defect-free system. A
Quality software can be achieved through testing. Effective testing reduces the
maintenance cost and provides reliable outcomes. Ineffective testing may lead to
software failure. Some failures may be dangerous. Testing is done with test cases.
● Testing provides a systematic approach to finding defects in software. Error-free
software may fail in performing the required tasks. The goal of software testers is to
locate and debug the effects.
● Software testers always try to prove that the system is incorrect by applying test
cases. To perform successful testing, testers must have a thorough understanding of
the whole system and its sub systems from requirements specification to
implementation.
Basic concept or terminologies
Errors:
● These are actual coding mistakes made by developers. In addition, there is a
difference in output of software and desired output, is considered as an error.
● Error is the discrepancy between the actual value of the output of software and the
theoretically correct value of the output for the given input.
● It is observed that most of the times errors occur during writing of programs by
programmers.
● A software tester begins with finding any error in the source code. The error is also
known as variance, mistake, or problem.
Fault:
● When error exists fault occurs. A fault, also known as a bug, is a result of an error,
which can cause system to fail.
● Fault is also called defect or bug, which is the manifestation of one or more errors.
The cause of an error is a fault (Either hardware fault or software fault), which
resides temporarily or permanently in the system.
● Mostly faults are observed at the architecture or design level or they might be a
faulty source code.
Failure:
● Failure is said to be the inability of the system to perform the desired task. Failure
occurs when fault exists in the system.
● Failure is the deviation of the observed behaviour from the specified behaviour. It
occurs when the faulty code is executed leading to an incorrect outcome. A failure is
the manifestation of an error in the system or software.
 ● A failure occurs because the system is erroneous. An error is caused by a fault and
may propagate to become a failure.
Test case:
● This is the triplet [I,S,O], where I is the data input to the system, S is the state of the
system at which the data is input, and O is the expected output of the system.
Test suite:
● This is the set of all test cases with which a given software product is to be tested
Verification vs. Validation
● Verification is the process of determining whether the output of one phase of
software development conforms to that of its previous phase, whereas validation is
the process of determining whether a fully developed system conforms to its
requirements specification. Thus while verification is concerned with phase
containment of errors, the aim of validation is that the final product be error free.
o Verification: “Are we building the product right?”
o Validation: “ Are we building the right product? ”
Testing involves performing the following main activities:
● Test suite design: The set of test cases using which a program is to be tested is
designed using different test case design techniques. The information about the
designing the test cases are obtained from code, design document and the SRS
document.
● Running test cases and checking the results to detect failures: Each test case is run
and the results are compared with the expected results. A mismatch between actual
and expected result indicate a failure. These test cases are noted down for later
debugging.
● Debugging: Debugging is carried out to identify the statements that are in error. In
this, failure symptoms are analyzed to locate the errors.
● Error correction: After the error is located in the previous activity, the code is
appropriately changed to correct the error.
The testing process can be represented using the following diagram:
Software Testing Fundamentals
1. Testability. James Bach1 provides the following definition for testability: “Software
testability is simply how easily [a computer program] can be tested.” The following
characteristics lead to testable software.
2. Operability. “The better it works, the more efficiently it can be tested.” If a system is
designed and implemented with quality in mind, relatively few bugs will block the
execution of tests, allowing testing to progress without fits and starts.
3. Observability. “What you see is what you test.” Inputs provided as part of testing
produce distinct outputs. System states and variables are visible or queriable during
execution. Incorrect output is easily identified. Internal errors are automatically
detected and reported. Source code is accessible.
4. Controllability. “The better we can control the software, the more the testing can be
automated and optimized.” All possible outputs can be generated through some
combination of input, and I/O formats are consistent and structured. All code is
executable through some combination of input. Software and hardware states and
variables can be controlled directly by the test engineer. Tests can be conveniently
specified, automated, and reproduced.
5. Decomposability. “By controlling the scope of testing, we can more quickly isolate
problems and perform smarter retesting.” The software system is built from
independent modules that can be tested independently.
6. Simplicity. “The less there is to test, the more quickly we can test it.” The program
should exhibit functional simplicity (e.g., the feature set is the minimum necessary to
meet requirements); structural simplicity (e.g., architecture is modularized to limit
the propagation of faults), and code simplicity (e.g., a coding standard is adopted for
ease of inspection and maintenance).
 7. Stability. “The fewer the changes, the fewer the disruptions to testing.” Changes to
the software are infrequent, controlled when they do occur, and do not invalidate
existing tests. The software recovers well from failures.
8. Understandability. “The more information we have, the smarter we will test.” The
architectural design and the dependencies between internal, external, and shared
components are well understood. Technical documentation is instantly accessible,
well organized, specific and detailed, and accurate. Changes to the design are
communicated to testers.

2. Internal and external views of testing:-They refer to two different perspectives on the
testing process, especially in the context of software development. These views help
understand the goals, scope, and approaches to testing from both an insider (internal) and
outsider (external) standpoint.
1. Internal View of Testing: The internal view of testing is concerned with how testing is
performed within the organization or development team. It focuses on the following
aspects:
a. Quality Assurance (QA): This perspective involves ensuring that the development
process is of high quality. It encompasses practices, standards, and methodologies
followed by the development team to prevent defects.
b. Unit Testing: This is the lowest level of testing, where individual units or
components of the software are tested in isolation. It ensures that each part of the
code functions as expected.
c. Integration Testing: At this level, the interaction between different units or
modules is tested to uncover issues related to the integration of these components.
d. System Testing: This encompasses testing the entire system as a whole, verifying
that it meets the specified requirements and functions correctly. It is performed
before the software is released.
e. Acceptance Testing: This is a type of testing that validates if the software meets
user or customer requirements and can be accepted for use. It may include user
acceptance testing (UAT) or other forms of customer validation.
f. Continuous Integration and Continuous Testing: An internal view also considers
automated testing practices, such as continuous integration (CI) and continuous
testing, which are integrated into the development process to ensure that code
changes do not introduce defects.
g. Test Automation: The automation of testing processes, from unit tests to
regression tests, is a crucial aspect of the internal view. It helps maintain quality and
efficiency in the development process.
2. External View of Testing: The external view of testing is concerned with how testing
is perceived and experienced by those outside the development team, such as
end-users, clients, or other stakeholders. It includes the following aspects:
 a. User Experience Testing: This perspective assesses how the end-users or
customers experience the software. It includes usability testing and user acceptance
testing, which focus on user satisfaction and ease of use.
b. Beta Testing: External users or a select group of customers are given access to the
software to identify issues and provide feedback before the final release.
c. Security Testing: An external view also emphasizes the assessment of the
software's security to identify vulnerabilities that could be exploited by malicious
actors.
d. Compliance and Certification: For software that needs to adhere to specific
industry standards or regulations, external views include compliance testing and
certification, ensuring that the software meets the required standards.
e. Performance Testing: This perspective evaluates how the software performs under
different conditions, such as load testing, stress testing, and scalability testing. It
helps ensure the software can handle the expected user load.
f. User Documentation and Training: External testing includes the evaluation of user
documentation, help guides, and training materials to ensure that they are clear and
effective for users.

Both internal and external views of testing are essential for delivering high-quality software.
The internal view focuses on the development process and quality control, while the
external view ensures that the software meets user needs and expectations. Effective testing
strategies encompass both perspectives to achieve a balance between internal quality and
external satisfaction.

3.White Box Testing:- White-box testing, sometimes called glass-box testing, is a test-case
design philosophy that uses the control structure described as part of component-level
design to derive test cases. Using white-box testing methods, you can derive test cases that
(1) guarantee that all independent paths within a module have been exercised at least once,
(2) exercise all logical decisions on their true and false sides, (3) execute all loops at their
boundaries and within their operational bounds, and (4) exercise internal data structures to
ensure their validity.
White box testings we discuss here are
1.Basis Path Testing
2.Control Structure Testing
1.Basis Path Testing:- Path Testing Basis Path Testing is a white-box testing technique based
on the control structure of a program or a module. Using this structure, a control flow graph
is prepared and the various possible paths present in the graph are executed as a part of
testing. Therefore, by definition, Basis path testing is a technique of selecting the paths in
the control flow graph, that provide a basis set of execution paths through the program or
module. Since this testing is based on the control structure of the program, it requires
complete knowledge of the program’s structure. To design test cases using this technique,
four steps are followed :
1. Construct the Control Flow Graph
 2. Compute the Cyclomatic Complexity of the Graph
3. Identify the Independent Paths
4. Design Test cases from Independent Paths
Let’s understand each step one by one. 1. Control Flow Graph – A control flow graph (or
simply, flow graph) is a directed graph which represents the control structure of a program
or module. A control flow graph (V, E) has V number of nodes/vertices and E number of
edges in it. A control graph can also have :
● Junction Node – a node with more than one arrow entering it.
● Decision Node – a node with more than one arrow leaving it.
● Region – area bounded by edges and nodes (area outside the graph is also
counted as a region.).

Below are the notations used while constructing a flow graph :

● Sequential Statements –
● If – Then – Else –

● Do – While –

● While – Do –
● Switch – Case –

Cyclomatic Complexity – The cyclomatic complexity V(G) is said to be a measure of the

logical complexity of a program. It can be calculated using three different formulae :
1. Formula based on edges and nodes :
V(G) = e - n + 2*P
1. Where, e is number of edges, n is number of vertices, P is number of connected
components. For example, consider first graph given above,
where, e = 4, n = 4 and p = 1

So,
Cyclomatic complexity V(G)
=4-4+2*1
=2
1. Formula based on Decision Nodes :
V(G) = d + P
1. where, d is number of decision nodes, P is number of connected nodes. For
example, consider first graph given above,
where, d = 1 and p = 1

So,
Cyclomatic Complexity V(G)
=1+1
=2
1. Formula based on Regions :
V(G) = number of regions in the graph
 1. For example, consider first graph given above,
Cyclomatic complexity V(G)
= 1 (for Region 1) + 1 (for Region 2)
=2
Hence, using all the three above formulae, the cyclomatic complexity obtained remains
same. All these three formulae can be used to compute and verify the cyclomatic complexity
of the flow graph. Note –
1. For one function [e.g. Main( ) or Factorial( ) ], only one flow graph is constructed.
If in a program, there are multiple functions, then a separate flow graph is
constructed for each one of them. Also, in the cyclomatic complexity formula, the
value of ‘p’ is set depending of the number of graphs present in total.
2. If a decision node has exactly two arrows leaving it, then it is counted as one
decision node. However, if there are more than 2 arrows leaving a decision node,
it is computed using this formula :
d=k-1
1. Here, k is number of arrows leaving the decision node.
Independent Paths : An independent path in the control flow graph is the one which
introduces at least one new edge that has not been traversed before the path is defined. The
cyclomatic complexity gives the number of independent paths present in a flow graph. This
is because the cyclomatic complexity is used as an upper-bound for the number of tests that
should be executed in order to make sure that all the statements in the program have been
executed at least once. Consider first graph given above here the independent paths would
be 2 because number of independent paths is equal to the cyclomatic complexity. So, the
independent paths in above first given graph :
● Path 1:
A -> B
● Path 2:
C -> D
Note – Independent paths are not unique. In other words, if for a graph the cyclomatic
complexity comes out be N, then there is a possibility of obtaining two different sets of
paths which are independent in nature. Design Test Cases : Finally, after obtaining the
independent paths, test cases can be designed where each test case represents one or more
independent paths.

Advantages : Basis Path Testing can be applicable in the following cases:

1. More Coverage – Basis path testing provides the best code coverage as it aims to
achieve maximum logic coverage instead of maximum path coverage. This results
in an overall thorough testing of the code.
2. Maintenance Testing – When a software is modified, it is still necessary to test
the changes made in the software which as a result, requires path testing.
3. Unit Testing – When a developer writes the code, he or she tests the structure of
the program or module themselves first. This is why basis path testing requires
enough knowledge about the structure of the code.
 4. Integration Testing – When one module calls other modules, there are high
chances of Interface errors. In order to avoid the case of such errors, path testing
is performed to test all the paths on the interfaces of the modules.
2. Control Structure Testing:-

Although basis path testing is simple and highly effective, it is not sufficient in itself. In this
section, other variations on control structure testing are discussed. These broaden testing
coverage and improve the quality of white-box testing.
1. Condition Testing Condition testing is a test-case design method that
exercises the logical conditions contained in a program module. A simple
condition is a Boolean variable or a relational expression, possibly preceded
with one NOT (¬) operator. A relational expression takes the form E1 E2
where E1 and E2 are arithmetic expressions and is one of the following: , , ,
(nonequality), , or . A compound condition is composed of two or more
simple conditions, Boolean operators, and parentheses. We assume that
Boolean operators allowed in a compound condition include OR (), AND (&),
and NOT (¬). A condition without relational expressions is referred to as a
Boolean expression. If a condition is incorrect, then at least one component
of the condition is incorrect. Therefore, types of errors in a condition include
Boolean operator error (incorrect/missing/extra Boolean operators), Boolean
variable errors, Boolean parenthesis errors, relational operator errors, and
arithmetic expression errors. The condition testing method focuses on testing
each condition in the program to ensure that it does not contain errors.

2. Data Flow Testing:- The data flow testing method [Fra93] selects test paths of
a program according to the locations of definitions and uses of variables in
the program. To illustrate the data flow testing approach, assume that each
statement in a program is assigned a unique statement number and that each
function does not modify its parameters or global variables. For a statement
with S as its statement number,

DEF(S) {X | statement S contains a definition of X}

USE(S) {X | statement S contains a use of X} If statement S is
an if or loop statement, its DEF set is empty and its USE set is based on
the condition of statement S. The definition of variable X at statement
S is said to be live at statement S’ if there exists a path from statement
S to statement S’ that contains no other definition of X.

3. Loop Testing
Loops are the cornerstone for the vast majority of all
algorithms implemented in software. And yet, we often pay them little
heed while conducting software tests. Loop testing is a white-box
testing technique that focuses exclusively on the validity of loop
constructs. Four different classes of loops [Bei90] can be defined:
simple loops, concatenated loops, nested loops, and unstructured
loops.
3.1 Simple loops.
 The following set of tests can be applied to simple
loops, where n is the maximum number of allowable passes
through the loop.

1. Skip the loop entirely.

2. Only one pass through the loop.
3. Two passes through the loop.

4. m passes through the loop where m <n.

5. n - 1, n, n + 1 passes through the loop

3.2 Nested loops. If we were to extend the test approach for simple
loops to nested loops, the number of possible tests would grow geometrically
as the level of nesting increases. This would result in an impractical number
of tests. Beizer [Bei90] suggests an approach that will help to reduce the
number of tests:
1. Start at the innermost loop. Set all other loops to minimum values.
2. Conduct simple loop tests for the innermost loop while holding the
outer loops at their minimum iteration parameter (e.g., loop counter) values.
Add other tests for out-of-range or excluded values.
3. Work outward, conducting tests for the next loop, but keeping all
other outer loops at minimum values and other nested loops to “typical”
values.
4. Continue until all loops have been tested.
3.3 Concatenated loops.
Concatenated loops can be tested using the approach defined for simple loops, if each of
the loops is independent of the other. However, if two loops are concatenated and the loop
counter for loop 1 is used as the initial value for loop 2, then the loops are not independent.
When the loops are not independent, the approach applied to nested loops is
recommended.
3.4 Unstructured loops.
 Whenever possible, this class of loops should be redesigned to reflect the use of the
structured programming constructs.

Black-box testing:- Black-box testing also called behavioral testing, focuses on the functional
requirements of the software. Black-box testing attempts to find errors in the following categories:

(1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external
database access, (4) behavior or performance errors, and (5) initialization and termination errors.