What is Software Testing in Software

Engineering?
Software engineering is the complex procedure of planning, creating and
managing computer programs or applications. Testing is essential in this
complex setting. It is a crucial stage that guarantees the software's
dependability, usefulness and quality.

Introduction to Testing in Software Engineering

In software engineering, testing refers to evaluating a system or application to
identify and rectify any discrepancies between expected and actual results. Its
primary objective is to ensure that the software functions as intended, meeting
the specified requirements and providing a seamless user experience.

Why is Testing Important?

1. Bug Detection: Testing helps identify and fix defects, or "bugs," in the
software. These bugs can range from minor inconveniences to critical errors
that can cause system failure.
2. Ensures Reliability: It provides confidence in the software's reliability,
stability, and performance under various conditions.
3. Confirms Compliance: Testing verifies if the software adheres to the specified
requirements, ensuring that it meets the needs of its intended users.
4. Enhances User Experience: Thorough testing leads to a more polished, user-
friendly product, which can significantly improve the end-user experience.
5. Saves Time and Money: Identifying and rectifying issues during the testing
phase is more cost-effective and efficient than addressing them after software
deployment.
6. Improves Maintenance: A well-tested software is easier to maintain and
update, providing a stable foundation for future development.

Types of Software Testing

Software testing encompasses a variety of techniques, each designed to
address specific aspects of a system's functionality. Here are some of the most
common types:

1. Unit Testing: It involves testing individual units or components of the software

in isolation to ensure they perform as expected.
2. Integration Testing: This assesses the interactions between different units or
components of the software to ensure they work together seamlessly.
3. System Testing: This evaluates the software, verifying that it meets all
specified requirements and functions as intended.
 4. Acceptance Testing: Testing the software with the end-users or stakeholders
to ensure it meets their expectations and requirements.
5. Regression Testing: This is performed after changes or updates to the
software to ensure that existing functionalities remain unaffected.
6. Performance Testing: It assesses how the software performs under different
conditions, such as high user loads or limited resources.
7. Security Testing: This evaluates the software's vulnerability to security
threats and ensures it can withstand attacks.
8. Usability Testing: It focuses on the user interface and overall user experience
to ensure the software is intuitive and easy to navigate.
9. Compatibility Testing: This testing ensures the software functions correctly
across different operating systems, browsers, and devices. It is crucial for
reaching a broad user base.
10.Load Testing: Load testing involves subjecting the software to a simulated
workload to evaluate its performance under high user traffic. This helps identify
any performance bottlenecks.
11.Stress Testing: Unlike load testing, stress testing aims to push the software
beyond its specified limits to assess how it handles extreme conditions. This
helps determine its breaking point.
12.Alpha and Beta Testing: Alpha testing is conducted internally by the
development team to identify major issues before releasing the software to a
select group of external users, known as beta testers. Beta testing provides
valuable feedback from real-world users.
13.Exploratory Testing: This testing relies on testers' intuition, creativity, and
domain knowledge to explore the software, uncovering unexpected behaviours
or issues that predefined test cases may not cover.

The Testing Process

1. Planning: This phase involves defining the scope, objectives, and resources
required for testing. Test plans and strategies are developed during this stage.
2. Design: Test cases are designed based on the requirements and specifications
of the software. These cases outline the steps to be taken and expected
outcomes.
3. Execution: The designed test cases are executed, and the actual results are
compared with the expected results.
4. Defect Reporting: Any discrepancies or defects identified during testing are
documented, including detailed information on reproducing them.
5. Retesting: After defects are fixed, the affected areas are retested to ensure
the issues are resolved.
6. Regression Testing: This step ensures that the changes made to fix defects
have not inadvertently affected other software parts.
7. Closure: A final report is generated, summarizing the testing process,
outcomes, and any remaining issues.
8. Performance Tuning: After identifying performance issues during testing,
developers may need to optimize the software's code, architecture, or
resources to enhance its speed, responsiveness, and efficiency.
 9. Security Patching: Security testing may reveal vulnerabilities that require
immediate attention. Developers must promptly address these issues through
patches or updates to ensure the software remains secure.
10.Documentation: Thorough documentation of the testing process, including
test cases, results, and any defects found, is essential for future reference,
maintenance, and compliance with industry standards.
11.User Acceptance Testing (UAT): In this phase, end-users validate the
software against their specific requirements. It ensures that the software meets
their needs and can be confidently deployed.
12.Deployment and Post-Deployment Testing: The software is deployed to the
production environment after successful testing and user acceptance. Post-
deployment testing confirms that the live system functions as expected and
monitors for unforeseen issues.

Best Practices in Software Testing

1. Early Testing: To catch and rectify issues before they become more complex
and costly, begin testing as early as possible in the software development life
cycle.
2. Continuous Integration and Continuous Deployment (CI/CD): Use
continuous integration (CI) or continuous delivery (CD) pipelines to automate
the integration of code changes and software deployment and ensure quick and
dependable software releases.
3. Maintain Test Environments: Ensure that testing environments accurately
mirror the production environment to simulate real-world conditions accurately.
4. Adopt Agile Testing Methods: Adopt agile approaches that encourage
continuous testing and iterative development to produce high-quality software
in shorter cycles.

Advantages of Testing in Software Engineering

