software Testing

1. Software testing

2. Objectives
 To discuss the distinctions between validation
testing and defect testing
 To describe the principles of system and
component testing
 To describe strategies for generating system test
cases
 To understand the essential characteristics of tool
used for test automation

3. Difference between Bug,
Defect, Error, Fault & Failure
 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.

4. The testing process
 Component testing
 Testing of individual program components;
 Usually the responsibility of the component developer (except
sometimes for critical systems);
 Tests are derived from the developer’s experience.
 System testing
 Testing of groups of components integrated to create a system
or sub-system;
 The responsibility of an independent testing team;
 Tests are based on a system specification.

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

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

7. 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:
1. Lack of resources
2. An invalid step
3. Inappropriate data definition

8. 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:

9. Bug Vs. Defect Vs. Error Vs. Fault Vs.
Failure
Comparison
basis
Bug Defect Error Fault Failure
Definition
It is an informal
name specified
to the defect.
The Defect is
the difference
between the
actual outcomes
and expected
outputs.
An Error is a
mistake made in
the code; that's
why we cannot
execute or
compile code.
The Fault is a
state that
causes the
software to fail
to accomplish its
essential
function.
If the software
has lots of
defects, it leads
to failure or
causes failure.
Raised by
The Test
Engineers
submit the bug.
The Testers
identify the
defect. And it
was also solved
by the developer
in the
development
phase or stage.
The Developers
and automation
test engineers
raise the error.
Human
mistakes cause
fault.
The failure finds
by the manual
test engineer
through the
development
cycle.

10. Test Oracles
 Test Oracle is a mechanism, different from the program
itself, that can be used to test the accuracy of a program’s
output for test cases. Conceptually, we can consider testing
a process in which test cases are given for testing and the
program under test. The output of the two then compares
to determine whether the program behaves correctly for
test cases. This is shown in figure.

11.  Testing oracles are required for testing. Ideally, we
want an automated oracle, which always gives the
correct answer. However, often oracles are human
beings, who mostly calculate by hand what the output
of the program should be. As it is often very difficult to
determine whether the behavior corresponds to the
expected behavior, our “human deities” may make
mistakes. Consequently, when there is a discrepancy,
between the program and the result, we must verify
the result produced by the oracle before declaring that
there is a defect in the result.

12.  The human oracles typically use the program’s
specifications to decide what the correct behavior of
the program should be. To help oracle determine the
correct behavior, it is important that the behavior of the
system or component is explicitly specified and the
specification itself be error-free. In other words actually
specify the true and correct behavior.
 There are some systems where oracles are
automatically generated from the specifications of
programs or modules. With such oracles, we are
assured that the output of the oracle conforms to the
specifications. However, even this approach does not
solve all our problems, as there is a possibility of
errors in specifications. As a result, a divine generated
from the specifications will correct the result if the
specifications are correct, and this specification will not

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

14.  It is an in-details document that contains all possible
inputs (positive as well as negative) and the
navigation steps, which are used for the test
execution process. Writing of test cases is a one-time
attempt that can be used in the future at the time of
regression testing.
 Test case gives detailed information about testing
strategy, testing process, preconditions, and expected
output. These are executed during the testing process
to check whether the software application is
performing the task for that it was developed or not.
 Test case helps the tester in defect reporting by
linking defect with test case ID. Detailed test case
documentation works as a full proof guard for the
testing team because if developer missed something,

15. When do we write a test case
 When the customer gives the business needs then,
the developer starts developing and says that they
need 3.5 months to build this product.
 And In the meantime, the testing team will start
writing the test cases.
 Once it is done, it will send it to the Test Lead for the
review process.
 And when the developers finish developing the
product, it is handed over to the testing team.
 The test engineers never look at the requirement
while testing the product document because testing
is constant and does not depends on the mood of

16. Why we write the test cases?
 To require consistency in the test case execution: we will see the
test case and start testing the application.
 To make sure a better test coverage: for this, we should cover all
possible scenarios and document it, so that we need not remember all
the scenarios again and again.
 It depends on the process rather than on a person: A test engineer
has tested an application during the first release, second release, and
left the company at the time of third release. As the test engineer
understood a module and tested the application thoroughly by deriving
many values. If the person is not there for the third release, it becomes
difficult for the new person. Hence all the derived values are
documented so that it can be used in the future.
 To avoid giving training for every new test engineer on the
product: When the test engineer leaves, he/she leaves with a lot of
knowledge and scenarios. Those scenarios should be documented so
that the new test engineer can test with the given scenarios and also
can write the new scenarios.

17. Equivalence Partitioning
Method
 Equivalence Partitioning Method is also known
