School of Computing Science and Engineering

Course Code:BTCS3503 Course Name: Software Testing & Quality Assurance

MCSE2320

Unit 2: Introduction to Software

Testing
Introduction to Software Testing: What is software testing and why it is so hard, Error, Fault,
Failure, Incident, Test Cases, Testing Process, Limitations of Testing,
Testing Activities: Levels of Testing, Unit Testing, Integration Testing, System Testing, Debugging,
Domain Testing.

Program Name: B.Tech Dr Shajahan

 Topics to be covered

• Introduction to Software Testing: What is software testing and why it is so hard,

• Error, Fault, Failure, Incident,

• Test Cases, Testing Process, Limitations of Testing,

• Testing Activities: Unit Testing,

• Levels of Testing, Integration Testing, System Testing,

• Debugging, Domain Testing.

 Error, Fault, Failure

• Testing is the process of identifying defects, where a defect is any variance

between actual and expected results. “A mistake in coding is called Error, error
found by tester is called Defect, defect accepted by development team then it is
called Bug, build does not meet the requirements then it Is Failure.”
 Error, Fault, Failure,

• Error :
• an error is usually a programmer action or omission that results in a fault.
• Refers to difference between Actual Output and Expected output.
• Fault :
• A fault is a software defect that causes a failure.
• It is a condition that causes the software to fail to perform its required
function.
Failure
• A failure is the unacceptable departure of a program operation from program
requirements.
• It is the inability of a system or component to perform required function
according to its specification.
 Error, Fault, Failure,

• IEEE Definitions
• Error: Human mistake that caused fault
• Fault: Discrepancy in code that causes a failure.
• Failure: External behavior is incorrect

• Note:

• Error is terminology of Developer.

• Bug is terminology of Tester

 Error, Fault, Failure,

• Software Testing is generally performed for one of two reasons –

 To detect the existence of defects (faults).
 To estimate the reliability of the code.
 Defect, Error, Bug, Failure and Fault!

• DEFECT:

• It can be simply defined as a variance between expected and actual. The defect is an error found AFTER
the application goes into production. It commonly refers to several troubles with the software products, with
their external behavior or with its internal features. In other words, a Defect is a difference between
expected and actual results in the context of testing. It is the deviation of the customer requirement.

• BUG:

• A bug is the result of a coding error. An Error found in the development environment before the product is
shipped to the customer. A programming error that causes a program to work poorly, produce incorrect
results or crash. An error in software or hardware that causes a program to malfunction. A bug is the
terminology of Tester.
 Defect, Error, Bug, Failure and Fault!

• FAILURE:

• A failure is the inability of a software system or component to perform its required functions within specified
performance requirements. When a defect reaches the end customer it is called a Failure. During
development, Failures are usually observed by testers.

• FAULT:

• An incorrect step, process or data definition in a computer program that causes the program to perform in
an unintended or unanticipated manner. A fault is introduced into the software as the result of an error. It is
an anomaly in the software that may cause it to behave incorrectly, and not according to its specification. It
is the result of the error.

• The software industry can still not agree on the definitions for all the above. In essence, if you use the term
to mean one specific thing, it may not be understood to be that thing by your audience.
Fault/Failure Model
• To understand why faults hide during testing, it is necessary to know the sequence of
events that must occur in order to observe incorrect output :
 An input must cause a defect to be executed.
 Once the defect is executed, the succeeding data state must become corrupted. This
data state is hence referred to as containing a data state error.
 After a data state error is created, the data state error must propagate to an output
state, meaning that incorrect output exits the software.
This sequence of events is called the “fault/failure” model, because it relates
faults, data state errors and failures.

Failure Fault Error Failure Fault

 TEST CASE

• The test case is defined as a group of

conditions under which a tester determines
whether a software application is working as
per the customer's requirements or not.

• Test case designing includes preconditions,

case name, input conditions, and expected
result. A test case is a first level action and
derived from test scenarios.
 TEST CASE