1. Bug Detection and Prevention: In early development, testing finds and fixes
faults or errors, lowering the possibility of later costly problems.
2. Improved Reliability: Thorough testing gives developers and users trust by
guaranteeing that the programme operates consistently and dependably in
various scenarios.
3. Higher Quality Software: Extensive testing produces better software that
meets or exceeds user expectations, boosting user happiness and confidence.
4. Enhanced User Experience: Usability and user interface testing results in a
product that is easy to use and offers a satisfying experience.
5. Cost-Efficiency: It is more economical to find and fix problems at the testing
stage rather than after deployment, when they can have more severe effects.
6. Timely Delivery: Meeting project timelines is facilitated by efficient testing,
which finds and fixes problems early on to avoid deployment delays.
7. Increased Security: Security testing identifies vulnerabilities and weaknesses
in the software and allows developers to implement measures to protect
against potential cyber threats.
Disadvantages of Testing in Software
Engineering
1. Time-Consuming: Comprehensive testing can be time-consuming, potentially
extending project timelines. Striking a balance between thorough testing and
timely delivery is crucial.
2. False Positives and Negatives: Testing may generate false positives
(indicating an issue without one) or false negatives (failing to detect an actual
problem). Which can lead to confusion and inefficiencies.
3. Lack of Comprehensive Testing Environment: Disparities between testing
findings and real performance may arise from poor testing conditions that do
not closely resemble the production environment.
4. Balancing Act: It can be challenging to balance the requirement for quick
delivery and the depth of testing since extensive testing may cause product
releases to be delayed.
5. Subjectivity in Usability Testing: Usability testing can be subjective as it
relies on human judgment and perception. This can lead to differing opinions on
the user-friendliness of the software.
6. Complexity: Implementing a comprehensive testing strategy requires
expertise in various testing methodologies, tools and technologies, which can
be complex and challenging.

Tools of Testing in Software Engineering

1. Unit Testing:

a) JUnit:
Description: JUnit is a widely used open-source testing framework for Java
programming language. It provides annotations and assertions to write and
execute unit tests for Java applications.

Use Case: Mainly used for unit testing Java applications.

b) NUnit:
Description: NUnit is a unit testing framework for the .NET framework, written
in C#. It allows developers to write and execute unit tests for C#, F#, and
VB.NET applications.

Use Case: Primarily used for unit testing .NET applications.

c) pytest:
Description: pytest is a testing framework for Python. It allows for simple unit
tests and more complex functional testing and provides detailed reports on
test results.

Use Case: Commonly used for testing Python applications.

d) Jasmine:
Description: Jasmine is an open-source testing framework for JavaScript. It's
designed for testing JavaScript code in web applications and provides a clean
syntax for writing tests.

Use Case: Used for testing JavaScript code, especially in web applications.

e) RSpec:
Description: RSpec is a testing framework for Ruby. It follows a behaviour-
driven development (BDD) approach and allows developers to write descriptive
and readable tests.

Use Case: Commonly used for testing Ruby applications, following BDD
principles.

2. System Testing:

a) Selenium:
Description: Selenium is a widely used open-source tool for automating web
browsers. It allows testers to write scripts to interact with web elements,
making it suitable for various types of testing, including functional and
regression testing.

Use Case: Used for web application testing across different browsers.

b) Appium:
Description: Appium is an open-source tool for automating mobile
applications on iOS and Android platforms. It allows testers to write and
execute tests for mobile apps using various programming languages.

Use Case: Primarily used for mobile application testing on iOS and Android.

c) TestComplete:
Description: TestComplete is a commercial automated testing tool that
supports desktop, web, and mobile application testing. It provides a
comprehensive environment for functional, regression, and load testing.

Use Case: Used for automated desktop, web, and mobile application testing.

3. Acceptance Testing:

a) Cucumber:
Description: Cucumber is a popular tool for behavior-driven development
(BDD). It allows stakeholders to define application behaviour in plain text,
making it easier to understand and validate.
Use Case: Mainly used for acceptance testing and BDD.

4. Regression Testing:

a) Selenium (Web applications):

Description: Selenium is a widely used open-source tool for automating web
browsers. It supports multiple programming languages and allows testers to
create automated test scripts for web applications, making it a versatile tool for
regression testing.

Use Case: Selenium is particularly popular for web application testing,

including regression testing, to ensure that new updates or changes do not
introduce unintended side effects.

b) TestComplete (Desktop and Web):

Description: TestComplete is a commercial automated testing tool developed
by SmartBear. It offers a comprehensive environment for automated testing of
both desktop and web applications. It supports a wide range of scripting
languages.

Use Case: TestComplete is suitable for regression testing of desktop and web
applications, providing a unified platform for testing across multiple
environments.

c) JUnit (Java):
Description: JUnit is a widely used open-source testing framework for Java.
While it is commonly associated with unit testing, it can also be used for
regression testing. JUnit provides annotations and assertions to write and
execute test cases.

Use Case: JUnit is utilized for regression testing Java applications, ensuring
that new code changes do not adversely affect existing functionalities.

d) NUnit (.NET):
Description: NUnit is a popular open-source unit testing framework for
the .NET platform. Like JUnit, NUnit can also be employed for regression testing
of .NET applications. It provides a framework for writing and executing test
cases in C#, VB.NET, or F#.

Use Case: NUnit is used for regression testing .NET applications, ensuring that
new code changes do not introduce regression defects.

Types of Software Testing

In this section, we are going to understand the various types of software
testing, which can be used at the time of the Software Development Life Cycle.

