INTRODUCTION TO FAULTS AND FAILURES; BASIC TESTING CONCEPTS

5.1 INTRODUCTION TO FAULTS AND FAILURES

In software engineering, the terms error, fault, and failure are closely related but have different
meanings. Understanding their relationship is essential for testing and quality assurance.
5.1.1 Error
An error is a human mistake made by a software developer, designer, or analyst during any phase
of the software development life cycle. It may occur due to a misunderstanding of requirements,
wrong logic, or carelessness.
For example, a programmer may misunderstand the formula for calculating the total price and
write the wrong logic.

5.1.2 Fault
A fault (also called a defect or bug) is the result of an error that appears in the software code or
design. It is an incorrect step, process, or data definition in a computer program. Faults are
caused by human errors but exist within the software itself.
For example, if the programmer writes the statement
total = price * 0.01
instead of
total = price * 1.01
this incorrect formula in the source code is a fault. It does not yet cause visible problems until
the program is executed, but it exists within the software.
5.1.3 Failure
A failure occurs when the software containing a fault is executed and produces an incorrect or
unexpected output.
It is the external behavior of the software that deviates from the expected result.
Continuing the same example, when the program runs and displays the wrong total amount to
the customer, this incorrect result is called a failure.

Thus, the relationship among them can be described as:

Error (human mistake) → Fault (defect in code) → Failure (wrong output during execution)
5.1.4 Example for Fault and Failure
Example 1:
A developer forgets to handle a division by zero condition in a calculator program.
● Fault: Missing condition check (bug) in the code.
● Failure: When the user enters a denominator value of zero, the program crashes or shows
an error message instead of handling it gracefully.

Example 2:
In a railway ticket booking system, the developer writes wrong logic to calculate the total fare.
● Fault: Incorrect formula in the code (e.g., fare = distance × 5 instead of distance × 10).
● Failure: The user receives an incorrect total fare on the ticket screen.
From these examples, we can understand that faults are the root cause present inside the code,
while failures are the visible symptoms that occur when those faults are executed.

5.2 BASIC TESTING CONCEPTS

Software Testing is the process of executing a program with the intention of finding errors. It
helps to ensure that the software system meets its specified requirements and performs correctly
in real-world conditions. Testing is an essential activity for improving the quality, reliability, and
performance of a software product.
The main objective of testing is not only to detect faults but also to verify and validate the
software system.

5.2.1 Objectives of Software Testing

1. Verification: To check whether the software is being built correctly according to the
specified design and requirements.
2. Validation: To confirm whether the software fulfills the actual user needs and
expectations.
3. Fault Detection: To identify defects before the system is delivered to the customer.
4. Quality Improvement: To enhance the reliability, maintainability, and efficiency of the
system.

5.2.2 Important Testing Terms

● A test case is a set of inputs, execution conditions, and expected results designed to test
a particular aspect of the software.
● Test data refers to the specific data values used to run test cases.
● A test plan is a document that describes the testing strategy, scope, objectives, and
resources required.
● A test suite is a collection of related test cases grouped together to test a specific module
or function.
● The expected result is what the program should produce, while the actual result is what
it really produces during execution.

5.2.3 Principles of Software Testing

 1. Testing shows the presence of defects, not their absence. Testing can reveal defects but
cannot prove that the software is completely free of errors.
2. Exhaustive testing is impossible. It is not practical to test every possible input
combination.
3. Early testing saves time and cost. Testing should begin early in the development process
to detect defects sooner.
4. Defect clustering: Most defects are often found in a small number of modules.
5. Pesticide paradox: Repeating the same tests will not find new defects; test cases must be
regularly reviewed and updated.
6. Testing is context dependent: The type and level of testing vary depending on the
software and its purpose.
7. Absence-of-errors fallacy: Even if no defects are found, the software may still fail to meet
user needs.

5.2.4 Basic Types of Testing

1. Unit Testing: Involves testing individual components or modules of a program to ensure
each part works correctly.
2. Integration Testing: Tests combined parts of a program to ensure they function together
as expected.
3. System Testing: Tests the entire integrated system to verify that it meets all specified
requirements.
4. Acceptance Testing: Conducted to ensure the system meets business needs and is ready
for delivery to the user.

5.2.5 Example of Testing in Practice

Suppose a banking application is developed to calculate interest on a deposit.
If the developer mistakenly writes the formula for interest calculation incorrectly (for example,
uses a wrong rate), that is a fault in the program. When the software executes and displays an
incorrect interest amount to the customer, that becomes a failure.
Testing helps to identify such faults before the software is released so that the failures do not
occur in real usage.
5.3 VERIFICATION AND VALIDATION

5.3.1 Verification and Validation

Verification and Validation is the process of investigating whether a software system satisfies
specifications and standards and fulfills the required purpose. Verification and Validation both
play an important role in developing good software development. Verification helps in examining
whether the product is built right according to requirements, while validation helps in examining
whether the right product is built to meet user needs.

What is Verification?

Verification is the process of checking that software achieves its goal without any bugs. It is the
process to ensure whether the product that is developed is right or not. It verifies whether the
developed product fulfills the requirements that we have. Verification is static
testing. Verification means Are we building the product, right?

What is Validation?

Validation is the process of checking whether the Software Product is up to the mark or in other
words product has high-level requirements. It is the process of checking the validation of the
product i.e. it checks what we are developing is the right product. It is validation of the actual
and expected products. Validation is dynamic testing. Validation means Are we building the right
product?

5.3.2 Differences between Verification and Validation

Here is the Differences between Verification and Validation

Verification Validation
Verification refers to the set of Validation refers to the set of activities
activities that ensure software that ensure that the software that has
Definition
correctly implements the specific been built is traceable to customer
function requirements.
It includes checking documents, It includes testing and validating the
Focus
designs, codes, and programs. actual product.
Type of Testing Verification is the Static testing. Validation is Dynamic testing.
It does not include the execution of the
Execution It includes the execution of the code.
code.
Methods used in verification are Methods used in validation are Black
Methods Used reviews, walkthroughs, inspections and Box Testing, White Box
desk-checking. Testing and Non-Functional testing.
 It checks whether the software meets
It checks whether the software
Purpose the requirements and expectations of
conforms to specifications or not.
a customer or not.
It can find the Bugs in the early stage of It can only find the bugs that could not
Bug
the development. be found by the verification process.
The goal of verification is application
The goal of validation is an actual
Goal and software architecture and
product.
specification.
Verification is typically performed by
the quality assurance (QA) team, Validation is performed by the testing
focusing on reviewing documents, team, which executes the software in
Responsibility
designs, and code to ensure real environments to ensure it meets
compliance with specified user expectations and requirements.
requirements.
Timing It comes before validation. It comes after verification.
It consists of checking of
Human or It consists of execution of program and
documents/files and is performed by
Computer is performed by computer.
human.
After a valid and completeValidation begins as soon as project
Lifecycle
specification, the verification starts. starts.
Error Focus Verification is for prevention of errors.
Validation is for detection of errors.
Verification is also termed as white boxValidation can be termed as black box
Another
testing or static testing as work product
testing or dynamic testing as work
Terminology
goes through reviews. product is executed.
Verification finds about 50 to 60% of Validation finds about 20 to 30% of the
Performance
the defects. defects.
Validation is based on the fact and is
Verification is based on the opinion of
often stable.
Stability reviewer and may change from person
to person.

5.3.3 Real-World Example of Verification vs Validation

● Verification Example: Imagine a team is developing a new mobile banking app. During
the verification phase, they review the requirements and design documents. They check
if all the specified features like fund transfer, account balance check, and transaction
history are included and correctly detailed in the design. They also perform peer reviews
and inspections to ensure the design aligns with the requirements. This step ensures that
the app is being built according to the initial plan and specifications without actually
running the app.
 ● Validation Example: In the validation phase, the team starts testing the mobile banking
app on actual devices. They check if users can log in, transfer money, and view their
transaction history as intended. Testers perform usability tests to ensure the app is user-
friendly and functional tests to ensure all features work correctly. They might also involve
real users to provide feedback on the app's performance. This phase ensures that the app
works as expected and meets user needs in real-world scenarios.

5.3.4 Advantages of Differentiating Verification and Validation

Differentiating between verification and validation in software testing offers several advantages:

1. Clear Communication: It ensures that team members understand which aspects of the
software development process are focused on checking requirements (verification) and
which are focused on ensuring functionality (validation).

2. Efficiency: By clearly defining verification as checking documents and designs without

executing code, and validation as testing the actual software for functionality and
usability, teams avoid redundant efforts and streamline their testing processes.

3. Minimized Errors: It reduces the chances of overlooking critical requirements or

functionalities during testing, leading to a more thorough evaluation of the software's
capabilities.

4. Cost Savings: Optimizing resource allocation and focusing efforts on the right testing
activities based on whether they fall under verification or validation helps in managing
costs effectively.

5. Client Satisfaction: Ensuring that software meets or exceeds client and user expectations
by conducting both verification and validation processes rigorously improves overall
software quality and user satisfaction.

6. Process Improvement: By distinguishing between verification and validation,

organizations can refine their testing methodologies, identify areas for improvement, and
enhance the overall Software development lifecycle (SDLC).

5.4 BLACK BOX AND WHITE BOX TESTS

5.4.1 What is Black Box Testing?
Black-Box Testing is a Type of Software Testing in which the tester is not concerned with the
software’s internal knowledge or implementation details but rather focuses on validating
the functionality based on the provided specifications or requirements.
 The following are the several categories of black box testing:
1. Functional Testing
2. Regression Testing
3. Nonfunctional Testing (NFT)

5.4.2 What is White Box Testing?

White-box Testing is a Software Testing Technique that involves testing the internal structure
and workings of a Software Application. The tester has access to the source code and uses this
knowledge to design test cases that can verify the correctness of the software at the code level.
It is also called Glass Box Testing or Clear Box Testing or Structural Testing.
White Box Testing

White box testing can be done for different purposes. The three main types are:
1. Unit Testing
2. Integration Testing
3. Regression Testing
5.4.3 Comparison of Black Box Testing Vs White Box Testing
Parameters Black Box Testing White Box Testing
Black Box Testing is a way of software
White Box Testing is a way of testing the
testing in which the internal structure or
Definition software in which the tester has
the program or the code is hidden and
knowledge about the internal structure
nothing is known about it.
 or the code or the program of the
