SOFTWARE TESTING

 Software testing is the process of evaluating and

verifying that a software product or application.
 The benefits of testing include preventing bugs,
reducing development costs and improving
performance.
AUTOMATION IN SOFTWARE TESTING
“Automated testing is a software testing technique
that automates the process of validating the functionality
of software and ensures it meets requirements before
being released into production. With automated testing, an
organization can run specific software tests at a faster
pace without human testers.”
 MANUAL TESTING
 Manual testing is testing, where the tester can test the
application without any knowledge of any
programming language.
 In manual testing, the test engineer tests the
application like a user to make it bug-free or stable.
 Manual test engineers always search for the fault or
bugs in the product before the product released in the
market, yet delivered software still has defects.
 And there is a chance that the final software product
still has a defect or does not meet the customer
requirement, even the manual test engineer do their
best.
 AUTOMATION TESTING
 Automation testing is a process of changing any
manual test case into the test scripts by using
automation testing tools, and scripting or
programming language is called automation.
 Automation testing is used to increase the efficiency,
effectiveness, and coverage of Software testing.
 Automation test engineer uses automation testing tools
to automate the manual design test cases without any
human interference.
 And these testing tools can control the execution of
tests, access the test data, and compares the actual
result against the expected result.
 WHY DO WE TEST SOFTWARE
Benefits Of Software Testing
 Saves You Money.
 Inspires Client Confidence.
 Maintains Great User Experience.
 Brings In More Profit.
 Boosts Customer Satisfaction.
 Promotes Organization, Productivity, and Efficiency.
 BLACK BOX TESTING

Black-box testing is a type of software testing in

which the tester is not concerned with the internal
knowledge or implementation details of the software, but
rather focuses on validating the functionality based on
the provided specifications or requirements.
Black box testing can be done in the following ways:
1. Syntax-Driven Testing
 Syntactically represented by some language
 For example- compilers, language that can be represented by
context-free grammar
 The test cases are generated so that each grammar rule is used
at least once.
2. Equivalence partitioning
 Instead of giving all of input separately we can group them
and test only one input of each group.
 The idea is to partition the input domain of the system into
several equivalence classes such that each member of the
class works similarly,
 if a test case in one class results in some error, other members
of the class would also result in the same error.
Techniques for performing a black box evaluation include:
1. Equivalence Class Testing
2. Boundary Value Evaluation
3. Decision Table Testing
4. State Transition Evaluation
5. Error Checking
Equivalence Class Testing:
 An application may follow the same control flow for certain types of
inputs.
 For example, an application that should only be accessible to adults
may terminate if a user enters an age under 18
Boundary Value Evaluation:
 Boundary values are inputs where an application’s changes from one
control flow to another.
 For example, the ages 17 and 18 are boundary values for adulthood
since a 17 year old may be rejected by an application, while an 18
year old would be accepted. Boundary value evaluation tests these
inputs to ensure that the system is properly handling these edge cases.
Decision Table Testing:
 An application may be designed to make decisions based on a
combination of inputs.
 For example, users over the age of 18 and living within a particular area
may be able to access an application. Decision table testing involves
enumerating each combination of inputs and its expected outcomes and
developing a test case to validate each combination.
State Transition Evaluation:
 An application may be designed to change state under certain conditions,
 For example, locking a user’s account after a certain number of failed
authentication attempts. State transition evaluation involves identifying
these situations and developing test cases to validate them.
Error Checking:
 This form of evaluation tests for common errors that a developer may
have made when creating an application.
 For example, testers may check to see if developers properly handled an
input of zero in a numeric field or restricted the character set for a name
to the letters and symbols that can appear in a name.
 TYPES OF BLACK BOX TESTING
Black box testing can be designed to accomplish a few different goals
 Functional Testing
 Non-Functional Testing
 Regression Testing
Functional Testing:
 Functional testing is intended to validate that an application does what
it is supposed to do.
 For example, functional tests may test an application’s authentication
mechanism to check that legitimate users can authenticate successfully
while invalid login attempts are rejected.
 Common types of functional testing include
 sanity checks - basic test result of a calculation can possibly be true
 integration testing - problems to verify that they work together as
designed
 system testing - examines every component of an application to make
sure that they work as a complete and unified whole
Non-Functional Testing:
 Non-functional testing evaluates how well an application
performs its core functions.
 Examples of tests include
 Performance - well-written performance tests often catch problems
before they become evident to users.
 usability - Usability testing measures the quality of a user’s
experience.
 Scalability.
 security testing.
Regression Testing:
 Regression testing is designed to ensure that a change to an
application does not break functionality.
 For example, regression testing should be performed after
patching a vulnerability in an application to ensure the patch has
not caused the application to fail functional or non-functional
tests.
 WHITE BOX TESTING
 As opposed to black box testing, white box
evaluations are performed with full knowledge of an
application’s internals, including access to the source
code.
 White box testing offers better test coverage than
black box testing since all code can be evaluated.
 it requires expertise with the language in which the
code was developed.
• also known as glass box is testing, structural
testing, clear box testing, open box testing
and transparent box testing.
• The primary goal of white box testing is to
focus on the flow of inputs and outputs through
the software and strengthening the security of
the software.
 DIFFERENCES BETWEEN WHITE BOX TESTING
AND BLACK BOX TESTING:
WHITE-BOX TESTING BLACK BOX TESTING

The developers can perform white box testing. The test engineers perform the black box
testing.

To perform WBT, we should have an To perform BBT, there is no need to have an

understanding of the programming languages. understanding of the programming languages.

In this, we will look into the source code and In this, we will verify the functionality of the
test the logic of the code. application based on the requirement
specification.

In this, the developer should know about the In this, there is no need to know about the
internal design of the code. internal design of the code.
CORRECTNESS AND VERIFICATION
 Correctness is an integral part of software testing.
 The focus of software testing is to run the candidate
program on selected input data and check whether the
program behaves correctly with respect to its
specification.
 The behavior of the program can be analyzed only if
we know what is a correct behavior
 Hence the skills that we develop as we try to prove
program correctness enable us to be better/more
effective testers.
ERROR, FAULT & FAILURE
 ERROR
The Problem in code leads to errors
A mistake can occur due to the developer's
coding
 Misunderstood the requirement
or the requirement was not defined
correctly.
The developers use the term error.
 DEFECT
 When the application is not working as per the
requirement is knows as defects.
 In other words, we can say that the bug announced by
the programmer and inside the code is called a Defect.
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.
 FAULT
 The fault may occur in software because it has not
added the code for fault tolerance, making an
application act up.

REASONS:

Lack of resources
An invalid step
Inappropriate data definition
 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.
Thank you