As we know, software testing is a process of analyzing an application's

functionality as per the customer prerequisite.

If we want to ensure that our software is bug-free or stable, we must perform

the various types of software testing because testing is the only method that
makes our application bug-free.

The different types of Software Testing

The categorization of software testing is a part of diverse testing activities,
such as test strategy, test deliverables, a defined test objective, etc.
And software testing is the execution of the software to find defects.

The purpose of having a testing type is to confirm the AUT (Application Under
Test).

To start testing, we should have a requirement, application-ready,

necessary resources available. To maintain accountability, we should
assign a respective module to different test engineers.
The software testing mainly divided into two parts, which are as follows:

o Manual Testing
o Automation Testing

What is Manual Testing?

Testing any software or an application according to the client's needs without
using any automation tool is known as manual testing.

In other words, we can say that it is a procedure of verification and

validation. Manual testing is used to verify the behavior of an application or
software in contradiction of requirements specification.

We do not require any precise knowledge of any testing tool to execute the
manual test cases. We can easily prepare the test document while performing
manual testing on any application.

To get in-detail information about manual testing, click on the following link:
manual-testing.
Classification of Manual Testing
In software testing, manual testing can be further classified into three
different types of testing, which are as follows:

o White Box Testing

o Black Box Testing
o Grey Box Testing

For our better understanding let's see them one by one:

White Box Testing

In white-box testing, the developer will inspect every line of code before
handing it over to the testing team or the concerned test engineers.

Subsequently, the code is noticeable for developers throughout testing; that's

why this process is known as WBT (White Box Testing).

In other words, we can say that the developer will execute the complete
white-box testing for the particular software and send the specific application
to the testing team.
The purpose of implementing the white box testing is to emphasize the flow of
inputs and outputs over the software and enhance the security of an
application.

White box testing is also known as open box testing, glass box testing,
structural testing, clear box testing, and transparent box testing.

To get the in-depth knowledge about white box testing refers to the below
link: white-box-testing.

Black Box Testing

Another type of manual testing is black-box testing. In this testing, the test
engineer will analyze the software against requirements, identify the defects or
bug, and sends it back to the development team.

Then, the developers will fix those defects, do one round of White box testing,
and send it to the testing team.

Here, fixing the bugs means the defect is resolved, and the particular feature is
working according to the given requirement.

The main objective of implementing the black box testing is to specify the
business needs or the customer's requirements.
In other words, we can say that black box testing is a process of checking the
functionality of an application as per the customer requirement. The source
code is not visible in this testing; that's why it is known as black-box testing.

For more information about Black box testing, refers to the below link: black-
box-testing.

Types of Black Box Testing

Black box testing further categorizes into two parts, which are as discussed
below:

o Functional Testing
o Non-function Testing

Functional Testing
The test engineer will check all the components systematically against
requirement specifications is known as functional testing. Functional testing
is also known as Component testing.

In functional testing, all the components are tested by giving the value,
defining the output, and validating the actual output with the expected value.
Functional testing is a part of black-box testing as its emphases on application
requirement rather than actual code. The test engineer has to test only the
program instead of the system.

To get the detailed information about functional testing refers to the below
link: functional-testing.

Types of Functional Testing

Just like another type of testing is divided into several parts, functional testing
is also classified into various categories.

The diverse types of Functional Testing contain the following:

o Unit Testing
o Integration Testing
o System Testing

Now, Let's understand them one by one:

1. Unit Testing
Unit testing is the first level of functional testing in order to test any software.
In this, the test engineer will test the module of an application independently or
test all the module functionality is called unit testing.

The primary objective of executing the unit testing is to confirm the unit
components with their performance. Here, a unit is defined as a single testable
function of a software or an application. And it is verified throughout the
specified application development phase.

2. Integration Testing
Once we are successfully implementing the unit testing, we will go integration
testing. It is the second level of functional testing, where we test the data flow
between dependent modules or interface between two features is
called integration testing.

The purpose of executing the integration testing is to test the statement's

accuracy between each module.

Types of Integration Testing

Integration testing is also further divided into the following parts:

o Incremental Testing
o Non-Incremental Testing

Incremental Integration Testing

Whenever there is a clear relationship between modules, we go for incremental
integration testing. Suppose, we take two modules and analysis the data flow
between them if they are working fine or not.

If these modules are working fine, then we can add one more module and test
again. And we can continue with the same process to get better results.

In other words, we can say that incrementally adding up the modules and test
the data flow between the modules is known as Incremental integration
testing.

Types of Incremental Integration Testing

Incremental integration testing can further classify into two parts, which are as
follows:

1. Top-down Incremental Integration Testing

2. Bottom-up Incremental Integration Testing
Let's see a brief introduction of these types of integration testing:

1. Top-down Incremental Integration Testing

In this approach, we will add the modules step by step or incrementally and
test the data flow between them. We have to ensure that the modules we are
adding are the child of the earlier ones.

2. Bottom-up Incremental Integration Testing

In the bottom-up approach, we will add the modules incrementally and check
the data flow between modules. And also, ensure that the module we are
adding is the parent of the earlier ones.

Non-Incremental Integration Testing/ Big Bang Method

Whenever the data flow is complex and very difficult to classify a parent and a
child, we will go for the non-incremental integration approach. The non-
incremental method is also known as the Big Bang method.

3. System Testing
Whenever we are done with the unit and integration testing, we can proceed
with the system testing.