• A test case is a defined format for software testing required to check if a particular
application/software is working or not.
• A test case consists of a certain set of conditions that need to be checked to test an
application or software i.e. in more simple terms when conditions are checked it
checks if the resultant output meets with the expected output or not.
• A test case consists of various parameters such as Id, condition, steps, input,
expected result, result, status, and remarks.
 TEST CASE

• A test case is a defined format for software testing required to check if a particular
application/software is working or not.
• A test case consists of a certain set of conditions that need to be checked to test an
application or software i.e. in more simple terms when conditions are checked it
checks if the resultant output meets with the expected output or not.
• A test case consists of various parameters such as Id, condition, steps, input,
expected result, result, status, and remarks.
 TEST CASE

Why we write the test cases?

• We will write the test for the following reasons:
• To require consistency in the test case execution
• To make sure a better test coverage
• It depends on the process rather than on a person
• To avoid training for every new test engineer on the product
 TEST CASE

Best practice for writing test case

• There are certain practices which one could follow while writing the test cases that would be considered as beneficial.
• Simple and clear: Test cases need to be very concise, clear, and transparent. They should be easy and simple to understand not only for
oneself but for others as well.
• Maintain the uniqueness: While writing the test cases, it’s necessary to make sure that they aren’t being written over and over again and
each case is different from the other.
• Zero Assumptions: Test cases should not contain assumed data, don’t come up with features/modules that don’t exist.
• Traceability: – Test cases should be traceable for the future reference, so while writing it’s important to keep that in mind,
• Different input data: While writing test cases, all types of data must be taken into consideration.
• Strong module name: The module name should be self-explanatory while writing the test case.
• Minimal Description: The description of a test case should be small, one or two lines are normally considered good practice but it should give
the basic overview properly.
• Maximum conditions: All kinds of conditions should be taken into consideration while writing a test, increasing the effectiveness.
• Meeting requirements: While writing the test case it’s important that the client/customer/end-user requirements are met.
• Repetitive Results: The test case must be written in such a way that it should provide the same result.
• Different Techniques: Sometimes testing all conditions might not be possible but using different testing with different test cases could help to
check every aspect of a software.
 TEST CASE
Test Case Management Tools - A few of the tools are listed below:
• Testpad: Testpad is a simple tool that makes test case management easier. The software’s main motto says that it aims to find
a bug that matters. Few features of Testpad include manual testing, reports of the test cases and software, dragging and
dropping to make testing easier, inviting guest testers by email, building custom templates, and much more.
• TestCaseLab: TestCaseLab is easily manageable for the test cases and could swiftly integrate them with bug trackers. The
features of TestCaseLab include Custom test cases, Test Runs, Integrations of test cases, Test Plans, tags and priority for test
cases, search by name of test cases, description and tags, etc.
• TestRail: TestRail is another platform that aims to make test case management easier, it streamlines the software testing
processes and along with more visibility into QA. The basic features of TestRail include management for test cases, plans,
and runs, more test coverage, real-time insights into the QA progress, etc.
• TestLodge: TestLodge is a test case management tool that helps the entire team to manage their requirements, test plans,
test cases, and test runs all in one single place and also with no user limit. The basic features of TestLodge include Test
Plans, Test Runs, Dashboard, Test Suite, and many more.
 TEST CASE

Types of Test Cases

• Functionality Test Case:
• Unit Test Case:
• User Interface Test Case:
• Integration Test Case:
• Performance Test Case:
• Database Test Case:
• Security Test Case:
• Usability Test Case:
• User Acceptance Test Case:
TEST CASE - Example
TEST CASE - Example
TEST CASE - Example
 Software Testing

What is Software Testing

• Software testing is a process of identifying the
correctness of software by considering its all
attributes (Reliability, Scalability, Portability,
Re-usability, Usability) and evaluating the
execution of software components to find the
software bugs or errors or defects.
 Testing