software.
Black box testing is mainly focused on
White box testing is mainly focused on
Testing testing the functionality of the software,
ensuring that the internal code of the
objectives ensuring that it meets the requirements
software is correct and efficient.
and specifications.
Black box testing uses methods White box testing uses methods
like Equivalence Partitioning, Boundary like Control Flow Testing, Data Flow
Testing methods
Value Analysis, and Error Guessing to Testing and Statement Coverage
create test cases. Testing.
Black box testing does not require any White box testing requires knowledge
knowledge of the internal workings of of programming languages, software
Knowledge level the software, and can be performed by architecture and design patterns.
testers who are not familiar with
programming languages.
Black box testing is generally used for White box testing is used for testing the
Scope testing the software at the functional software at the unit level, integration
level. level and system level.
Implementation of code is not needed Code implementation is necessary for
Implementation
for black box testing. white box testing.
Black Box Testing is mostly done by White Box Testing is mostly done by
Done By
software testers. software developers.
Black Box Testing can be referred to as White Box Testing is the inner or the
Terminology
outer or external software testing. internal software testing.
Black Box Testing is a functional test of White Box Testing is a structural test of
Testing Level
the software. the software.
Black Box testing can be initiated based
Testing White Box testing of software is started
on the requirement specifications
Initiation after a detail design document.
document.
No knowledge of programming is It is mandatory to have knowledge of
Programming
required. programming.
Black Box Testing is the behavior testing White Box Testing is the logic testing of
Testing Focus
of the software. the software.
White Box Testing is generally
Black Box Testing is applicable to the
Applicability applicable to the lower levels of
higher levels of testing of software.
software testing.
Alternative Black Box Testing is also called closed White Box Testing is also called as clear
Names testing. box testing.
Time Black Box Testing is least time White Box Testing is most time
Consumption consuming. consuming.
Suitable for
Black Box Testing is not suitable or White Box Testing is suitable for
Algorithm
preferred for algorithm testing. algorithm testing.
Testing
 Data domains along with inner or
Can be done by trial-and-error ways and
Approach internal boundaries can be better
methods.
tested.
Search something on google by using
Example By input to check and verify loops
keywords
It is less exhaustive as compared to It is comparatively more exhaustive
Exhaustiveness
white box testing. than black box testing.

5.4.4 Key Differences of Black Box and White Box Testing

● Black Box Testing focuses only on what the software does from the outside, without
looking at how it works internally. In contrast, White Box Testing examines the internal
workings and structure of the software.
● You do not need to understand how the system is built to do Black Box Testing, but for
White Box Testing, you need to know the code. Because of this, Black Box Testing is
usually quicker to perform than White Box Testing
5.4.5 Key Similarities of Black Box and White Box Testing
● White Box Testing and Black Box Testing serve different purposes, but both are essential
for ensuring that software works as expected. Together, they help verify that the software
is functioning properly and performing without any issues, ultimately leading to a more
reliable and improved version of the system.

5.5 WHITE BOX TEST COVERAGE – CODE COVERAGE, CONDITION COVERAGE, BRANCH
COVERAGE

5.5.1 Code Coverage

Code Coverage is a metric used in Software Testing that quantifies the extent to which the source
code of a program is tested. It measures the percentage of code executed by the test suite,
helping developers identify untested parts of an application.

As we know at last of the development each client wants a quality software product as well and
the developer team is also responsible for delivering a quality software product to the
customer/client. Where this quality refers to the product’s performance, functionalities,
behavior, correctness, reliability, effectiveness, security, and maintainability. Where Code
Coverage metric helps in determining the performance and quality aspects of any software. The
formula to calculate code coverage is

Code Coverage = (Number of lines of code executed) / (Total Number of lines of code in a system
component) * 100

Code Coverage Criteria

To perform code coverage analysis various criteria are taken into consideration. These are the
major methods/criteria which are considered.

1. Statement Coverage/Block coverage

The number of statements that have been successfully executed in the program source code.

Statement Coverage = (Number of statements executed) / (Total Number of statements) *100.

2. Decision Coverage/Branch Coverage

The number of decision control structures that have been successfully executed in the program
source code.

Decision Coverage = (Number of decision/branch outcomes exercised) / (Total number of

decision outcomes in the source code) *100.

3. Function coverage

The number of functions that are called and executed at least once in the source code.

Function Coverage = (Number of functions called) / (Total number of function) *100.

4. Condition Coverage/Expression Coverage

The number of Boolean condition/expression statements executed in the conditional statement.

Condition Coverage = (Number of executed operands) / (Total Number of Operands) *100.

[Link] Types of code coverage

Understanding the different types of code coverage helps in ensuring comprehensive testing of
your software. Here are the main types:
Types of code coverage
1. Statement Coverage
● Definition: Measures whether each line of code is executed.
● Purpose: Ensures that all code statements are tested at least once.
● Example: If a function has ten lines of code, statement coverage ensures each line is
executed during testing.
2. Branch Coverage (Decision Coverage)
● Definition: Measures whether each possible branch (true/false) from each decision point
is executed.
● Purpose: Ensures that all branches of control structures (like if-else statements) are
tested.
● Example: If a program has an if-else statement, both the if and the else branches should
be tested.
3. Function Coverage
● Definition: Measures whether each function or subroutine in the code is called.
● Purpose: Ensures that all functions in the code are invoked during testing.
● Example: In a class with multiple methods, function coverage ensures each method is
called at least once.
4. Condition Coverage (Predicate Coverage)
● Definition: Measures whether each Boolean sub-expression is evaluated to both true and
false.
● Purpose: Ensures that each condition in a decision has been tested for both true and false
outcomes.
● Example: In a compound condition like if (A && B), both A and B should be tested for true
and false values.
5. Path Coverage
 ● Definition: Measures whether all possible paths through the code are executed.
● Purpose: Ensures that all possible execution paths are tested.
● Example: For a function with multiple nested loops and conditionals, path coverage
would ensure all possible execution routes are tested.
6. Line Coverage
● Definition: Measures the number of executed lines divided by the total number of lines.
● Purpose: Provides a straightforward metric of how much of the codebase is executed.
● Example: If a file has 100 lines and 80 lines are executed during testing, line coverage
would be 80%.
7. Loop Coverage
● Definition: Measures whether loops are executed and how many times.
● Purpose: Ensures that loops are tested with zero, one, and multiple iterations.
● Example: For a loop that processes items in a list, loop coverage ensures the loop is tested
with an empty list, a single-item list, and a multiple-item list.
Each type of code coverage focuses on different aspects of the code, helping to ensure thorough
testing and improving overall software quality.
[Link] Tools for Code Coverage
Below are a few important code coverage tools
● JaCoCo
● Cobertura
● Emma
● Clover
● Codecov
● Coveralls
● Istanbul
● SonarQube
● NCover
● BullseyeCoverage
● Visual Studio Code Coverage
● dotCover
● OpenCover
● gcov
● Testwell CTC++
[Link] Advantages of Using Code Coverage
● It helps in determining the performance and quality aspects of any software.
● It helps in evaluating quantitative measures of code coverage.
● It helps in the easy maintenance of the code base.
● It helps in accessing the quality of the test suite and analyzing how comprehensively a
software is verified.
● It helps in the exposure of bad, dead, and unused code.
● It helps in creating extra test cases to increase coverage.
● It helps in developing the software product faster by increasing its productivity and
efficiency.
● It helps in measuring the efficiency of test implementation.
 ● It helps in finding new test cases that are uncovered.
[Link] Disadvantages of Using Code Coverage
● Sometimes it fails to cover code completely and correctly.
● It cannot guarantee that all possible values of a feature are tested with the help of code
coverage.
● It fails to ensure how perfectly the code has been covered.
● For some test files, additional mock data is required to execute the test cases.
● Sometimes it is difficult to cover the test cases handling functions.
● Lot of test cases are required to increase the test coverages for complex code.
● A developer must have strong knowledge of writing unit test cases to cover all possible
scenarios in the developed code.
5.5.2 CONDITION COVERAGE

The software condition coverage can be calculated by dividing the total count of conditions
executed with the total count of conditions in the source code, and then multiplied by hundred.

Condition Coverage = (Total count of conditions executed / Total count of conditions in the
source code) * 100

[Link] Why is Software Condition Coverage Testing Required?

The software condition coverage testing is required to ensure that the program source code is
working properly, and is able to satisfy the given requirements. It is observed that the traditional
testing methodologies sometimes miss particular paths in the code, thereby some of the critical
defects remain undetected. The software condition coverage testing takes care of these
situations by methodically verifying all the conditions inside the decision points. Thus it improves
the overall quality, and performance of the software.

[Link] How is Software Condition Coverage Testing Performed?

The software condition coverage testing are performed by following the steps listed below −

Step 1 − Determine the decision points or conditional statements in the program source code like
the if, else if, if, switch etc.

Step 2 − Every decision point may consist of more than one condition. These conditions are
evaluated, and split into simpler modules to have an exhaustive testing.

Step 3 − Design test cases to include every possible result of all the conditions namely true, and
false. It helps to cover every branch of code at the time of testing.

Step 4 − Execute the white box test cases, and evaluate the results. A coverage report is
generated to measure the extent of verification of the conditions. It also describes the validated,
and invalidated conditions, thereby it gives an idea if more fine tuning of the test cases are
needed.

[Link] Advantages of Software Condition Coverage Testing

The advantages of the software condition coverage testing are listed below −
● The software condition coverage testing guarantees that all the conditions in the code are
checked at least once.
● The software condition coverage testing detects defects from the early stages of the
software development life cycle(SDLC).
● The condition coverage testing improves the quality, maintainability, and reliability of the
software.
● The software condition coverage testing helps in faster troubleshooting of errors in the
code.
● The condition coverage testing gives higher confidence, and trust on the code developed
for the software.
[Link] Example

Let us take an example of the below code snippet to determine the count of the condition
coverage.

Input X, Y, Z, and W

IF (X == 0 || Y == 0)

THEN PRINT 100

ELSE IF (Z == 0 && W == 0)