In system testing, the test environment is parallel to the production

environment. It is also known as end-to-end testing.

In this type of testing, we will undergo each attribute of the software and test if
the end feature works according to the business requirement. And analysis the
software product as a complete system.

Non-functional Testing
The next part of black-box testing is non-functional testing. It provides
detailed information on software product performance and used technologies.
Non-functional testing will help us minimize the risk of production and related
costs of the software.

Non-functional testing is a combination of performance, load, stress,

usability and, compatibility testing.

For more information about Non-functional testing, refer to the following

link: non-functional-testing.

Types of Non-functional Testing

Non-functional testing categorized into different parts of testing, which we are
going to discuss further:

o Performance Testing
o Usability Testing
o Compatibility Testing

1. Performance Testing
In performance testing, the test engineer will test the working of an application
by applying some load.

In this type of non-functional testing, the test engineer will only focus on
several aspects, such as Response time, Load, scalability, and Stability of
the software or an application.

Classification of Performance Testing

Performance testing includes the various types of testing, which are as follows:
 o Load Testing
o Stress Testing
o Scalability Testing
o Stability Testing

o Load Testing
While executing the performance testing, we will apply some load on the
particular application to check the application's performance, known as load
testing. Here, the load could be less than or equal to the desired load.

It will help us to detect the highest operating volume of the software and
bottlenecks.

o Stress Testing
It is used to analyze the user-friendliness and robustness of the software
beyond the common functional limits.

Primarily, stress testing is used for critical software, but it can also be used for
all types of software applications.

Refers to the below link for in-depth knowledge of stress testing: stress-testing.

o Scalability Testing
To analysis, the application's performance by enhancing or reducing the load in
particular balances is known as scalability testing.

In scalability testing, we can also check the system, processes, or

database's ability to meet an upward need. And in this, the Test Cases are
designed and implemented efficiently.

o Stability Testing
Stability testing is a procedure where we evaluate the application's
performance by applying the load for a precise time.

It mainly checks the constancy problems of the application and the efficiency
of a developed product. In this type of testing, we can rapidly find the system's
defect even in a stressful situation.

2. Usability Testing
Another type of non-functional testing is usability testing. In usability
testing, we will analyze the user-friendliness of an application and detect the
bugs in the software's end-user interface.

Here, the term user-friendliness defines the following aspects of an

application:

o The application should be easy to understand, which means that all the features
must be visible to end-users.
o The application's look and feel should be good that means the application
should be pleasant looking and make a feel to the end-user to use it.

3. Compatibility Testing
In compatibility testing, we will check the functionality of an application in
specific hardware and software environments. Once the application is
functionally stable then only, we go for compatibility testing.

Here, software means we can test the application on the different operating
systems and other browsers, and hardware means we can test the application
on different sizes.

Grey Box Testing

Another part of manual testing is Grey box testing. It is a collaboration of
black box and white box testing.

Since, the grey box testing includes access to internal coding for designing test
cases. Grey box testing is performed by a person who knows coding as well as
testing.
In other words, we can say that if a single-person team done both white box
and black-box testing, it is considered grey box testing.

Automation Testing
The most significant part of Software testing is Automation testing. It uses
specific tools to automate manual design test cases without any human
interference.

Automation testing is the best way to enhance the efficiency, productivity, and
coverage of Software testing.

It is used to re-run the test scenarios, which were executed manually, quickly,
and repeatedly.

In other words, we can say that whenever we are testing an application by

using some tools is known as automation testing.

We will go for automation testing when various releases or several regression

cycles goes on the application or software. We cannot write the test script or
perform the automation testing without understanding the programming
language.

.
Some other types of Software Testing
In software testing, we also have some other types of testing that are not part
of any above discussed testing, but those testing are required while testing any
software or an application.

o Smoke Testing
o Sanity Testing
o Regression Testing
o User Acceptance Testing
o Exploratory Testing
o Adhoc Testing
o Security Testing
o Globalization Testing
Let's understand those types of testing one by one:

In smoke testing, we will test an application's basic and critical features

before doing one round of deep and rigorous testing.

Or before checking all possible positive and negative values is known

as smoke testing. Analyzing the workflow of the application's core and main
functions is the main objective of performing the smoke testing.

Sanity Testing
It is used to ensure that all the bugs have been fixed and no added issues
come into existence due to these changes. Sanity testing is unscripted, which
means we cannot documented it. It checks the correctness of the newly added
features and components.

Regression Testing
Regression testing is the most commonly used type of software testing. Here,
the term regression implies that we have to re-test those parts of an
unaffected application.

Regression testing is the most suitable testing for automation tools. As per the
project type and accessibility of resources, regression testing can be similar
to Retesting.

Whenever a bug is fixed by the developers and then testing the other features
of the applications that might be simulated because of the bug fixing is known
as regression testing.

In other words, we can say that whenever there is a new release for some
project, then we can perform Regression Testing, and due to a new feature
may affect the old features in the earlier releases.

User Acceptance Testing

The User acceptance testing (UAT) is done by the individual team known as
domain expert/customer or the client. And knowing the application before
accepting the final product is called as user acceptance testing.

In user acceptance testing, we analyze the business scenarios, and real-time

scenarios on the distinct environment called the UAT environment. In this
testing, we will test the application before UAI for customer approval.