• Software testing is the process of executing a program with the aim of finding the
error.
• To make our software perform well it should be error-free.
• If testing is done successfully it will remove all the errors from the software.
• Software testing is an activity which aims at evaluating the quality of a software
product and also to improve it by identifying defects.
• Software testing strives to achieve its objectives but has certain limitations.
However, adherence to the established objectives ensures effective testing.
Testing - Objectives
 Testing Objectives

1. To evaluate the work products such as requirements, design, user stories, and code: ...
2. To verify the fulfillment of all specified requirements: ...
3. To validate if the test object is complete and works as per the expectation of the users and the stakeholders:
4. To build confidence in the quality level of the test object:
5. To prevent defects in the software product:
6. To find defects in the software product:
7. To provide sufficient information to stakeholders to allow them to make informed decisions, especially regarding the
level of quality of the test object:
8. To reduce the level of risk of insufficient software quality:
 Testing Principles

Testing is the process of executing a program with the aim of finding errors. To make our software perform well it
should be error-free. If testing is done successfully it will remove all the errors from the software.
Principles of Testing:-
(i) All the test should meet the customer requirements
(ii) To make our software testing should be performed by a third party
(iii) Exhaustive testing is not possible. As we need the optimal amount of testing based on the risk assessment of
the application.
(iv) All the test to be conducted should be planned before implementing it
(v) It follows the Pareto rule(80/20 rule) which states that 80% of errors come from 20% of program components.
(vi) Start testing with small parts and extend it to large parts.
 Testing Principles

There are seven principles in software testing:

1.Testing shows the presence of defects
2.Exhaustive testing is not possible
3.Early testing
4.Defect clustering
5.Pesticide paradox
6.Testing is context-dependent
7.Absence of errors fallacy
 Testing Principles

1. Testing shows the presence of defects:

The goal of software testing is to make the software fail. Software testing reduces the presence of defects.
Software testing talks about the presence of defects and doesn’t talk about the absence of defects. Software
testing can ensure that defects are present but it can not prove that software is defect-free. Even multiple testing
can never ensure that software is 100% bug-free. Testing can reduce the number of defects but not remove all
defects.
 Testing Principles

2. Exhaustive testing is not possible:

It is the process of testing the functionality of the software in all possible inputs (valid or invalid) and pre-
conditions is known as exhaustive testing. Exhaustive testing is impossible means the software can never test at
every test case. It can test only some test cases and assume that the software is correct and it will produce the
correct output in every test case. If the software will test every test case then it will take more cost, effort, etc.,
which is impractical.
 Testing Principles

3. Early Testing:
To find the defect in the software, early test activity shall be started. The defect detected in the early phases of
SDLC will be very less expensive. For better performance of software, software testing will start at the initial
phase i.e. testing will perform at the requirement analysis phase.

4. Defect clustering:
In a project, a small number of modules can contain most of the defects. Pareto Principle to software testing
state that 80% of software defect comes from 20% of modules.
 Testing Principles

5. Pesticide paradox:
Repeating the same test cases, again and again, will not find new bugs. So it is necessary to review the test
cases and add or update test cases to find new bugs.

6. Testing is context-dependent:
The testing approach depends on the context of the software developed. Different types of software need to
perform different types of testing. For example, The testing of the e-commerce site is different from the testing of
the Android application.

7. Absence of errors fallacy:

If a built software is 99% bug-free but it does not follow the user requirement then it is unusable. It is not only
necessary that software is 99% bug-free but it is also mandatory to fulfill all the customer requirements.
 Software Testing

Software testing can be divided into two steps:

1. Verification: it refers to the set of tasks that ensure that the software correctly
implements a specific function.

2. Validation: it refers to a different set of tasks that ensure that the software that has
been built is traceable to customer requirements.

Verification: “Are we building the product right?”

Validation: “Are we building the right product?”
 Level of Software Testing

Software level testing can be majorly classified into 4 levels:

1. Unit Testing: A level of the software testing process where individual units/components of a
software/system are tested. The purpose is to validate that each unit of the software performs as
designed.
2. Integration Testing: A level of the software testing process where individual units are combined and
tested as a group. The purpose of this level of testing is to expose faults in the interaction between
integrated units.
3. System Testing: A level of the software testing process where a complete, integrated
system/software is tested. The purpose of this test is to evaluate the system’s compliance with the
specified requirements.
4. Acceptance Testing: A level of the software testing process where a system is tested for
acceptability. The purpose of this test is to evaluate the system’s compliance with the business
requirements and assess whether it is acceptable for delivery.
Level of Software Testing
 Level of Software Testing - Unit Testing

• This is ideally our first level of testing software.

• How does it work?
• Here, specific lines of code, distinct functionalities, and desired procedures are isolated and
tested.
• These lines of code, functionalities, and procedures are termed software units because they are
combined to make up the software.
• They can also be referred to as components of the software.
 Level of Software Testing - Unit Testing

For example, a line of code in a “calculator software” can have the function of
implementing “addition,” while another line of code implements “multiplication,” etc.
These addition and multiplication functions and other functions of the calculator
software must be individually tested to ensure that the calculator operates flawlessly.
You do not want to start a calculator that implements a division when users click on
the add sign.

Unit testing is a process that mostly involves testing the internal workings of the
software. It’s easy and quick to do because it deals with the software unit by unit, not
as a whole.
 Level of Software Testing - Integration Testing

• This testing level involves combining all the components that make up the software and testing
everything as a whole instead of individually as done during unit testing.
• Why is integration testing needed?
• First, the integrated codes could have been written by different developers, and need to be
tested to ensure their correctness.
• By testing, we can identify and correct inter-working defects, simultaneous operation defects,
parallel operation defects, etc.
 Level of Software Testing - Integration Testing

• For example, we could verify if the following conditions from the checklist were met:
• If communication between the systems is carried out correctly
• If linked documents can run smoothly on all platforms
• Whether security specifications work during communication between systems
• Whether the software can withstand network breakdowns between the web servers and app
servers
 Level of Software Testing - Integration Testing

• Integration testing can be done in two ways: Bottom-up integration testing and Top-down integration
testing.
• Bottom-up integration
• This testing begins with unit testing, followed by tests of progressively higher-level combinations
of units called modules or builds.
• Top-down integration
• In this testing, the highest-level modules are tested first and progressively, lower-level modules
are tested thereafter.
 Level of Software Testing - System Testing

• System testing has to do with verifying the required operations of the software and its compatibility
with operating systems.
• In other words, we test both the technicalities and the business logic of the software;
• we run functional tests to check what the various functions of a system do, and non-functional tests
to check how those functions work.
• For instance, in functional testing, we check if a login feature responds when the user enters a
password. But in non-functional testing, we check how long it takes the user to log in after password
entry.
 Level of Software Testing - System Testing

System testing is important because of the following reasons −

• System testing is the first step in the Software Development Life Cycle, where the application is
tested as a whole.
• The application is tested thoroughly to verify that it meets the functional and technical specifications.
• The application is tested in an environment that is very close to the production environment where
the application will be deployed.
• System testing enables us to test, verify, and validate both the business requirements as well as the
application architecture.
 Level of Software Testing - Acceptance Testing

This level of software testing is similar to the system testing, but here, the test is carried out by some selected end-
users. This is the only software testing stage that is carried out by users. This stage determines if the software is
finally ready to be launched to the general public.

All the selected users give their various opinions about the operation of the software; they let the organization
know whether the software meets their diverse requirements, and recommend areas that may need to be
improved upon. Acceptance testing can also be referred to as User Acceptance Testing.

Though each organization may conduct acceptance testing using its own specifics — who and where to test — it is
vital that we select users with different demographics, operating systems, and unique past experiences of using
similar software.
 Level of Software Testing - Acceptance Testing

There are two types of Acceptance Testing:

1. Alpha Testing
2. Beta Testing
Alpha Testing
This test is the first stage of testing and will be performed amongst the teams (developer and QA teams). Unit
testing, integration testing and system testing when combined together is known as alpha testing. During this
phase, the following aspects will be tested in the application −
• Spelling Mistakes
• Broken Links
• Cloudy Directions
• The Application will be tested on machines with the lowest specification to test loading times and any
latency problems.
 Level of Software Testing - Acceptance Testing