as Equivalence class partitioning (ECP). It is a
software testing technique or black-box testing
that divides input domain into classes of data,
and with the help of these classes of data, test
cases can be derived. An ideal test case identifies
class of error that might require many arbitrary
test cases to be executed before general error is
observed.
 In equivalence partitioning, equivalence classes
are evaluated for given input conditions.
Whenever any input is given, then type of input
condition is checked, then for this input

18. Guidelines for Equivalence
Partitioning :
 If the range condition is given as an input, then
one valid and two invalid equivalence classes are
defined.
 If a specific value is given as input, then one valid
and two invalid equivalence classes are defined.
 If a member of set is given as an input, then one
valid and one invalid equivalence class is
defined.
 If Boolean no. is given as an input condition, then
one valid and one invalid equivalence class is
defined.

20. Software Testing – Boundary
Value Analysis
 Functional testing is a type of software testing in
which the system is tested against the functional
requirements of the system. It is conducted to
ensure that the requirements are properly
satisfied by the application. Functional testing
verifies that each function of the software
application works in conformance with the
requirement and specification. Boundary Value
Analysis(BVA) is one of the functional testings.

21. Boundary Value Analysis
 Boundary Value Analysis is based on testing the
boundary values of valid and invalid partitions.
The behavior at the edge of the equivalence
partition is more likely to be incorrect than the
behavior within the partition, so boundaries are
an area where testing is likely to yield defects.
 It checks for the input values near the boundary
that have a higher chance of error. Every partition
has its maximum and minimum values and these
maximum and minimum values are the boundary
values of a partition.

22.  A boundary value for a valid partition is a valid
boundary value.
 A boundary value for an invalid partition is an
invalid boundary value.
For each variable we check-
 Minimum value.
 Just above the minimum.
 Nominal Value.
 Just below Max value.
 Max value.

23. White Box Testing
 The box testing approach of software testing consists of black box testing and
white box testing. We are discussing here white box testing which also known
as glass box is testing, structural testing, clear box testing, open box
testing and transparent box testing. It tests internal coding and
infrastructure of a software focus on checking of predefined inputs against
expected and desired outputs. It is based on inner workings of an application
and revolves around internal structure testing. In this type of testing
programming skills are required to design test cases. 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.
 The term 'white box' is used because of the internal perspective of the
system. The clear box or white box or transparent box name denote the ability
to see through the software's outer shell into its inner workings.
 Developers do white box testing. In this, the developer will test every line of
the code of the program. The developers perform the White-box testing and
then send the application or the software to the testing team, where they will
perform the black box testing and verify the application along with the
requirements and identify the bugs and sends it to the developer.
 The developer fixes the bugs and does one round of white box testing and
sends it to the testing team. Here, fixing the bugs implies that the bug is

24. The white box testing contains various
tests, which are as follows:
 Path testing
 Loop testing
 Condition testing
 Testing based on the memory perspective
 Test performance of the program

25. Path testing
 In the path testing, we will write the flow graphs and
test all independent paths. Here writing the flow graph
implies that flow graphs are representing the flow of
the program and also show how every program is
added with one another as we can see in the below
image:
And test all the independent paths implies that suppose a path from
main() to function G, first set the parameters and test if the program is
correct in that particular path, and in the same way test all other paths
and fix the bugs.

26. Reasons for white box testing
 It identifies internal security holes.
 To check the way of input inside the code.
 Check the functionality of conditional loops.
 To test function, object, and statement at an
individual level.

27. Advantages of White box
testing
 White box testing optimizes code so hidden errors
can be identified.
 Test cases of white box testing can be easily
automated.
 This testing is more thorough than other testing
approaches as it covers all code paths.
 It can be started in the SDLC phase even without
GUI.

28. testing
 White box testing is too much time consuming
when it comes to large-scale programming
applications.
 White box testing is much expensive and
complex.
 It can lead to production error because it is not
detailed by the developers.
 White box testing needs professional
programmers who have a detailed knowledge
and understanding of programming language and
implementation.

29. Difference 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 understanding of the
programming languages.
To perform BBT, there is no
need to have an understanding
of the programming languages.
In this, we will look into the
source code and test the logic
of the code.
In this, we will verify the
functionality of the application
based on the requirement
specification.
In this, the developer should
know about the internal design
of the code.
In this, there is no need to know
about the internal design of the
code.

30. Testing phases

31. Defect testing
 The goal of defect testing is to discover defects in
programs
 A successful defect test is a test which causes a
program to behave in an anomalous way
 Tests show the presence not the absence of
defects