Exploratory Testing
Whenever the requirement is missing, early iteration is required, and the
testing team has experienced testers when we have a critical application. New
test engineer entered into the team then we go for the exploratory testing.

To execute the exploratory testing, we will first go through the application in all
possible ways, make a test document, understand the flow of the application,
and then test the application.

Adhoc Testing
Testing the application randomly as soon as the build is in the checked
sequence is known as Adhoc testing.
It is also called Monkey testing and Gorilla testing. In Adhoc testing, we
will check the application in contradiction of the client's requirements; that's
why it is also known as negative testing.

When the end-user using the application casually, and he/she may detect a
bug. Still, the specialized test engineer uses the software thoroughly, so he/she
may not identify a similar detection.

Security Testing

It is an essential part of software testing, used to determine the weakness,

risks, or threats in the software application.

The execution of security testing will help us to avoid the nasty attack from
outsiders and ensure our software applications' security.

In other words, we can say that security testing is mainly used to define that
the data will be safe and endure the software's working process.

Globalization Testing
Another type of software testing is Globalization testing. Globalization
testing is used to check the developed software for multiple languages or not.
Here, the words globalization means enlightening the application or software
for various languages.

Globalization testing is used to make sure that the application will support
multiple languages and multiple features.

In present scenarios, we can see the enhancement in several technologies as

the applications are prepared to be used globally.

Levels of Testing
In this section, we are going to understand the various levels of software
testing.

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

In order to detect an error, we will implement software testing; therefore, all

the errors can be removed to find a product with more excellent quality.
What are the levels of Software Testing?
Testing levels are the procedure for finding the missing areas and avoiding
overlapping and repetition between the development life cycle stages. We
have already seen the various phases such as Requirement collection,
designing, coding testing, deployment, and maintenance of SDLC
(Software Development Life Cycle).

In order to test any application, we need to go through all the above phases of
SDLC. Like SDLC, we have multiple levels of testing, which help us maintain the
quality of the software.

Different Levels of Testing

The levels of software testing involve the different methodologies, which can
be used while we are performing the software testing.

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

discussed below:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
As we can see in the above image that all of these testing levels have a
specific objective which specifies the value to the software development
lifecycle.

For our better understanding, let's see them one by one:

Level1: Unit Testing

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

The first level of testing involves analyzing each unit or an individual

component of the software application.

Unit testing is also the first level of functional testing. The primary purpose
of executing unit testing is to validate unit components with their performance.

A unit component is an individual function or regulation of the application, or

we can say that it is the smallest testable part of the software. The reason of
performing the unit testing is to test the correctness of inaccessible code.

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

Level2: Integration Testing

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

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

In integration testing, the test engineer tests the units or separate

components or modules of the software in a group.

The primary purpose of executing the integration testing is to identify the

defects at the interaction between integrated components or units.

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

We only go for the integration testing when the functional testing has been
completed successfully on each application module.
In simple words, we can say that integration testing aims to evaluate the
accuracy of communication among all the modules.

Level3: System Testing

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

It is end-to-end testing where the testing environment is parallel to the

production environment. In the third level of software testing, we will test the
application as a whole system.

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

known as System testing.

In system testing, we will go through all the necessary modules of an

application and test if the end features or the end business works fine, and test
the product as a complete system.

In simple words, we can say that System testing is a sequence of different

types of tests to implement and examine the entire working of an integrated
software computer system against requirements.

Level4: Acceptance Testing

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

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

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

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

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

What is a bug?
In software testing, a bug is the informal name of defects, which means that
software or application is not working as per the requirement. When we have
some coding error, it leads a program to its breakdown, which is known as a
bug. The test engineers use the terminology Bug.

If a QA (Quality Analyst) detect a bug, they can reproduce the bug and
record it with the help of the bug report template.

What is a Defect?
When the application is not working as per the requirement is knows
as defects. It is specified as the aberration from the actual and expected
result of the application or software.

In other words, we can say that the bug announced by the programmer and
inside the code is called a Defect.

What is Error?
The Problem in code leads to errors, which means that a mistake can occur due
to the developer's coding error as the developer misunderstood the
requirement or the requirement was not defined correctly.
The developers use the term error.

What is Fault?
The fault may occur in software because it has not added the code for fault
tolerance, making an application act up.
 A fault may happen in a program because of the following reasons:

o Lack of resources
o An invalid step
o Inappropriate data definition

What is Failure?
Many defects lead to the software's failure, which means that a loss specifies
a fatal issue in software/ application or in its module, which makes the system
unresponsive or broken.

In other words, we can say that if an end-user detects an issue in the product,
then that particular issue is called a failure.

Possibilities are there one defect that might lead to one failure or several
failures.

For example, in a bank application if the Amount Transfer module is not

working for end-users when the end-user tries to transfer money, submit
button is not working. Hence, this is a failure.

The flow of the above terminologies are shown in the following image:

Bug Vs. Defect Vs. Error Vs. Fault Vs. Failure

We have listed some of the vital differences between bug, defect, error,
fault, and failure in the below table.

Compa Bug Defect Error Fault Failure

rison
basis

Definitio It is an The Defect i An Error is a The Fault is a If the

n informal name s the mistake made state that software has
specified to difference in the code; causes the lots of
the defect. between the that's why we software to fail defects, it
actual cannot to accomplish leads to
outcomes execute or its essential failure or
and compile code. function. causes
expected failure.
outputs.