THEN PRINT 200

END IF

END

Let us now calculate the condition coverage with the first test case, with the inputs X = 0, Y = 0,
Z = 0, W = 0. With these values, the first condition of the OR operator with the expression X == 0,
holds true. Since the result of the left side of the OR is already true, so the right side of the
expression, Y == 0 of it, will be skipped from evaluation.

So, the condition Y == 0 remained unchecked. Then, the statement 3 will be executed resulting
in printing 100 and the condition IF (Z == 0 && W == 0) in the ELSE part(at the line 4) will not be
executed. Hence, out of a total four conditions, only one of them got executed. The total
condition coverage as per formula:
Condition Coverage = (Total count of conditions executed / Total count of conditions in the
source code) * 100

Condition Coverage = (1 / 4) * 100 = 25 %.

Let us now calculate the condition coverage with the second test case, with the inputs X = 1, Y =
0, Z = 0, W = 0. With these values, the first condition having the OR operator with the expression
X == 1, holds false. As the result of the left side of the OR is false, so the right side expression Y
== 0 of it, will be evaluated. So this time, the condition Y == 0 is checked. Then, the statement 3
will be executed resulting in printing 100 and the condition IF (Z == 0 && W == 0) in the ELSE
part(at the line 4) will remain unchecked. Hence, out of a total four conditions, two of them got
executed. The total condition coverage as per formula

Condition Coverage = (Total count of conditions executed / Total count of conditions in the
source code) * 100

Condition Coverage = (2 / 4) * 100 = 50 %.

Let us now calculate the condition coverage with the third test case, with the inputs X = 1, Y = 1,
Z = 0, W = 0. With these values, the first condition having the OR operator with the expression X
== 1, holds false. As the left side of the OR is false, so the right side expression Y == 1 of it, will be
evaluated. Since both sides of the OR operator result in false, so this time, the condition IF (Z ==
0 && W == 0) in the ELSE part(at the line 4) will be executed.

The first condition having the AND operator with the expression Z == 0, holds true. Though the
left side of the AND operator is true, the right side expression W == 0 will also need to be
evaluated. Since both of them are true, then, the statement 5 will be executed resulting in
printing 200. Hence, out of total four conditions, four of them got executed this time. The total
condition coverage as per formula

Condition Coverage = (Total count of conditions executed / Total count of conditions in the source
code) * 100

Condition Coverage = (4 / 4) * 100 = 100 %.

[Link] Conclusion

This concludes our comprehensive take on the tutorial on Software Condition Coverage Testing.
Weve started with describing what is software condition coverage testing, formula to calculate
the software condition coverage percentage, why is software condition coverage testing
required, how is software condition coverage testing performed, what are the advantages of
software condition coverage testing, and an example to obtain the software condition coverage
percentage. This equips you with in-depth knowledge of Software Condition Coverage Testing. It
is wise to keep practicing what you’ve learned and exploring others relevant to Software Testing
to deepen your understanding and expand your horizons.

5.5.3 BRANCH COVERAGE

Branch coverage in unit testing is a metric that measures the percentage of branches (decision
points) in the source code that have been executed during the testing process. It indicates how
well the test cases navigate through different possible outcomes of conditional statements,
helping evaluate the thoroughness of testing. A high branch coverage means that most decision
paths in the code have been tested, increasing the likelihood of detecting potential defects.

1. Achieving comprehensive branch coverage is important for ensuring the reliability and
effectiveness of unit tests in identifying and addressing code issues.

2. This metric helps identify areas of code that may not have been adequately tested,
increasing the likelihood of detecting potential defects and enhancing the overall
reliability and quality of the software.

Formula for Branch Coverage:

Branch Coverage = ((Number of Executed Branches) ÷ (Total Number of Branches)) ✕ 100%

[Link] What is the Purpose of Branch Coverage in Unit Testing?

The main purpose of the Branch Coverage in Unit testing is that the test cases should cover each
branch statement inside the coding block or functions block. It is also known as decision
coverage.

1. Comprehensive Test Coverage: The primary purpose of Branch Coverage in unit testing
is to ensure test coverage by targeting each branch statement within code blocks or
functions. This is also known as decision coverage. It aims to verify that every possible
branch, including conditional and unconditional statements, has been executed at least
once during testing.

2. Conditional Statements Coverage: Branch Coverage addresses the coverage of

conditional statements such as if, if...else, while, for, and do...while statements in the
source code. The metric includes these conditional statements in the overall branch
coverage calculation for the file.

3. Unconditional Statements Coverage: The metric also encompasses the coverage of

unconditional statements in the source code, such as printable statements and return
 statements from functions and methods. These unconditional statements' coverage
contributes to the overall branch coverage for the file.

4. Execution of Branch Test Cases: Branch Coverage involves the execution of test cases
specifically designed for branch statements. These test cases are executed, and the
results are analyzed to ensure that each branch has been exercised.

5. Execution with Mock Data: To enhance test scenarios, Branch Coverage may utilize mock
data or additional data sets when executing branch test cases. This ensures a more
thorough examination of the code's decision paths.

[Link] What are Branch Coverage Metrics?

Branch Coverage Metrics serve to gauge the effectiveness of test coverage by measuring how
many branches or decision logics within the source code are covered. Typically expressed as a
percentage, the branch coverage percentage is a key indicator of testing thoroughness. The
evaluation formula is automated within testing software, where, for example, covering 7 out of
10 branch statements results in coverage of (7/10) * 100, yielding 70%. This indicates that 3
branch statements remain uncovered.

Test Coverage Evaluation

1. 70-80% Coverage: If the coverage falls between 70% and 80%, it's acceptable, but
improvements may be needed for overall coverage. This range is often flagged in yellow,
signaling a cautionary status.

2. Above 80% Coverage: Achieving coverage above 80% is considered efficient, and it is
typically highlighted in green, indicating a robust test coverage.

3. Below 70% Coverage: If coverage is below 70%, it is not recommended, and efforts
should be made to increase coverage. This is usually highlighted in red, signaling
inadequate test coverage that requires attention.

[Link] Example of Branch Coverage

Consider the following simple function that determines whether a person is eligible to vote based
on their age. The function has two conditional statements (if and else) and one unconditional
print statement. Branch coverage in unit testing for this function aims to cover all possible
branches, including both conditional and unconditional statements.