Beta Testing
• This test is performed after alpha testing has been successfully performed. In beta testing, a sample of the
intended audience tests the application. Beta testing is also known as pre-release testing.
• Beta test versions of software are ideally distributed to a wide audience on the Web, partly to give the program a
"real-world" test and partly to provide a preview of the next release.
• In this phase, the audience will be testing the following −
• Users will install, run the application and send their feedback to the project team.
• Typographical errors, confusing application flow, and even crashes.
• Getting the feedback, the project team can fix the problems before releasing the software to the actual users.
• The more issues you fix that solve real user problems, the higher the quality of your application will be.
• Having a higher-quality application when you release it to the general public will increase customer satisfaction.
 Verification and Validations

Verification testing
Verification testing includes different activities such as
business requirements, system requirements, design
review, and code walkthrough while developing a
product.
It is also known as static testing, where we are
ensuring that "we are developing the right product or
not".
And it also checks that the developed application
fulfilling all the requirements given by the client.
 Verification and Validations
Validation testing
• Validation testing is testing where tester performed functional and non-functional testing.
• Here functional testing includes Unit Testing (UT), Integration Testing (IT) and System Testing (ST),
and non-functional testing includes User acceptance testing (UAT).
• Validation testing is also known as dynamic testing, where we are ensuring that "we have developed
the product right." And it also checks that the software meets the business needs of the client.
 Debugging

Debugging is the process of fixing a bug in the software.

• It can defined as the identifying, analyzing and removing errors.
• This activity begins after the software fails to execute properly and concludes by solving the problem and
successfully testing the software.
• It is considered to be an extremely complex and tedious task because errors need to be resolved at all stages of
debugging.
 Debugging

Why do we need Debugging?

The process of debugging begins as soon as the code of the software is written. Then, it continues in successive
stages as code is combined with other units of programming to form a software product. Debugging has many
benefits such as:
• It reports an error condition immediately. This allows earlier detection of an error and makes the process of
software development stress-free and unproblematic.
• It also provides maximum useful information of data structures and allows easy interpretation.
• Debugging assists the developer in reducing useless and distracting information.
• Through debugging the developer can avoid complex one-use testing code to save time and energy in software
development.
 Debugging

Debugging Process: Steps involved in debugging are:

• 1. Identify the Error: A bad identification of an error can lead to wasted
developing time. It is usual that production errors reported by users
are hard to interpret and sometimes the information we receive is
misleading. It is import to identify the actual error.
• 2. Find the Error Location: After identifying the error correctly, you
need to go through the code to find the exact spot where the error is
located. In this stage, you need to focus on finding the error instead of
understanding it.
• 3. Analyze the Error: In the third step, you need to use a bottom-up
approach from the error location and analyze the code. This helps you
in understanding the error. Analyzing a bug has two main goals, such
as checking around the error for other errors to be found, and to make
sure about the risks of entering any collateral damage in the fix.
 Debugging

Debugging Process: Steps involved in debugging are:

• 4. Prove the Analysis: Once you are done analyzing the
original bug, you need to find a few more errors that may
appear on the application. This step is about writing automated
tests for these areas with the help of a test framework.
• 5. Cover Lateral Damage: In this stage, you need to create or
gather all the unit tests for the code where you are going to
make changes. Now, if you run these unit tests, they all should
pass.
• 6. Fix & Validate: The final stage is the fix all the errors and run
all the test scripts to check if they all pass.
 Debugging

Debugging Tools:
Here is a list of some of the widely used debuggers:
• Radare2
• WinDbg
• Valgrind
 Level of Software Testing

The activities of testing can be divided into the following basic steps:

• Planning and Control

• Analysis and Design
• Implementation and Execution
• Evaluating exit criteria and Reporting
• Test Closure activities
 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.
Types of Software Testing
 Types of Software Testing

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:
GALGOTIAS UNIVERSITY

THANK YOU