Raised The Test The Testers The Develop Human The failure
by Engineers su identify the ers and mistakes caus finds by the
bmit the bug. defect. And it automation e fault. manual test
was also test engineer
solved by the engineers rai through
developer in se the error. the develop
the ment cycle.
development
phase or
stage.

Differen Different type Different Different type Different type -----

t types of bugs are as type of of Error is as of Fault are as
follows: Defects are below: follows:
as follows:
o Logic Based o Syntacti o Business
bugs on priority: c Error Logic
o Algorith o User Faults
mic o High interfac o Function
bugs o Mediu e error al and
o Resourc m o Flow Logical
e bugs o Low control Faults
And based error o Faulty
on the o Error GUI
severity: handlin o Performa
g error nce
o Critical o Calculat Faults
o Major ion error o Security
o Minor o Hardwar Faults
o Trivial e error o Software/
o Testing hardware
Error fault
Reasons Following are The below The reasons The reasons Following
behind reasons which reason leads for having behind are some of
may cause to an error are the fault are the most
the bugs: the defects: as follows: as follows: important
Missing coding Giving Errors in the A Fault may reasons
Wrong coding incorrect and code. occur by an behind
Extra coding wrong The Mistake improper step the failure:
inputs. of some in the initial Environment
Dilemmas values. stage, process, al condition
and errors in If a developer or data System
the outside is unable to definition. usage
behavior and compile or Inconsistency Users
inside run a or issue in the Human error
structure and program program.
design. successfully. An irregularity
An error in Confusions or loophole in
coding or and issues in the software
logic affects programming. that leads the
the software Invalid login, software to
and causes it loop, and perform
to syntax. improperly.
breakdown Inconsistency
or the failure.
between
actual and
expected
outcomes.
Blunders in
design or
requirement
actions.
Misperception
in
understanding
the
requirements
of the
application.
Way to Following are With the help Below are The fault can The way to
prevent the way to of the ways to be prevented prevent fail
the stop following, we prevent with the help of ure are as
reasons the bugs: can prevent the Errors: the following: follows:
Test-driven the Defects: Enhance the Peer review. Confirm re-
development. Implementin software Assess the testing.
Offer g several quality with functional Review the
programming innovative system review necessities of requirement
language programming and the software. s and revisit
 support. methods. programming. Execute the the
Adjusting, Use of Detect the detailed code specification
advanced, andprimary and issues and analysis. s.
operative correct prepare a Verify the Implement
development software suitable correctness of current
procedures. development mitigation software protective
Evaluating the
techniques. plan. design and techniques.
code Peer review Validate the programming. Categorize
systematically
It is fixes and and
. executing verify their evaluate
consistent quality and errors and
code reviews precision. issues.
to evaluate
its quality
and
correctness.
Comparison Basis Top-Down Bottom-up
Integration Testing Integration Testing

Definition We will add the The lower-level

modules modules are tested
incrementally or one with higher-level
by one and test the modules until all the
data flow in similar modules have been
order. tested successfully.

Executed on The top-down The bottom-up

integration testing integration testing
approach will be approach will be
executed on the executed on Object-
Structure or oriented
procedure-oriented programming
programming languages.
languages.

Observation In the top-down In the bottom-up

approach, the approach, the
observation of test observation of test
output is more output is more
complicated. accessible.
Risk analysis We are collaborating To analyze the
on the impact of individual process, we
internal operational can use the Models.
failures.

Work on The top-down The bottom-down

integration testing integration testing
approach will work on approach will work on
major to minor the miner to
components. significant
components.

Complexity The complexity of the The complexity of the

top-down approach is bottom-up approach
simple. is complex and highly
data intensive.

Stub/Driver Stub modules must The driver modules

creation be created in the top- must be created in
down testing the bottom-up testing
approach. approach.

Managed from It is performed from It is performed from

main-module to sub- the sub-module to the
module. main module.

Advantage Following are some of Below are some of the

the significant essential advantages
benefits of using top- of using bottom-up
down integration integration testing:
testing:
o We do not need
o In this, the early to wait for the
prototype is development of
possible. all the modules
o Fault as it saves time.
Localization is o Identification of
easier. defects is easy.
Disadvantage Some of the most The disadvantage of
common drawbacks the bottom-up
of the top-down approach is as
approach are as follows:
follows:
o Compulsory
o Lower-level modules are
 modules are tested last, due
tested to which the
ineffectively. defects can
o Due to the high occur.
number of o There is no
stubs, it gets possibility of an
pretty early prototype.
complicated.
o Critical Modules
are tested first
so that fewer
chances of
defects.

Describe Stubs and Drivers in the Software

Testing?
In Software Testing, the words stub and drivers described as a replica of the
modules that operate as an alternative to the new or missing modules.

Stubs are mainly used in top-down integration testing; on the other hand,
drivers are mainly used in bottom-up integration testing individually and
designed the enhance the testing process.

To sustain the essential requirements of the inaccessible modules or

components, we are precisely established the stubs and drives. And extremely
beneficial in getting the anticipated outcomes.

Both Stubs and drivers are the essential part of the basic software
development and software testing process. Thus, to help us understand the
substance of stubs and drivers in software testing, we will see an exhaustive
discussion.

What are Stubs?

 o A stub is a replica of a module that collects the data and develops many