32. Testing process goals
 Validation testing
 To demonstrate to the developer and the system customer that
the software meets its requirements;
 A successful test shows that the system operates as intended.
 Defect testing
 To discover faults or defects in the software where its
behaviour is incorrect or not in conformance with its
specification;
 A successful test is a test that makes the system perform
incorrectly and so exposes a defect in the system.

33. The software testing process

34. Testing policies
 Only exhaustive testing can show a program is free
from defects. However, exhaustive testing is
impossible,
 Testing policies define the approach to be used in
selecting system tests:
 All functions accessed through menus should be tested;
 Combinations of functions accessed through the same menu
should be tested;
 Where user input is required, all functions must be tested with
correct and incorrect input.

35. System testing
 Involves integrating components to create a
system or sub-system.
 May involve testing an increment to be delivered
to the customer.
 Two phases:
 Integration testing - the test team have access to
the system source code. The system is tested as
components are integrated.
 Release testing - the test team test the complete
system to be delivered as a black-box.

36. Integration testing
 Involves building a system from its components and
testing it for problems that arise from component
interactions.
 Top-down integration
 Develop the skeleton of the system and populate it with
components.
 Bottom-up integration
 Integrate infrastructure components then add functional
components.
 To simplify error localisation, systems should be
incrementally integrated.

37. Incremental integration testing
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
T
estsequence1 T
estsequence2 T
estsequence3

38. Testing approaches
 Architectural validation
 Top-down integration testing is better at discovering errors in
the system architecture.
 System demonstration
 Top-down integration testing allows a limited demonstration at
an early stage in the development.
 Test implementation
 Often easier with bottom-up integration testing.
 Test observation
 Problems with both approaches. Extra code may be required
to observe tests.

39. Release testing
 The process of testing a release of a system that
will be distributed to customers.
 Primary goal is to increase the supplier’s
confidence that the system meets its
requirements.
 Release testing is usually black-box or functional
testing
 Based on the system specification only;
 Testers do not have knowledge of the system
implementation.

40. Black-box testing

41. Testing guidelines
 Testing guidelines are hints for the testing team to
help them choose tests that will reveal defects in the
system
 Choose inputs that force the system to generate all error
messages;
 Design inputs that cause buffers to overflow;
 Repeat the same input or input series several times;
 Force invalid outputs to be generated;
 Force computation results to be too large or too small.

42. Testing scenario
A student in Scotland is studyingA merican Historyand has been asked to write a paper
on Ô
Frontier mentalit y in the American West from 1840 to 1880Õ.To do this, she needs to
find sources from a range o f libraries. She logs on to the LIBSYS system and uses the
search facilit y to discover if she can acce ss original documents from that time. She
discovers sources inva rious US university libraries and down loads copies of some of
these. However, for one document, she needs to have confirmation from her university
that she is a genu ine student and that use is for non- commercialpurposes. The s tudent
then uses the facility in LIBSYS that can request such permis sion and registers her
request. If granted, the document will be downloaded to the registered libraryÕ
s server
and printed for her. She receives a message from LIBSYS telli ng her that she will receive
an e-mail message whenth e printed document is available for collection.

43. System tests
1. Test the login mechanism using correct and incorrect logins to check
that valid users are accepted and invalid users are rejected.
2. Test the search facility using different queries against known sources to
check that the search mechanism is actually finding documents.
3. Test the system presentation facility to check that information about
documents is displayed properly.
4. Test the mechanismto request permission for downloading.
5. Test the e-mail response indicating that the downloaded document is
available.

44. Use cases
 Use cases can be a basis for deriving the tests
for a system. They help identify operations to be
tested and help design the required test cases.
 From an associated sequence diagram, the
inputs and outputs to be created for the tests can
be identified.

45. Collect weather data sequence chart

46. Performance testing
 Part of release testing may involve testing the
emergent properties of a system, such as
performance and reliability.
 Performance tests usually involve planning a
series of tests where the load is steadily
increased until the system performance becomes
unacceptable.

47. Stress testing
 Exercises the system beyond its maximum design
load. Stressing the system often causes defects to
come to light.
 Stressing the system test failure behaviour.. Systems
should not fail catastrophically. Stress testing checks
for unacceptable loss of service or data.
 Stress testing is particularly relevant to distributed
systems that can exhibit severe degradation as a
network becomes overloaded.

48. Key points
 Testing can show the presence of faults in a system; it cannot
prove there are no remaining faults.
 Component developers are responsible for component testing;
system testing is the responsibility of a separate team.
 Integration testing is testing increments of the system; release
testing involves testing a system to be released to a customer.
 Use experience and guidelines to design test cases in defect
testing.