checkAge(int age) {

if (age >= 18)

print("Eligible to Vote")
else

print("Not Eligible to Vote")

print("Print the Age: %d" + age)

[Link] Branch Coverage Test Cases

1. Test Case 1 (True Positive): Create a test case to cover the if condition by providing an
age greater than or equal to 18. This scenario represents a True Positive, where the
individual is eligible to vote. This test case covers the if part of the function.

2. Test Case 2 (False Positive): Generate a test case to cover the other condition by
providing an age less than 18. This represents a False Positive scenario, where the
individual is not eligible to vote. This test case covers the other part of the function.

3. Test Case 3 (Print Statement): Design a test case to cover the print statement by
providing mock data for age and verifying that the age is printed correctly. This test case
ensures coverage of the common print statement executed in the function.

[Link] Tools Used for Branch Coverage

There are many tools used for branch coverages. Let's see some of the tools.

1. [Link]: An open-source tool designed for the Python programming language,

[Link] aids in analyzing code coverage for developed Python code. It provides
insights into which parts of the code are exercised by unit tests.

2. JCov: An open-source testing tool tailored for the Java programming language, JCov
facilitates testing and analysis of code coverage. It allows developers to gain visibility into
the branches covered by their unit tests in Java applications.

3. JaCoCo: Another open-source code coverage testing tool, JaCoCo, is widely used for both
Kotlin and Java programming environments. It provides detailed insights into code
coverage, including branch coverage, to ensure comprehensive testing.

4. CoCo: This testing tool is utilized to analyze code coverage for the C programming
language. Unlike some others, CoCo is not an open-source tool but serves the purpose of
assessing coverage in C code.

5. Coverlet: An open-source tool designed for the .NET framework, Coverlet enables the
analysis of various coverage metrics, including branch coverage. It is particularly useful
for assessing the thoroughness of unit tests in .NET applications.
[Link] Advantages of Using Branch Coverage

1. Efficiency: Branch coverage provides an efficient metric for assessing how thoroughly unit
tests have explored different decision paths within the code. It ensures that various
branches, including conditional and unconditional statements, are executed, contributing
to a more comprehensive test suite.

2. Knowledge Gaining: Writing test cases for branch coverage requires a deep
understanding of the code, promoting knowledge acquisition. This learning process
enhances developers' familiarity with the codebase and its decision logic.

3. Supports Deployment Activities: Branch coverage supports higher-level deployment

activities by ensuring that critical decision points in the code have been adequately
tested. This helps in delivering more reliable and robust software.

[Link] Disadvantages of Using Branch Coverage in Unit Testing

1. Requires Learning: Utilizing branch coverage in unit testing demands coding knowledge
to write effective test cases. This could pose a challenge, particularly for beginners or
individuals with limited programming experience.

2. Additional Mock Data Needed: In some cases, creating mock data becomes necessary to
execute test cases effectively. This may lead to the addition of dummy files or data in the
source code folder, potentially impacting the cleanliness of the codebase.

3. Uncovered Branches: Despite efforts, it may be challenging to cover all branches in the
code. Certain branches, especially those involving complex logic or exceptional scenarios,
might remain uncovered, limiting the overall effectiveness of branch coverage.
Continuous refinement of test cases is essential to address such challenges.

Note : Short Hint for white box test coverage – code coverage, condition coverage, branch
coverage
1. Code Coverage (Statement Coverage)
Definition:
Code coverage measures the percentage of executable statements in the code that have been
executed by the test cases.
Formula:
Code Coverage = (Number of lines of code executed)/(Total Number of lines of code in a system
component) * 100
Example:
if (a > 5)
b = b + 1;
c = c + 1;
 ● Test Case 1: a = 6
→ Executes both statements → 100% coverage
● Test Case 2: a = 4
→ Skips b = b + 1; → only 1 of 2 statements executed → 50% coverage
Statement Coverage ensures all code lines are executed at least once.

2. Branch Coverage (Decision Coverage)

Definition:
Branch Coverage ensures that each possible branch (true/false) of every decision point (like if,
else, switch) is executed at least once.
Formula:
Branch Coverage = ((Number of Executed Branches) ÷ (Total Number of Branches)) ✕ 100%
Example:
if (x > 0)
printf("Positive");
else
printf("Negative");
● Test Case 1: x = 5 → True branch executed
● Test Case 2: x = -3 → False branch executed
Both branches executed → 100% Branch Coverage
Note: It ensures all decisions take both true and false outcomes, but not necessarily all
combinations of conditions.

3. Condition Coverage
Definition:
Condition Coverage checks that each Boolean sub-expression in a decision has been evaluated
both True and False, at least once.
Condition Coverage (%) = (Number of executed conditions / Total number of conditions) * 100
Example:
if (A > 5 && B < 10)
printf("Valid");
To achieve Condition Coverage, you need:
Test Case A>5 B<10 Output
1 T T Valid
2 F T Not valid
3 T F Not valid
Each condition (A>5, B<10) is True and False at least once.
Condition Coverage is stronger than Branch Coverage because it tests each part of the condition
separately.
Comparison Summary
Coverage Type Focus Ensures Example
Code/Statement
Every executable statement Each line executed once Covers all lines
Coverage
Branch Coverage Decision outcomes True/False of each branch Covers all if/else
Each condition tested for
Condition Coverage Boolean expressions Covers each sub-condition
T/F

● Statement Coverage: Each line tested once

● Branch Coverage: Both True/False paths taken
● Condition Coverage: Each condition (like x>0) tested for True & False

5.6 EQUIVALENCE PARTITIONING METHOD

Equivalence Partitioning Method is also known as Equivalence class partitioning (ECP). It is

a software testing technique or black-box testing that divides input domain into classes of data,
and with the help of these classes of data, test cases can be derived. An ideal test case identifies
class of error that might require many arbitrary test cases to be executed before general error is
observed.

In equivalence partitioning, equivalence classes are evaluated for given input conditions.
Whenever any input is given, then type of input condition is checked, then for this input
conditions, Equivalence class represents or describes set of valid or invalid states.
5.6.1 Guidelines for Equivalence Partitioning:
● If the range condition is given as an input, then one valid and two invalid equivalence
classes are defined.
If input is a Range
→ Create 1 Valid class, 2 Invalid classes
Example: 1–10
o Valid: 1–10
o Invalid: <1
o Invalid: >10

● If a specific value is given as input, then one valid and two invalid equivalence classes are
defined.
If input requires a Specific Value
→ Create 1 Valid, 2 Invalid classes
Example: Value must be exactly 5
o Valid: 5
o Invalid: <5
o Invalid: >5

● If a member of set is given as an input, then one valid and one invalid equivalence class is
defined.
If input is from a Set / List
→ 1 Valid, 1 Invalid class
● Valid: Any member of the set
● Invalid: Any value not in the set

● If Boolean no. is given as an input condition, then one valid and one invalid equivalence
class is defined.
If input is Boolean (True/False)
→ 1 Valid, 1 Invalid class
● Valid: True or False
● Invalid: Any other input (e.g., “yes”, 1, null)
[Link]-1:
Let us consider an example of any college admission process. There is a college that gives
admissions to students based upon their percentage.

Consider percentage field that will accept percentage only between 50 to 90 %, more and even
less than not be accepted, and application will redirect user to an error page. If percentage
entered by user is less than 50 %or more than 90 %, that equivalence partitioning method will
show an invalid percentage. If percentage entered is between 50 to 90 %, then equivalence
partitioning method will show valid percentage.
5.6.3. Example 2:
Let us consider an example of an online shopping site. In this site, each of products has a specific
product ID and product name. We can search for product either by using name of product or by
product ID. Here, we consider search field that accepts only valid product ID or product name.
Let us consider a set of products with product IDs and users wants to search for Mobiles. Below
is a table of some products with their product Id.
Product Product ID
Mobiles 45
Laptops 54
Pen Drives 67
Keyboard 76
Headphones 34

If the product ID entered by user is invalid then application will redirect customer or user to error
page. If product ID entered by user is valid i.e. 45 for mobile, then equivalence partitioning
method will show a valid product ID.

[Link]-3:
Let us consider an example of software application. There is function of software application that
accepts only particular number of digits, not even greater or less than that particular number.

Consider an OTP number that contains only 6-digit number, greater and even less than six digits
will not be accepted, and the application will redirect customer or user to error page. If password
entered by user is less or more than six characters, that equivalence partitioning method will
show an invalid OTP. If password entered is exactly six characters, then equivalence partitioning
method will show valid OTP.
5.7 BOUNDARY VALUE ANALYSIS
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 testings.
5.7.1 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.
In simple terms boundary value Analysis is like testing the edge cases of our software where most
of the time it will get broke so it is important to do BVA before deploying the code. There are
many other test that are done if you wish to learn them all then you can join our complete
software testing course
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-
o Minimum value.
o Just above the minimum.
o Nominal Value.
o Just below Max value.
o Max value.

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

 Boundary Value Analysis (Age accepts 18 to 56)
Invalid Valid Invalid
(min-1) (min, min + 1, nominal, max - 1, max) (max + 1)
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 Testcases: When any value less than 18 and greater than 56 is entered.
● Enter the value- 17.
● Enter the value- 57.
5.7.2 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 Date.

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 Cases Month Day Year Output

1 6 15 1900 14 June 1900
2 6 15 1901 14 June 1901
3 6 15 1960 14 June 1960
4 6 15 1999 14 June 1999
5 6 15 2000 14 June 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 Case Month Day Year Output

6 6 1 1960 31 May 1960
7 6 2 1960 1 June 1960
 8 6 30 1960 29 June 1960
9 6 31 1960 Invalid day

Taking Month as Single Fault Assumption i.e. Month will be having values varying from 1 to 12
and others will have nominal values.

Test Case Month Day Year Output

10 1 15 1960 14 Jan 1960
11 2 15 1960 14 Feb 1960
12 11 15 1960 14 Nov 1960
13 12 15 1960 14 Dec 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.

5.7.3 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.
5.7.4 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.
5.7.5 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
1 Enter value 0 to 5 character Not accepted
2 Enter 6 to 10 character Accepted
3 Enter 11 to 14 character Not Accepted

5.7.6 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.

5.7.7 Boundary Value Analysis vs Equivalence Partitioning

Boundary Value Analysis (BVA) focuses on testing at the boundaries between partitions, while
Equivalence Partitioning (EP) divides input data into equivalent classes to reduce test cases. Both
methods aim to minimize test efforts while maximizing coverage.

Below are some of the differences between BVA and Equivalence Partitioning.

Boundary Value Analysis Equivalence Partitioning

Equivalence Partitioning examines
BVA considers the input data values
Uses input data values from the range of
from the defined boundaries.
equivalence class intervals.
In Equivalence partitioning, valid and
It considers min+1, min, min-1, nominal,
invalid ranges of equivalence classes
Testing Values max+1, max, and max-1 values as input
are taken for testing developed
test data values.
applications.
It helps in identifying bugs in-
Bug It identifies bugs at boundary values
between the partitioned equivalence
Identification only.
data class.
 Application It can be performed at any stage of
It is a part of stress and negative testing.
Areas software testing like unit testing.
Correctness of Equivalence
It is restricted to applications with close Partitioning is dependent on how
Usage Condition
boundary values. correctly the tester identifies
equivalence class.

5.8 USAGE OF STATE TABLES

State tables play a crucial role in various aspects of software engineering, primarily in the design,
specification, testing, and validation of software systems. Here are some specific ways state
tables are used:
1. Finite State Machines (FSMs)
State tables are fundamental for modeling finite state machines, which are widely used to
represent the behavior of systems that can be in one of a finite number of states at any given
time. FSMs are applicable in areas such as protocol handling, control systems, user interfaces,
and more.
● Example: In an elevator control system, states could include "idle," "moving up," "moving
down," "doors opening," and "doors closing." State tables would define transitions
triggered by events like button presses and limit switches.
2. Specification and Requirements Analysis
State tables are used to formally specify and analyze system requirements, especially those
involving complex sequences of states and transitions. They provide a visual and structured
representation that helps stakeholders understand and validate system behavior.
● Example: In a traffic light control system, state tables could specify states like "green
light," "yellow light," "red light," and transitions triggered by timers and vehicle sensors.
3. Design and Implementation
During the design phase, state tables aid software architects and developers in translating high-
level requirements into detailed design specifications. They guide the implementation of state
transitions and associated actions or behaviours within the software.
● Example: In a video game character AI, state tables might define states such as "idle,"
"patrolling," "attacking," and transitions based on player proximity and health conditions.
4. Testing and Validation
State tables are instrumental in generating test cases that thoroughly exercise all possible state
transitions and edge cases. They ensure comprehensive coverage of system behaviors and help
identify potential errors or anomalies.
● Example: Testing a thermostat control system would involve state tables specifying states
like "heating," "cooling," "standby," and transitions triggered by temperature thresholds
and user settings.
5. Documentation and Communication
State tables serve as valuable documentation artifacts that aid in communication among project
stakeholders. They provide a common understanding of system behavior, helping to align
development efforts and validate system correctness.
 ● Example: In a banking application, state tables could define states for "logged in,"
"viewing account details," "making a transaction," and transitions based on user actions
and security protocols.
6. Maintenance and Debugging
During software maintenance and debugging, state tables act as reference guides for
understanding and modifying system behavior. They facilitate pinpointing issues related to state
transitions or unexpected system behaviors.
● Example: Debugging an embedded system for a smart home device would involve
referring to state tables that outline states like "connected," "disconnected," "offline
mode," and transitions based on network status and user commands.

5.9 TESTING USE CASES

Testing Use Cases

Testing use cases involves verifying that the software correctly performs all the actions and
workflows described in the use case model. Each use case represents a specific interaction
between the user (actor) and the system to achieve a goal.
This type of testing ensures that the system behaves as expected for each scenario defined in
the requirements.

Purpose:
● To confirm that the implemented system meets functional requirements.
● To validate real user interactions with the system.
● To test both main and alternate paths of use cases.
Process:
1. Identify use cases from the Software Requirement Specification (SRS) or UML diagrams.
2. Develop test cases for each scenario and flow (main, alternate, and exceptional).
3. Execute these test cases and record actual outcomes.
4. Compare the results with expected behavior.
5. Document findings for analysis.
Example:
In an Online Shopping System, the use case includes viewing items, selecting products, adding
them to the cart, and making a purchase. The customer then proceeds to checkout, where
payment is made through services such as credit cards or PayPal. Alternate paths could include
“User not authenticated,” “Payment failed,” or “Item out of stock.”

[Link]
A Use Case defines how a user (actor) interacts with the system to achieve a particular goal.
Each use case describes a specific functionality or service that the system provides to its users.
In this Online Shopping System, use cases describe how different types of customers (new,
registered, or web customers) perform activities such as viewing items, registering, making
purchases, and checking out.
Purpose:
● To identify the functional behavior of the system.
● To make sure all user interactions are properly understood and tested.
2. Use Case Model
A Use Case Model shows the interaction between actors and the system using diagrams and
descriptions.
It includes all use cases, actors, and their relationships.
Actors:
1. Web Customer – The main actor who uses the online shopping website.
2. New Customer – A customer who needs to register before purchasing.
3. Registered Customer – A user who already has an account.
4. Authentication Service – Verifies the user’s identity before allowing access.
5. Identity Provider – Manages login and identity details.
6. Credit Payment Service – Handles credit/debit card payments.
7. PayPal – Processes payments through PayPal gateway.
System Boundary:
Subsystem – “Online Shopping”
Everything inside this boundary belongs to the system; actors outside the box interact
with it.
Use Cases (Inside the System):
1. View Items – Allows customers to browse available products.
2. Client Register – Lets new customers create an account.
3. Make Purchase – Handles the process of selecting and buying items.
4. Checkout – Confirms the order and processes the payment.
Relationships:
1. Include Relationship:
a. Make Purchase → includes → View Items and Checkout
(Because purchasing an item always involves viewing and checking out.)
2. Generalization Relationship:
a. New Customer and Registered Customer → both extend Web Customer.
3. Associations:
a. Lines between actors and use cases represent direct interactions.

3. Functional Requirements
Functional requirements define what the system should do based on the use cases.
From the diagram, the main functional requirements are:
1. The system shall allow new customers to register and create accounts.
2. The system shall allow registered customers to log in using authentication services.
3. The system shall allow users to view available items in the online store.
4. The system shall allow users to make purchases by adding items and checking out.
5. The system shall integrate with external payment services like Credit Payment and
PayPal.
6. The system shall validate payments and confirm orders upon successful transaction.

4. Parameters (for Testing Each Use Case)

● Parameter ● Description / Example
● Use Case Name ● e.g., Make Purchase
 ● Parameter ● Description / Example
● Actors ● Registered Customer, Authentication Service, Payment Gateway
● Preconditions ● Customer must be logged in and have items in the cart
● Input Data ● Item ID, quantity, payment details
● Main Flow ● 1. Select items → 2. Proceed to checkout → 3. Make payment
● Alternate Flow ● Payment fails → Show error message and rollback
● Expected Output ● Order confirmation message displayed; inventory updated
● Postconditions ● Order saved in database, payment confirmed
● Exceptions ● Network error, insufficient balance, session timeout

5. Example: Make Purchase Use Case

Actor: Registered Customer
● Goal: To successfully buy selected items online.
● Precondition: Customer logged in, items added to cart.
● Main Steps:
1. Customer views items
2. Adds desired products to cart
3. Chooses checkout
4. Selects payment option (Credit or PayPal)
5. System verifies and confirms payment
● Postcondition: Purchase completed; confirmation and receipt shown

6. Summary
● The Use Case Diagram provides a complete view of the system’s interactions.
● It helps in understanding, designing, and testing functional behavior.
● Each use case connects to functional requirements that specify what the system must
do.
● Parameters define how each use case can be tested step by step.

Advantages:
● Ensures user requirements are met accurately.
● Covers end-to-end system functionality.
● Helps detect missing workflows or logic errors early.

5.10 TRANSACTION BASED TESTING

Transaction-based testing in software engineering focuses on validating that a system correctly
processes transactions, which are sequences of operations or actions performed by the system.
This approach is particularly important for applications that handle financial transactions, order
processing, or any other processes where accuracy and integrity are crucial.
Here’s a breakdown of transaction-based testing:
1. Understanding Transactions
A transaction typically involves multiple steps or actions that should be treated as a single unit of
work. For instance:
● Financial Systems: A transaction could involve checking account balances, deducting
amounts, and updating account records.
● E-commerce Systems: An order transaction may include selecting items, processing
payment, and updating inventory.
2. Objectives of Transaction-Based Testing
● Correctness: Ensuring that transactions are processed accurately and completely.
● Consistency: Verifying that the system maintains data consistency before and after the
transaction.
● Integrity: Confirming that transactions maintain data integrity and adhere to business
rules.
● Performance: Testing the system’s ability to handle transactions efficiently under various
conditions.
● Recovery: Ensuring that the system can recover gracefully from transaction failures or
interruptions.
3. Key Elements of Transaction-Based Testing
1. Test Cases: Design test cases that cover different types of transactions, including normal,
boundary, and error scenarios.
o Normal Cases: Typical transactions that the system should handle correctly.
o Boundary Cases: Transactions at the edge of acceptable input ranges or
conditions.
o Error Cases: Invalid or incomplete transactions that should be properly handled
by the system.
2. Transaction Scenarios: Define scenarios that represent real-world use cases for
transactions.
o Successful Transactions: Ensure that transactions complete successfully and the
system behaves as expected.
o Failed Transactions: Simulate errors or failures and verify that the system handles
them correctly, such as rolling back changes.
3. Data Validation: Verify that data involved in transactions is processed and stored
correctly.
o Input Validation: Check that input data is correctly validated before processing.
o Output Validation: Ensure that the outputs of transactions match expected
results.
4. Transactional Integrity: Test that the system maintains data integrity and consistency
during and after transactions.
o Atomicity: Verify that transactions are indivisible; either all operations succeed,
or none do.
o Consistency: Check that the system remains in a consistent state before and after
a transaction.
o Isolation: Ensure that transactions are isolated from each other and do not
interfere with one another.
 o Durability: Confirm that completed transactions are permanent and not lost due
to system failures.
5. Performance Testing: Assess the performance of transactions under different load
conditions, including:
o Load Testing: Evaluate how the system handles a high volume of transactions.
o Stress Testing: Test the system’s behavior under extreme conditions or loads.
o Scalability Testing: Determine how well the system scales with increasing
transaction volumes.
6. Recovery Testing: Validate that the system can recover from transaction failures, such as:
o Rollback: Ensure that the system correctly rolls back incomplete transactions.
o Error Handling: Verify that appropriate error messages or recovery actions are
taken in case of transaction failures.
4. Tools and Techniques
● Automated Testing Tools: Use tools like Selenium, JMeter, or custom scripts to automate
transaction-based test cases.
● Database Testing Tools: Employ tools to verify data integrity and consistency in
databases.
● Mocking and Stubbing: Use mocking frameworks to simulate external systems or
dependencies involved in transactions.
5. Best Practices
● Comprehensive Coverage: Ensure that test cases cover a wide range of transaction
scenarios.
● Realistic Data: Use realistic data for testing to better simulate actual conditions.
● Documentation: Document test cases, expected results, and any anomalies for better
tracking and analysis.
Transaction-based testing is crucial for ensuring that systems perform reliably and accurately,
particularly in environments where transactions are critical to the application's functionality.

5.11 TESTING FOR NON-FUNCTIONAL REQUIREMENTS – VOLUME, PERFORMANCE AND

EFFICIENCY
Testing for non-functional requirements focuses on evaluating how well a system performs in
various operational contexts rather than its functionality. Non-functional requirements are
crucial for understanding the system's behavior under different conditions and ensuring it meets
quality attributes like volume handling, performance, and efficiency. Here’s how you can
approach testing for these aspects:
1. VOLUME TESTING
Objective: To ensure that the system can handle large volumes of data or transactions and
scale effectively.
Key Aspects:
● Data Volume: Test how the system manages and processes large amounts of data.
● Transaction Volume: Assess the system’s ability to handle high transaction loads or user
activity.
Approach:
 1. Define Test Scenarios: Create scenarios that simulate high volumes of data or
transactions. For example, if testing an e-commerce site, simulate thousands of
concurrent users placing orders.
2. Test Data Preparation: Generate large datasets to be used in testing. This might involve
creating bulk data or using data generation tools.
3. Execution: Run the test and monitor how the system behaves under load. This includes
checking for data integrity, response times, and system stability.
4. Analysis: Evaluate the system’s ability to handle the volume without performance
degradation or failure.
Tools: Apache JMeter, LoadRunner, Gatling.

2. PERFORMANCE TESTING
Objective: To measure how well the system performs in terms of response time, throughput,
and resource utilization under various conditions.
Key Aspects:
● Response Time: Time taken by the system to respond to a request.
● Throughput: Number of transactions or requests processed in a given time period.
● Concurrency: Number of simultaneous users or processes the system can handle.
● Resource Utilization: CPU, memory, disk, and network usage during operation.
Approach:
1. Identify Performance Metrics: Determine the performance metrics you need to
measure, such as response time, throughput, or latency.
2. Create Performance Test Cases: Design test cases that include typical and peak load
scenarios.
3. Execute Tests: Use performance testing tools to simulate different loads and measure
system performance.
4. Monitor and Measure: Monitor system performance metrics during the tests and
record the results.
5. Analyze Results: Compare the results against the performance requirements or
benchmarks to assess if the system meets the expected performance criteria.
Tools: Apache JMeter, LoadRunner, NeoLoad, Performance Center.

3. EFFICIENCY TESTING
Objective: To evaluate how effectively the system uses resources, including its capacity to
perform tasks with minimal overhead.
Key Aspects:
● Resource Usage: Assess how efficiently the system uses CPU, memory, and other
resources.
● Response Time vs. Resource Utilization: Evaluate how changes in resource usage affect
response time and overall performance.
● Scalability: Test how efficiently the system scales with increased load or data volume.
Approach:
1. Define Efficiency Metrics: Identify key metrics for efficiency, such as resource usage per
transaction or operation.
 2. Set Baselines: Establish performance baselines for resource usage under normal
operating conditions.
3. Conduct Tests: Run tests to observe how efficiently the system performs tasks under
varying loads.
4. Optimize: Identify any inefficiencies or bottlenecks and make recommendations for
optimization based on test results.
5. Validate Improvements: Re-test the system after optimization to ensure that efficiency
improvements are effective.
Tools: Profilers (e.g., VisualVM, YourKit), APM tools (e.g., New Relic, Dynatrace).

BEST PRACTICES FOR NON-FUNCTIONAL TESTING

1. Define Clear Requirements: Clearly define non-functional requirements and acceptance
criteria before testing.
2. Use Realistic Scenarios: Ensure test scenarios reflect real-world usage patterns and
conditions.
3. Automate Where Possible: Automate tests for scalability and repeatability, particularly
for performance and volume testing.
4. Monitor Continuously: Continuously monitor system performance during testing to
capture real-time data.
5. Analyze and Act: Regularly analyze test results and take action based on findings to
improve system performance and efficiency.
Testing non-functional requirements is essential to ensure that a system not only works
correctly but also performs optimally under expected and unexpected conditions. This
approach helps in delivering a robust, reliable, and efficient system that meets user
expectations and operational needs.

5.12 INSPECTION OF CONCEPTS

Inspection in software engineering is a systematic and formal process used to review and
evaluate software artifacts—such as code, design documents, and requirements—to identify
defects, ensure quality, and improve development practices. Unlike other review methods,
inspections are typically structured and follow a predefined process, often involving multiple
roles and steps. Here are the key concepts related to inspection in software engineering:
1. Purpose of Inspection
● Defect Detection: Identify defects or issues early in the development process before
they propagate to later stages.
● Quality Assurance: Ensure that software artifacts meet specified quality standards and
adhere to requirements.
● Process Improvement: Gather data on recurring issues to improve development
processes and practices.
2. Types of Inspections
1. Code Inspection:
 o Focuses on reviewing the source code to find defects, ensure adherence to
coding standards, and identify opportunities for refactoring or optimization.
2. Design Inspection:
o Evaluates design documents, including architectural and detailed design, to
verify that they meet requirements and are feasible.
3. Requirements Inspection:
o Reviews requirements documents to ensure they are clear, complete, and
unambiguous. It involves stakeholders to validate that the requirements align
with user needs and business objectives.
4. Document Inspection:
o Includes reviewing various types of documentation such as user manuals, test
plans, and technical specifications to ensure accuracy and completeness.
3. Inspection Process
1. Planning:
o Define the scope, objectives, and criteria for the inspection.
o Select the artifacts to be inspected and assemble the inspection team.
o Schedule the inspection meeting and allocate time for preparation.
2. Preparation:
o Reviewers study the artifact to be inspected before the meeting.
o Prepare questions and identify potential issues or concerns.
3. Inspection Meeting:
o A structured meeting where reviewers discuss the artifact, identify defects, and
provide feedback.
o The artifact's author presents it and responds to questions from reviewers.
4. Issue Recording:
o Document identified defects, issues, and suggestions for improvement.
o Assign action items for defect resolution and track their progress.
5. Rework and Follow-Up:
o The author revises the artifact based on feedback and resolves identified issues.
o Conduct follow-up inspections if necessary to ensure that all issues are
addressed.
6. Closure:
o Finalize the inspection process once all issues are resolved and verify that the
artifact meets the required standards.
4. Roles in Inspection
● Author: The creator of the artifact being inspected. They present the artifact and
answer questions during the inspection process.
● Reviewer: Team members who examine the artifact, identify defects, and provide
feedback. Reviewers typically have relevant expertise.
● Moderator: Facilitates the inspection meeting, ensuring that it remains focused and
productive. They manage the process and ensure adherence to the inspection protocol.
● Recorder: Documents the issues found, actions required, and decisions made during the
inspection.
5. Benefits of Inspection
 ● Early Defect Detection: Helps identify and address defects early in the development
cycle, reducing the cost and effort of fixing them later.
● Improved Quality: Ensures that software artifacts meet quality standards and
requirements.
● Knowledge Sharing: Encourages collaboration and learning among team members
through discussions and feedback.
● Process Improvement: Provides insights into common issues and helps in refining
development processes.
6. Inspection Techniques
● Checklist-Based Inspections: Use predefined checklists to guide the inspection and
ensure that all important aspects are reviewed.
● Ad-Hoc Inspections: Informal reviews that are less structured, often used for quick
evaluations or initial assessments.
● Formal Inspections: Follow a structured process with clearly defined roles, steps, and
documentation, often used for critical artifacts.
7. Best Practices
● Set Clear Objectives: Clearly define the goals of the inspection to keep the process
focused and productive.
● Prepare Thoroughly: Ensure that reviewers and authors are well-prepared to maximize
the effectiveness of the inspection.
● Foster a Constructive Environment: Create a positive atmosphere where feedback is
constructive and aimed at improvement, not blame.
● Follow Up: Ensure that identified issues are addressed and that necessary rework is
completed. Verify that all action items are followed up on and resolved.
8. Challenges and Solutions
● Challenge: Resistance from team members due to perceived extra effort or criticism.
o Solution: Emphasize the value of inspections in improving quality and reducing
future work. Foster a culture of continuous improvement.
● Challenge: Ensuring comprehensive coverage of all aspects of the artifact.
o Solution: Use detailed checklists and involve diverse reviewers to cover different
perspectives.
● Challenge: Managing the inspection process effectively to avoid delays.
o Solution: Adhere to a well-defined process and schedule, and ensure that the
moderator manages time and discussions efficiently.
By adhering to these concepts and best practices, inspections can significantly contribute to the
development of high-quality software and help teams maintain effective and efficient
development processes.

5.13 UNIT TESTING, INTEGRATION TESTING, SYSTEM TESTING AND ACCEPTANCE TESTING.

Software Testing is an important part of the Software Development Life Cycle which is help to
verify the product is working as expected or not. In SDLC, we used different levels of testing to
find bugs and errors. Here we are learning those Levels of Testing in detail.
Table of Content
● What Are the Levels of Software Testing?
● 1. Unit Testing
● 2. Integration Testing
● 3. System testing
● 4. Acceptance Testing
What Are the Levels of Software Testing?
Software Testing is essential to verify an application is working properly or not. To achieve this,
testing can be done through various stages of development from each component to all
system. Those "stages", called Levels of Testing, help to make sure all components of system
are working properly.
Learn more: Software Development Life Cycle
Likely Levels of Testing divided into four main levels, which are as follows:

Levels of Testing

1. Unit Testing
Unit Testing is the first step in testing your software. It focuses on checking individual
components or functions of the application to make sure they work correctly on their own. The
goal here is to catch any issues early before those small components are integrated with the rest
of the system.
Unit tests help developers spot bugs early in the development process, making it easier and
quicker to fix them. It's the first layer of defense to verify that each part of the application
performs as expected.
Mainly features are:
● Testing individual functions or components.
● Ensuring correct behavior at the smallest level.
● Catching errors early.
2. Integration Testing
After unit testing, Integration Testing takes over. This level checks how different modules or
components of the software work together. It's important because even if individual parts work
perfectly, they might face issues when interacting with one another.
Integration testing ensures that data flows correctly between modules and that they
communicate seamlessly. It helps catch problems that might arise when different parts of the
system interact.
3. System testing
System Testing is when you test the software as a system. This stage checks whether the entire
system functions as expected in a real-world environment. It includes both functional and non-
functional tests to ensure that the software meets customer needs.
● Full end-to-end testing of the software.
● Verifying both functional and non-functional requirements.
● Testing the software's behavior in real-world conditions.
4. Acceptance Testing
Acceptance Testing, also known as User Acceptance Testing (UAT), is the final test before
releasing the software to the end-users. In this phase, the customer or end-users verify if the
software meets their needs and expectations.
UAT is crucial because it verify the software is ready for production. It’s the last chance to catch
any overlooked issues before deployment. If the software passes this stage, the customer gives
the green light for release.
● Validating the software against business requirements.
● Ensuring the software meets customer expectations.
● Getting final approval from the customer.
Testing Principles
While performing the software testing, following Testing Principles must be applied by every
software engineer:
1. The requirements of customers should be traceable and identified by all different tests.
2. Planning of tests that how tests will be conducted should be done long before the
beginning of the test.
3. The Pareto principle can be applied to software testing- 80% of all errors identified during
testing will likely be traceable to 20% of all program modules.
4. Testing should begin “in the small” and progress toward testing “in the large”.
5. Exhaustive testing which simply means to test all the possible combinations of data is not
possible.
6. Testing conducted should be most effective and for this purpose, an independent third
party is required.

5.13.1 UNIT TESTING - SOFTWARE TESTING

Unit testing is the process of testing the smallest parts of your code, like it is a method in which
we verify the code's correctness by running one by one. It's a key part of software development
that improves code quality by testing each unit in isolation.
You write unit tests for these code units and run them automatically every time you make
changes. If a test fails, it helps you quickly find and fix the issue. Unit testing promotes modular
code, ensures better test coverage, and saves time by allowing developers to focus more on
coding than manual testing.
What is a Unit Test?
A unit test is a small piece of code that checks if a specific function or method in is an
application works correctly. It will work as the function inputs and verifying the outputs. These
tests check that the code work as expected based on the logic the developer intended.

In these multiple tests are written for a single function to cover different possible scenarios and
these are called test cases. While it is ideal to cover all expected behaviors, it is not always
necessary to test every scenario.
Unit tests should run one by one, it means that they do not depend on other system parts like
databases or networks. Instead, data stubs can be used to simulate these dependencies.
Writing unit tests is easiest for simple, self-contained code blocks.
Types of Unit Testing
Unit testing can be performed manually or automatically:
1. Manual unit testing
Manual Testing is like checking each part of a project by hand, without using any special tools.
People, like developers, do each step of the testing themselves. But manual unit testing isn't
used much because there are better ways to do it and it has some problems:
● It costs more because workers have to be paid for the time they spend testing,
especially if they're not permanent staff.
● It takes a lot of time because tests have to be done every time the code changes.
● It is hard to find and fix problems because it is tricky to test each part separately.
● Developers often do manual testing themselves to see if their code works correctly.
Types of Unit Testing
2. Automated unit testing
Automation Unit Testing is a way of checking if software works correctly without needing lots of
human effort. We use special tools made by people to run these tests automatically. These are
part of the process of building the software. Here's how it works:
● Developers write a small piece of code to test a function in the software. This code is
like a little experiment to see if everything works as it should.
● Before the software is finished and sent out to users, these test codes are taken out.
They're only there to make sure everything is working properly during development.
● Automated testing can help us check each part of the software on its own. This helps us
find out if one part depends too much on another. It's like putting each piece of a puzzle
under a magnifying glass to see if they fit together just right.
● We usually use special tools or frameworks to do this testing automatically. These tools
can tell us if any of our code doesn't pass the tests we set up.
 ● The tests we write should be really small and focus on one specific thing at a time. They
should also run on the computer's memory and not need internet connection.
So, automated unit testing is like having a helper that checks our work as we build software,
making sure everything is in its right place and works as expected.
Workflow of Unit Testing
The unit testing workflow includes the following step-by-step process:
Workflow of Unit Testing

Unit Testing Techniques

There are 3 types of Unit Testing Techniques. They are follows:
1. Black Box Testing: This testing technique is used in covering the unit tests for input, user
interface, and output parts.
2. White Box Testing: This technique is used in testing the functional behavior of the system
by giving the input and checking the functionality output including the internal design
structure and code of the modules.
3. Gray Box Testing: This technique is used in executing the relevant test cases, test
methods, and test functions, and analyzing the code performance for the modules.
Unit Testing Tools
Choosing the correct unit testing tool is important for the following reasons:
● Ensures that every system component is benefitted from achieving better product
quality.
● The debugging process is simplified.
● Code Refactoring and debugging of the code becomes simpler.
● If bugs are present, they would be defined earlier in the SDLC process.
● Bug fixing costs would be reduced significantly
Following are some of the unit testing tools:
● LambdaTest: A cloud-based platform for cross-browser testing, supporting unit tests in
various frameworks.
● JUnit: A widely-used Java testing framework for creating and running unit tests.
● NUnit: A .NET framework for unit testing C# applications.
● TestNG: An advanced Java testing framework with features like parallel testing.
● PHPUnit: A PHP testing framework for unit and integration tests.
● Mockito: A Java mocking framework for simulating dependencies.
● Cantata: A tool for unit and integration testing in C/C++.
● Karma: A JavaScript test runner for browser-based testing.
 ● Mocha: A flexible JavaScript testing framework for [Link] and browsers.
● TypeMock: A .NET mocking framework for isolating dependencies.

5.13.2 INTEGRATION TESTING

Integration Testing is a Software Testing Technique that focuses on verifying the interactions and
data exchange between different components or modules of a Software Application. The goal
of Integration Testing is to identify any problems or bugs that arise when different components
are combined and interact with each other.
● It mainly tests interface between two software units or modules. It focuses on
determining the correctness of the interface. Once all the modules have been unit-tested,
integration testing is performed.
● Integration testing can be done by picking module by module. This can be done so that
there is a proper sequence to be followed.
● Exposing the defects is the major focus of the integration testing and the time of
interaction between the integrated units.
Integration Testing

Why is Integration Testing Important?

Integration testing is important because it verifies that individual software modules or
components work together correctly as a whole system. This ensures that the integrated
software functions as intended and helps identify any compatibility or communication issues
between different parts of the system. By detecting and resolving integration problems early,
integration testing contributes to the overall reliability, performance, and quality of the software
product.
How to Write Integration Tests?
Designing integration test cases is a key part of ensuring that the different components of your
software work well together. Here's a simplified approach to designing these tests:
● Identify the components to be tested: Start by pinpointing which parts of your software
need to be tested together. These are usually modules that interact or depend on each
other.
 ● Determine the test objectives: Define what you want to achieve with the test. Are you
testing if data flows correctly between modules? Or perhaps checking if the system
behaves as expected when components interact?
● Define the test data: Decide what data you’ll use to test the integration. Make sure the
data represents real-world scenarios so that your tests are relevant and meaningful.
● Design the test cases: Plan out the specific steps for each test. Think about what actions
the test will take and what results you expect.
● Develop test scripts: Write the code that will automate your tests. If your tests are
manual, ensure the steps are clearly documented and easy to follow.
● Set up the testing environment: Make sure the environment where the tests will run
mimics the real-world setup as closely as possible. This will give you more accurate results.
● Execute the tests: Run your tests, paying close attention to how the components interact
and whether they perform as expected.
● Evaluate the results: Finally, review the test outcomes. Did the components work as
intended? Were there any errors or unexpected behaviors?
Types of Integration Testing
There are four main strategies for executing integration testing: big-bang, top-down, bottom-up,
and sandwich (or hybrid) testing. Each of these methods comes with its own set of advantages
and challenges, so it's important to choose the right one based on the specific needs of your
project. Those approaches are the following:

Integration Test Approaches

1. Big-Bang Integration Testing
It is the simplest integration testing approach, where all the modules are combined and the
functionality is verified after the completion of individual module testing. In simple words, all the
modules of the system are simply put together and tested. This approach is practicable only for
very small systems. If an error is found during the integration testing, it is very difficult to localize
the error as the error may potentially belong to any of the modules being integrated.
● In debugging errors reported during Big Bang integration testing is very expensive to fix.
● Big-bang integration testing is a software testing approach in which all components or
modules of a software application are combined and tested at once.
 ● This approach is typically used when the software components have a low degree of
interdependence or when there are constraints in the development environment that
prevent testing individual components.
● The goal of big-bang integration testing is to verify the overall functionality of the system
and to identify any integration problems that arise when the components are combined.
● While big-bang integration testing can be useful in some situations, it can also be a high-
risk approach, as the complexity of the system and the number of interactions between
components can make it difficult to identify and diagnose problems.
Advantages of Big-Bang Integration Testing
● It is convenient for small systems.
● Simple and straightforward approach.
● Can be completed quickly.
● Does not require a lot of planning or coordination.
● May be suitable for small systems or projects with a low degree of interdependence
between components.
Disadvantages of Big-Bang Integration Testing
● There will be quite a lot of delay because you would have to wait for all the modules to
be integrated.
● High-risk critical modules are not isolated and tested on priority since all modules are
tested at once.
● Not Good for long projects.
● High risk of integration problems that are difficult to identify and diagnose.
● This can result in long and complex debugging and troubleshooting efforts.
● This can lead to system downtime and increased development costs.
● May not provide enough visibility into the interactions and data exchange between
components.
● This can result in a lack of confidence in the system’s stability and reliability.
● This can lead to decreased efficiency and productivity.
● This may result in a lack of confidence in the development team.
● This can lead to system failure and decreased user satisfaction.
2. Bottom-Up Integration Testing
In bottom-up testing, each module at lower levels are tested with higher modules until all
modules are tested. The primary purpose of this integration testing is that each subsystem tests
the interfaces among various modules making up the subsystem. This integration testing uses
test drivers to drive and pass appropriate data to the lower-level modules.
Advantages of Bottom-Up Integration Testing
● In bottom-up testing, no stubs are required.
● A principal advantage of this integration testing is that several disjoint subsystems can be
tested simultaneously.
● It is easy to create the test conditions.
● Best for applications that uses bottom-up design approach.
● It is Easy to observe the test results.
Disadvantages of Bottom-Up Integration Testing
● Driver modules must be produced.
 ● In this testing, the complexity that occurs when the system is made up of a large number
of small subsystems.
● As Far modules have been created, there is no working model can be represented.
3. Top-Down Integration Testing
Top-down integration testing technique is used in order to simulate the behaviour of the lower-
level modules that are not yet integrated. In this integration testing, testing takes place from top
to bottom. First, high-level modules are tested and then low-level modules and finally integrating
the low-level modules to a high level to ensure the system is working as intended.
Advantages of Top-Down Integration Testing
● Separately debugged module.
● Few or no drivers needed.
● It is more stable and accurate at the aggregate level.
● Easier isolation of interface errors.
● In this, design defects can be found in the early stages.
Disadvantages of Top-Down Integration Testing
● Needs many Stubs.
● Modules at lower level are tested inadequately.
● It is difficult to observe the test output.
● It is difficult to stub design.

4. Mixed Integration Testing

A mixed integration testing is also called sandwiched integration testing. A mixed integration
testing follows a combination of top down and bottom-up testing approaches. In top-down
approach, testing can start only after the top-level module have been coded and unit tested. In
bottom-up approach, testing can start only after the bottom level modules are ready. This
sandwich or mixed approach overcomes this shortcoming of the top-down and bottom-up
approaches. It is also called the hybrid integration testing. also, stubs and drivers are used in
mixed integration testing.
Advantages of Mixed Integration Testing
● Mixed approach is useful for very large projects having several sub projects.
● This Sandwich approach overcomes this shortcoming of the top-down and bottom-up
approaches.
● Parallel test can be performed in top and bottom layer tests.
Disadvantages of Mixed Integration Testing
● For mixed integration testing, it requires very high cost because one part has a Top-down
approach while another part has a bottom-up approach.
● This integration testing cannot be used for smaller systems with huge interdependence
between different modules.
Applications of Integration Testing
Integration testing is all about making sure that different parts of a software application work
well together. While unit testing checks individual components, integration testing focuses on
how those components interact with each other. Here are the few applications of Integration
Testing:
 1. Identify the components: Identify the individual components of your application that
need to be integrated. This could include the frontend, backend, database, and any third-
party services.
2. Create a test plan: Develop a test plan that outlines the scenarios and test cases that need
to be executed to validate the integration points between the different components. This
could include testing data flow, communication protocols, and error handling.
3. Set up test environment: Set up a test environment that mirrors the production
environment as closely as possible. This will help ensure that the results of your
integration tests are accurate and reliable.
4. Execute the tests: Execute the tests outlined in your test plan, starting with the most
critical and complex scenarios. Be sure to log any defects or issues that you encounter
during testing.
5. Analyze the results: Analyze the results of your integration tests to identify any defects
or issues that need to be addressed. This may involve working with developers to fix bugs
or make changes to the application architecture.
6. Repeat testing: Once defects have been fixed, repeat the integration testing process to
ensure that the changes have been successful and that the application still works as
expected.

Difference between Manual Testing and Automated Testing

Here is the Manual Testing vs Automated Testing difference in detailed manner:

Parameters Manual Testing Automation Testing

In manual testing, the test In automated testing, the test
Definition cases are executed by the cases are executed by the
human tester. software tools.
Manual testing is time- Automation testing is faster than
Processing Time
consuming. manual testing.
Automation testing takes up
Manual testing takes up
Resources requirement automation tools and trained
human resources.
employees.
Exploratory testing is Exploratory testing is not possible
Exploratory testing
possible in manual testing. in automation testing.
Automation testing uses
Manual testing doesn’t use
Framework requirement frameworks like Data Drive,
frameworks.
Keyword, etc.
Manual testing is not reliable Automated testing is more
Reliability due to the possibility of reliable due to the use of
manual errors. automated tools and scripts.
 In manual testing, In automated testing, investment
Investment investment is required for is required for tools and
human resources. automated engineers.
In manual testing, the test In automated testing, the test
results are recorded in an results are readily available to all
Test results availability
excel sheet so they are not the stakeholders in the dashboard
readily available. of the automated tool.

5.13.3 SYSTEM TESTING

System Testing is a type of software testing that is performed on a completely integrated system
to evaluate the compliance of the system with the corresponding requirements. In system
testing, integration testing passed components are taken as input.
● The goal of integration testing is to detect any irregularity between the units that are
integrated. System testing detects defects within both the integrated units and the whole
system. The result of system testing is the observed behavior of a component or a system
when it is tested.
● System Testing is carried out on the whole system in the context of either system
requirement specifications or functional requirement specifications or the context of
both. System testing tests the design and behavior of the system and also the
expectations of the customer.
● It is performed to test the system beyond the bounds mentioned in the software
requirements specification (SRS). System Testing is performed by a testing team that is
independent of the development team and helps to test the quality of the system
impartial.
● It has both functional and non-functional testing. System Testing is performed after the
integration testing and before the acceptance testing.

System Testing
System Testing Process
System Testing is performed in the following steps:
● Test Environment Setup: Create testing environment for the better-quality testing.
● Create Test Case: Generate test case for the testing process.
 ● Create Test Data: Generate the data that is to be tested.
● Execute Test Case: After the generation of the test case and the test data, test cases are
executed.
● Defect Reporting: Defects in the system are detected.
● Regression Testing: It is carried out to test the side effects of the testing process.
● Log Defects: Defects are fixed in this step.
● Retest: If the test is not successful then again test is performed.

System Testing Process

Types of System Testing

Here are the Types of System Testing are follows:
Types of testing
 ● Functional Testing: This checks if the system’s features work as expected and meet the
defined requirements.
● Performance Testing: This tests how the system performs under different conditions,
like high traffic or heavy use, to ensure it can handle the expected load.
● Security Testing: This ensures the system’s security measures protect sensitive data
from unauthorized access or attacks.
● Compatibility Testing: This makes sure the system works well across different
hardware, software, and network environments.
● Usability Testing: This evaluates how easy and user-friendly the system is, making sure
it provides a good experience for users.
● Regression Testing: This ensures that any new code or features don’t break or
negatively affect the system’s existing functionality.
● Acceptance Testing: This tests the system at a high level to make sure it meets customer
expectations and requirements before release.
Tools used for System Testing
Here are the Tools used for System Testing are follows:
1. JMeter
2. Gallen Framework
3. HP Quality Center/ALM
4. IBM Rational Quality Manager
5. Microsoft Test Manager
6. Selenium
7. Appium
8. LoadRunner
9. Gatling
10. JMeter
11. Apache JServ
12. SoapUI
Note: The choice of tool depends on various factors like the technology used, the size of the
project, the budget, and the testing requirements.
Advantages of System Testing
Here are the Advantages of System Testing are follows:
● In System Testing The testers do not require more knowledge of programming to carry
out this testing.
● It will test the entire product or software so that we will easily detect the errors or
defects which cannot be identified during the unit testing and integration testing.
● The testing environment is similar to that of the real time production or business
environment.
● It checks the entire functionality of the system with different test scripts and also it
covers the technical and business requirements of clients.
● After this testing, the product will almost cover all the possible bugs or errors and hence
the development team will confidently go ahead with acceptance testing
● Verifies the overall functionality of the system.
● Detects and identifies system-level problems early in the development cycle.
 ● Helps to validate the requirements and ensure the system meets the user needs.
● Improves system reliability and quality.
● Facilitates collaboration and communication between development and testing teams.
● Enhances the overall performance of the system.
● Increases user confidence and reduces risks.
● Facilitates early detection and resolution of bugs and defects.
● Supports the identification of system-level dependencies and inter-module interactions.
● Improves the system’s maintainability and scalability.
Disadvantages of System Testing
Here are the Disadvantages of System Testing are follows:
● System Testing is time consuming process than another testing techniques since it
checks the entire product or software.
● The cost for the testing will be high since it covers the testing of entire software.
● It needs good debugging tool otherwise the hidden errors will not be found.
● Can be time-consuming and expensive.
● Requires adequate resources and infrastructure.
● Can be complex and challenging, especially for large and complex systems.
● Dependent on the quality of requirements and design documents.
● Limited visibility into the internal workings of the system.
● Can be impacted by external factors like hardware and network configurations.
● Requires proper planning, coordination, and execution.
● Can be impacted by changes made during development.
● Requires specialized skills and expertise.
● May require multiple test cycles to achieve desired results.
Best Practices for System Testing
To make system testing effective, follow these best practices:
1. Clear Test Plan and Requirements: Make sure you have a well-defined test plan and
clear requirements. This ensures all parts of the system are covered and tested
correctly.
2. Test Early and Often: Start testing as soon as possible in the development process and
continue testing regularly. Finding and fixing issues early helps save time and money.
3. Use Automation for Repetitive Tests: Automate tests that you run repeatedly, like
regression or performance tests. This saves time and allows you to focus on more
complex testing.
4. Create Realistic Test Scenarios: Design test cases based on how users will actually use
the system. This includes testing for edge cases, unusual inputs, and potential system
failures.
5. Collaborate with Developers: Work closely with developers throughout the testing
process. They can help identify problems faster and provide insights into how the
system functions.

5.13.4 ACCEPTANCE TESTING

Acceptance Testing is a formal testing according to user needs, requirements, and business
processes conducted to determine whether a system satisfies the acceptance criteria or not
and to enable the users, customers, or other authorized entities to determine whether to
accept the system or not.

Acceptance Testing is the last phase of software testing performed after System Testing and
before making the system available for actual use.

Prerequisite - Software Testing | Basics, Types of Software Testing

Flow of Acceptance Testing

Types of Acceptance Testing

Here are the Types of Acceptance Testing
1. User Acceptance Testing (UAT)
2. Business Acceptance Testing (BAT)
3. Contract Acceptance Testing (CAT)
4. Regulations Acceptance Testing (RAT)
5. Operational Acceptance Testing (OAT)
6. Alpha Testing
7. Beta Testing
 Types of Acceptance Testing

1. User Acceptance Testing (UAT)

● User acceptance testing is used to determine whether the product is working for the
user correctly.
● Specific requirements which are quite often used by the customers are primarily picked
for testing purposes. This is also termed as End-User Testing.
2. Business Acceptance Testing (BAT)
● BAT is used to determine whether the product meets the business goals and purposes
or not.
● BAT mainly focuses on business profits which are quite challenging due to the changing
market conditions and new technologies, so the current implementation may have to
being changed which results in extra budgets.
3. Contract Acceptance Testing (CAT)
● CAT is a contract that specifies that once the product goes live, within a predetermined
period, the acceptance test must be performed, and it should pass all the acceptance
use cases.
● Here is a contract termed a Service Level Agreement (SLA), which includes the terms
where the payment will be made only if the Product services are in-line with all the
requirements, which means the contract is fulfilled.
● Sometimes, this contract happens before the product goes live.
● There should be a well-defined contract in terms of the period of testing, areas of
testing, conditions on issues encountered at later stages, payments, etc.
4. Regulations Acceptance Testing (RAT)
● RAT is used to determine whether the product violates the rules and regulations that
are defined by the government of the country where it is being released.
 ● This may be unintentional but will impact negatively on the business. Generally, the
product or application that is to be released in the market, has to go under RAT, as
different countries or regions have different rules and regulations defined by its
governing bodies.
● If any rules and regulations are violated for any country then that country or the specific
region then the product will not be released in that country or region.
● If the product is released even though there is a violation then only the vendors of the
product will be directly responsible.
5. Operational Acceptance Testing (OAT)
● OAT is used to determine the operational readiness of the product and is non-functional
testing.
● It mainly includes testing of recovery, compatibility, maintainability, reliability, etc. OAT
assures the stability of the product before it is released to production.
6. Alpha Testing
● Alpha testing is used to determine the product in the development testing environment
by a specialized testers team usually called alpha testers.
7. Beta Testing
● Beta testing is used to assess the product by exposing it to the real end-users, typically
called beta testers in their environment.
● Feedback is collected from the users and the defects are fixed. Also, this helps in
enhancing the product to give a rich user experience.
Use of Acceptance Testing
1. To find the defects missed during the functional testing phase.
2. How well the product is developed.
3. A product is what actually the customers need.
4. Feedback help in improving the product performance and user experience.
5. Minimize or eliminate the issues arising from the production.
Advantages of Acceptance Testing
1. This testing helps the project team to know the further requirements from the users
directly as it involves the users for testing.
2. Automated test execution.
3. It brings confidence and satisfaction to the clients as they are directly involved in the
testing process.
4. It is easier for the user to describe their requirement.
5. It covers only the Black-Box testing process and hence the entire functionality of the
product will be tested.
Disadvantages of Acceptance Testing
1. Users should have basic knowledge about the product or application.
2. Sometimes, users don't want to participate in the testing process.
3. The feedback for the testing takes a long time as it involves many users and the opinions
may differ from one user to another user.
4. Development team is not participated in this testing process.