possible data. However, it executes like an actual module and is mainly used to
test modules.
o Generally, stubs are created by software developers in order to use them
instead of modules if the particular modules are miss or not yet developed.
o By using these test stubs, the test engineers can simulate the performance of
the lower-level modules, which are not yet joined with the software.
Furthermore, it helps us to accelerate the activity of the missing modules.

Types of Stubs
In the top-down approach of incremental integration testing, the stubs are
divided into four essential parts, which are as follows:

o Demonstrate the trace message.

o Exhibits the parameter values.
o Returns the consistent values, which are handled by the modules or the
components.
o Returns the values of the specific parameters, which were utilized by testing
components or modules.

What are Drivers?

o The Drivers establish the test environments and takes care of the
communication, estimates results, and also sends the reports.
o These are just like stubs and used by software test engineers in order to
accomplish the missing or incomplete modules/ components requirements.
o The drivers are mainly developed in the Bottom-up approach of incremental
integration testing.
o Generally, drivers are bit complex as compared to the stubs.
o These can test the lower levels of the code when the upper-level modules or
codes are not developed or missing.
o In other words, we can say that the Drivers perform as pseudo-codes, which
are mainly used when the stub modules are completed; however, the initial
modules/components are not prepared.

Examples of Stubs and Drivers

Let us see an example of stubs and drivers, which help us to enhance our
knowledge of stubs and drivers.

Suppose we have one web application that contains four different modules,
such as:

o Module-P
o Module-Q
 o Module-R
o Module-S
And all the modules, as mentioned earlier, are responsible for some individual
activities or functionality, as we can observe in the following table:

Different Modules Individual Activities

Module-P Login page of the web application

Module-Q Home-page of the web application

Module-R Print Setup

Module-S Log out page

Note: Modules P, Q, R, and S encompasses the dependencies of each

module over the other.
It is always a better approach to implement the testing or development of all
the modules equivalently. The minute each gets developed, they can be
combined and tested according to their similar dependencies with a module.

Once Module-P is developed, it will go through the testing process. But, to

perform and validate the testing methods regarding Module-P, they
need Module-Q, which is not yet developed entirely and still in the developing
process.

And it is not possible to test Module-P on the lack of Module-Q. Thus, in such
scenarios, we will take the help of Stubs and Drivers in the software
testing process.

The Stubs and drivers will replicate all the basic functionality and features
displayed by the real Module-Q. And subsequently, it is being combined
with Module-P in order to execute the testing process effectively.

Now, we can validate the estimated functionality of the Login page, which
was in Module-P, only if it is going to the Home Page, which is the activity
of Module-Q as per the correct and valid inputs.

In the same way, stubs and drivers are used to accomplish the requirements
of other modules, such as the Sign-out page, which comes under the Module-
S and needs to be aimed to the Login page (Module-P) after effectively
logging out from the particular application.
Likewise, we may also use Stubs or Drivers instead of Module-R and Module-
S if they are not available.

As the result of the inaccessibility of Module-P, stubs and drivers will work as
an alternate for it to perform the testing of Module-S.

But here, the question arises that both drivers and Stubs serve the
same functionality?

Let's find the answer to the above question:

Yes, we can say that both stubs and drivers carry out similar features and
objectives. Both of them act as an alternative for the missing or absent
module. But, the change between them can be pictured throughout the
integration testing process.

The key difference between Stubs and Drivers

The below facts explain the critical differences between stubs and
drivers during the integration testing process.

o Stubs and Drivers design as a dummy for the missing or inaccessible modules
or the components.
o Most commonly, stubs and drivers are used in the incremental
integration testing, where stubs are used in top-bottom
methodology while drivers are used in a bottom-up methodology.
o Usually, developers and unit test engineers are included in the creation of stubs
and drivers.
o Even though it provides an ease to perform the separate components or the
modules without worrying about the accessibility of other modules, and leads
them into a time-consuming process, as it involves the development of replica
for all the missing modules.
o Precisely, stubs and drivers are developed for each module holding different
purposes.
Stubs VS Drivers
Here, we are discussing some significant comparisons between Stubs and
Drivers in the below table:

Stubs Drivers

A section of code that imitates A section of code that imitates

the called function is known as the calling function is known as
Stubs. Drivers.

It is used to test the When the main module is

functionality of modules and prepared or ready, we will take
test modules and also replicate the help of drivers. Generally,
the performance of the lower- drivers are a bit more complex
level module which are not yet as compared to the stubs.
merged, and the activity of the
missing module/components.

The stubs are developed during The drivers are developed

the Top-down approach of during the bottom-up approach
incremental integration testing. of incremental integration
testing.

Stubs replicate the activity of Drivers authorizes test cases to

not developed and missing another system and which refer
modules or components. the modules under testing.

The stubs are created by the Mostly, the drivers are created
team of test engineers. by the developer and the unit
Test engineers.

Stubs are developed when high- Drivers are acquired when

level modules are tested, and lower-level modules are tested,
lower-level modules are not and higher-level modules are
 formed. not yet developed.

These are parallel to the On the other hand, the drivers

modules of the software, which are used to reminding the
are under development process. component, which needs to be
tested.

The stubs signify the low-level The drivers signify the high-
modules. level modules.

Fundamentally, the Stubs are The Drivers are also known as

also known as a called program the calling program and are
and initially used in the Top- mainly used in bottom-up
down integration testing. integration testing.

These are reserved for testing The drivers are used if the core
the feature and functionality of module of the software isn't
the modules. established for testing.

What is Software Technical Review?

The software technical review is a critical assessment of every detail in the
software. It helps to detect defects from the initial phases of the software
development life cycle (SDLC). It is a formal process where the various
software documents such as requirements, specifications, design documents,
source code, test plans, test strategy, test cases etc are evaluated by peers to
identify faults, and areas of improvements. The ultimate objective of the
technical review is to check if the software is built as per its requirements, and
to ensure that it does not contain issues which may impact the later phases of
the software development process.

Objectives of Software Technical Review

The objectives of the software technical review are listed below −

 The software technical review finds defects from the early stages of the SDLC.
 The technical review ensures that the software is built as per compliances, standards,
and requirements.
 The software technical review suggests areas of improvements in the documentation,
design, architecture, and code.
 The software technical review encourages exchange of knowledge among all the team
members.
 The technical review ensures that the software adheres to compliances, and
regulations.

Types of Software Technical Review

The different types of the software technical review are listed below −

1. Peer Review
They are informal, and unstructured reviews done by the team members,
peers, or colleagues to provide fast feedback so that the quality of delivered
software is enhanced, and quick corrective measures are taken. It proceeds
with the help of collaborative discussions. It occurs without prior planning may
be at the time of knowledge sharing or pair programming. For example, a
developer requests his team mate to review his code.

2. Walkthroughs
They are semi-formal reviews where the author of the document or code
describes it to a group of reviewers. The objective is mainly to share the
understanding of his work among the team members rather than finding
errors. The reviewers ask questions and pass the required suggestions. There
is no formal defect logging in the process. It is generally a knowledge sharing
platform. For example, the project manager walks through the project roadmap
to the entire team.

3. Inspections
They are formal, methodical, and structured reviews done to detect errors, and
to suggest areas of correction. It is used to identify defects from the early
stages of the SDLC, and to improve the software quality. It involves proper
planning, composition, meeting, rework, and follow up. It comprises the
moderator, author, scribe, reviewers etc. For example, a development team
organizes an inspection meeting on the code developed for the last release of
the software.
 4. Audits
These types of reviews are done to ensure that the software is built as per the
given requirements, regulations, standards, legal and contractual agreements.
They are conducted by external or internal teams. The audits are on the basis
of some predefined criterias, the discrepancies and non-compliances are
documented, and reported. For example, a group of auditors reviews if the
software development processes followed are as per the ISO standards.

Differences between Formal and Informal Reviews

The differences between the formal and informal reviews are listed below −

Sr.N
Formal Reviews Informal Reviews
o.

They help to identify bugs, and to ensure They give fast feedback, and find
1 that the software is built as per the obvious defects in the software usually
compliances, and specifications. during the knowledge sharing process.

They are formal, methodical, and structured

They are informal, and unstructured
reviews which involve proper planning,
2 reviews and conducted on an ad hoc
composition, meeting, rework, and follow
basis.
up.

They involve exhaustive documentations They involve minimal documentations,

3 involving the defects, details of meetings, and depend on verbal communications,
and corrective actions suggested. and notes.

They consist of the moderator, author,

They consist of the project stakeholders
4 scribe, reviewers etc who have been
who have been informally invited.
formally invited.

Importances of Software Technical Review

The importances of the software technical review are listed below −

 The software technical review boosts the confidence, and morale of the team
members for being able to show cause their works to external members.
 The technical review improves the developers overall understanding of the working of
software, and which in turn helps them to maintain the code in an efficient manner.
 The software technical aids in tracking the project with respect to the customers, and
project management.
 The technique helps to gather feedback, and suggestions on the software, and its
development process.

What is Software Compliance Testing?

The software compliance testing is performed so that the software follows all
the rules given by the regulatory authorities, and it is as per the industry
standards. These rules include topics such as security, accessibility, privacy of
data etc. It is similar to a list of checklist items which should be followed to
ensure that software is at par, and can overlap with other similar software.

Why is compliance important?

Compliance in software development is like playing by the rules, keeping
things safe, making people trust us, and making sure our software works fine
and is well accepted by everyone. Inability to follow software development
compliance standards could result in fines, legal problems, users’
disappointment, losing an opportunity to go global with our product, and so on.

Key aspects of compliance

Key aspects of compliance in software development include:
Coding Standards
General coding standards refers to how the developer writes code, so here we
will discuss some essential standards regardless of the programming language
being used.

The following are some representative coding standards:

1. Indentation: Proper and consistent indentation is essential in producing
easy to read and maintainable programs.
Indentation should be used to:
o Emphasize the body of a control structure such as a loop or a
select statement.
o Emphasize the body of a conditional statement
o Emphasize a new scope block
2. Inline comments: Inline comments analyze the functioning of the
subroutine, or key aspects of the algorithm shall be frequently used.
3. Rules for limiting the use of global: These rules file what types of
data can be declared global and what cannot.
4. Structured Programming: Structured (or Modular) Programming
methods shall be used. "GOTO" statements shall not be used as they
lead to "spaghetti" code, which is hard to read and maintain, except as
outlined line in the FORTRAN Standards and Guidelines.
5. Naming conventions for global variables, local variables, and
constant identifiers: A possible naming convention can be that global
variable names always begin with a capital letter, local variable names
are made of small letters, and constant names are always capital letters.
6. Error return conventions and exception handling system: Different
functions in a program report the way error conditions are handled
should be standard within an organization. For example, different tasks
while encountering an error condition should either return a 0 or 1
consistently.