Unit Lecture

4 19
No No
Topic Performance Testing: Load Testing, Stress Testing, Volume Testing
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Define Load Testing, Stress Testing, Volume Testing K2
LO2 Analyse the factors of test design. K2
LO3 Find out the requirement of testing K3

1. Overview of testing activities: The test plan provides an overview of the testing activities
and where to start and stop the work.
2. Provides timeline: The test plan helps to create the timeline for the testing activities based on
the number of hours and the workers needed.
3. Helps to estimate resources: The test plan helps to create an estimate of the number of
resources needed to finish the work.
4. Serves as a blueprint: The test plan serves as a blueprint for all the testing activities, it has
every detail from beginning to end.
5. Helps to identify solutions: A test plan helps the team members They consider the project’s
challenges and identify the solutions.
6. Serves as a rulebook: The test plan serves as a rulebook for following rules when the project
is completed phase by phase.
Test Design
Software testing, like all processes, is an investment and is considered successful when it
provides an ROI. To ensure, we are getting the ROI; it has to be tracked too. One factor that
will create an impact on the ROI, is the effectiveness of the test strategy. An effective test
design will largely dictate the effectiveness of the testing strategy, thus the ROI from the
software testing process.

Test design factors:

1. Positive
2. Negative
3. User Interface
4. Usability
5. Performance
6. Security
7. Reliability
8. Compatibility

Positive: Testing the software in the positive way, that is to check whether the system is functioning
properly with correct inputs. For example, testing an number field with integers.
Negative: Testing the software in a negative way, that is to check whether the system fails on
giving wrong inputs. For example, testing a number field with alphabets, special characters etc.
User Interface: Testing the user interaction with the system. For example testing the links, images,
alignment, padding, font, colour, labels, navigation, button etc
Usability : Testing the efficiency and accuracy of the software, that is to determine whether the user
is able to perform the specified task. Successful login/registration to a site by a user is a perfect
example.
Performance: Testing the performance of the system under a particular workload. Load and stress
testing is an example for performance testing ie, testing a system by running multiple applications,
testing with maximum number of users etc
Security: Testing the security of the system ie, to determine whether the data is protected or not.
For example logged out users, by copy pasting the URL or by any other method, should not be able
to access the pages which are accessible only for logged in users.
Security testing includes Authentication, Authorization, Confidentiality, Integrity, Non-repudiation
Reliability: Testing the consistency of the system, that is to determine whether the system is
functioning properly in all conditions repeatedly. For example, the system will produce the same
result on doing the repeated action.
Compatibility: Testing the compatibility of the system on different environments that is to ensure
the functioning of the system on different browsers, hardware and operating system platforms. For
example testing the product in different platforms like Windows, Linux, Mac etc and on different
browsers like Mozilla Firefox, Chrome, Safari, IE etc.
Testable requirements
Testable requirements are essential to ensure that the software meets the needs of the business.
Testing involves verifying that each requirement has been met by the software. It's important to
develop tests based on the intended behavior described and not on the behavior delivered.
Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
1 _____________serves as a blue print. Testcase K1
Checking of data protection is done through
1. Availability
2. Security
2 2 K2
3. Reliability
4. Compatability

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 List out the design factors of test case design. 2 3 K1
2 What are the objectives of Test design? 5 3 K1

Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 232-270
Unit Lecture
4 20
No No
Topic Fail-Over Testing, Recovery Testing, Configuration Testing
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Describe Fail-Over Testing, Recovery Testing, Configuration K2
Testing
LO2 Model the test design result K2

teration. In the event

that this is not the
case, the test case will
be put through an
additional review,
which can be
accomplished by
shifting it to the
review stage.
Every time a test case
is run, it is possible to
make one revision to
it.
Former State Now
Deprecated A test
case that is no longer
relevant could be
shifted to a
deprecated state. In
an ideal scenario, the
test case should be
examined
to determine whether
or not it continues to
exist if it has not been
run for at least a
year. Because of the
factors listed below, a
test case might
become irrelevant
over
the course of time.
First, the functionality
of the system being
tested has undergone
significant revisions,
and second, an
insufficient amount of
test case maintenance
has led to an outdated
test case. Second,
when an older test
case is changed, it's
possible that some of
the requirements of
the first test case will
no longer be met.
Third, as the
circumstances evolve
over time, the
reusability of test
instances has a
tendency to
deteriorate. This is
particularly true of
test cases that were
not
developed with
sufficient
consideration given to
the possibility of
reuse. In
conclusion, test cases
may be haphazardly
brought forward for a
considerable
amount of time after
the original
justifications for them
have vanished. It's
possible
that nobody knows
the reason a particular
test case was created
in the first place,
but that doesn't stop
people from using it.
After a test factory
has been established,
a test manager is able
to develop a test
suite with the
assistance of a test
suite template. In
order to combine test
cases for
the purpose of
evaluating a specific
version, a test suite
schema is utilized, as
can
be seen in Table 11.7.
A test suite ID, a title,
an objective, and a
collection of test
cases that need to be
handled by the test
suite are all necessary
components of the
structure. Additionally,
one determines the
individual test cases
that will need to be
carried out (test
rounds 1, 2, 3, and/or
regression), as well as
the specifications that
each test case must
meet. The plan is to
compile a new
project's test suite
from a
MODELING A TEST DESIGN PROCESS
Create State It is the creator of a test case, also referred to as the owner or creator, who is
responsible for initiating the creation of the test case and putting it into this original condition. The
following required variables affiliated with the test case are initialized by the creator:
requirement_ids, tc_id, tc_title, originator_group, creator, and test_category. It is anticipated that
the test case will validate the requirements that are listed in the field labeled "requirement_ids." The
group that first recognized the need for the exam is known as the originator group. By filling out
the eng_assigned column, the creator of the test case has the ability to allocate it to a particular test
engineer, including himself, and to transition the test case from the create state to the draft state.

Draft State The test group, also known as the system test squad, is the entity in charge of
maintaining this condition. During this phase of the process, the designated test engineer is
responsible for entering the following data: tc_author, objective, setup, test_steps, cleaning,
pf_criteria, candidate_for_automation, and automation_priority. After the creator of the test case
has finished filling out all of the required sections, the test engineer may transfer the test case to the
creator so that the creator can run through the test case. The test case will remain in this condition
until the developer examines it and moves through each step. After that, the creator has the ability
to change the status of the document from the draft state to the review state by entering all of the
names of the approvers into the section labeled "approver_names."

States That Were Reviewed and Eliminated The person who initially developed the test scenario is
also the proprietor of the evaluation state. The proprietor extends an invitation to the test engineers
and developers to look over the test case and validate it. They check to see that the test case can be
run, and that the conditions for passing or failing are articulated in detail. In the event that any of
the fields require an update, action items pertaining to the test scenario are formulated. Action items
resulting from a review conference are entered into the review_actions section, and the owner of the
test case is responsible for carrying out the action items in order to implement modifications. After
receiving positive feedback from all of the evaluators, the test case is moved into the released stage.
In the event that the evaluators come to the conclusion that this is not a legitimate test case or that it
cannot be executed, the test case will be shifted to the deleted state. In order to remove a test case,
there must first be a review action item that states "delete this test case." States That Are Both
Released and Up to Date When a test case is in the published state, it is in a state where it is ready
to be run, and it is added to a test suite. On the other hand, a test case that is in the update state
indicates that it is currently undergoing one or more of the following processes: having its
reusability improved; having its pass–fail parameters fine-tuned; and/or having the specific test
procedure fixed. For instance, rather than hard coding the data values, a repeatable test case ought
to make use of parameters instead. In addition, a test case needs to be changed so that it can be
adapted to changes in the surroundings or the functionality of the system. By taking a test case
through the released–update cycle a limited number of times, one can improve the reproducibility of
the test case, thereby making it easier for other people to rapidly comprehend, borrow, and reuse it.
In addition to this, this lays the groundwork and justifies the need for the test case to be
mechanized. It is important for a test scenario to be platform agnostic. After implementing a remedy
for a bug, a test engineer might return a test case to its previously released state if an upgrade only
introduces a minor

MODELING TEST
RESULTS
After a test case has
been designed or
selected, its execution
status is reset to its
original state, which is
unverified. This
happens
automatically. The
test case
outcome will be
moved into the invalid
state if the test case is
not legitimate for the
software version that
is currently being
tested. In the
condition that has not
been
tested, the identifier
of the test suite is
recorded in a variable
that is called
test_suite_id. Once the
execution of a test
case has begun, the
status of the test
outcome may
transition into one of
the following states:
succeeded, failed,
invalid,
or delayed. If the test
case processing is
finished and it meets
the pass criteria, a
test engineer may
transfer the test case
outcome from the
untested state to the
passed state. This
occurs when the test
case is considered to
have satisfied the
pass
criteria.
A test engineer will
move the test result
from the untested
state to the failed
state if
the test execution is
finished and has
fulfilled the fail
criteria. They will then
correlate the defect
with the test case by
initializing the
defect_ids field and
transfer the test result
to the failed state.
When a new build is
obtained that
contains a remedy for
the bug, the test case
needs to be rerun so
that the change
can be verified. In the
event that the
reexecution is finished
and the conditions for
passing the test are
met, the test outcome
will be changed to the
passed state.
If it is not feasible to
completely carry out
the test case's
instructions, the
outcome
of the test is set to the
stopped state. The
defect number that
prevents the test case
from being executed
is, if it is known,
entered into the
defect_ids section of
the
database. When a new
build that addresses a
stalled test case is
obtained, the test
case could potentially
be reexecuted again.
The test result is
considered to have
passed when it is
shifted into the passed
state provided that
the processing has
been
MODELING TEST
RESULTS
After a test case has
been designed or
selected, its execution
status is reset to its
original state, which is
unverified. This
happens
automatically. The
test case
outcome will be
moved into the invalid
state if the test case is
not legitimate for the
software version that
is currently being
tested. In the
condition that has not
been
tested, the identifier
of the test suite is
recorded in a variable
that is called
test_suite_id. Once the
execution of a test
case has begun, the
status of the test
outcome may
transition into one of
the following states:
succeeded, failed,
invalid,
or delayed. If the test
case processing is
finished and it meets
the pass criteria, a
test engineer may
transfer the test case
outcome from the
untested state to the
passed state. This
occurs when the test
case is considered to
have satisfied the
pass
criteria.
A test engineer will
move the test result
from the untested
state to the failed
state if
the test execution is
finished and has
fulfilled the fail
criteria. They will then
correlate the defect
with the test case by
initializing the
defect_ids field and
transfer the test result
to the failed state.
When a new build is
obtained that
contains a remedy for
the bug, the test case
needs to be rerun so
that the change
can be verified. In the
event that the
reexecution is finished
and the conditions for
passing the test are
met, the test outcome
will be changed to the
passed state.
If it is not feasible to
completely carry out
the test case's
instructions, the
outcome
of the test is set to the
stopped state. The
defect number that
prevents the test case
from being executed
is, if it is known,
entered into the
defect_ids section of
the
database. When a new
build that addresses a
stalled test case is
obtained, the test
case could potentially
be reexecuted again.
The test result is
considered to have
passed when it is
shifted into the passed
state provided that
the processing has
been
MODELING TEST RESULTS
After a test case has been designed or selected, its execution status is reset to its original state,
which is unverified. This happens automatically. The test case outcome will be moved into the
invalid state if the test case is not legitimate for the software version that is currently being tested.
In the condition that has not been tested, the identifier of the test suite is recorded in a variable that
is called test_suite_id. Once the execution of a test case has begun, the status of the test outcome
may transition into one of the following states: succeeded, failed, invalid, or delayed. If the test case
processing is finished and it meets the pass criteria, a test engineer may transfer the test case
outcome from the untested state to the passed state. This occurs when the test case is considered to
have satisfied the pass criteria. A test engineer will move the test result from the untested state to
the failed state if the test execution is finished and has fulfilled the fail criteria. They will then
correlate the defect with the test case by initializing the defect_ids field and transfer the test result to
the failed state. When a new build is obtained that contains a remedy for the bug, the test case needs
to be rerun so that the change can be verified. In the event that the reexecution is finished and the
conditions for passing the test are met, the test outcome will be changed to the passed state. If it is
not feasible to completely carry out the test case's instructions, the outcome of the test is set to the
stopped state. The defect number that prevents the test case from being executed is, if it is known,
entered into the defect_ids section of the database. When a new build that addresses a stalled test
case is obtained, the test case could potentially be reexecuted again. The test result is considered to
have passed when it is shifted into the passed state provided that the processing has been

reate state, to when it

is considered to be
useable, which is the
released state. This
information is referred
to as the average time
spent in the design of
a test case. This
measure is helpful in
allocating time to the
test preparation
activity in a
succeeding
test project, which is
why it is being
discussed here. As a
result, it is beneficial
to
the preparation of the
exam.
Number of Available
Test (NAT) Cases: This
refers to the total
number of test
scenarios that have
been completed and
published by
previously completed
initiatives. For the
purpose of the
ongoing testing
endeavor, we have
chosen to
perform regression
testing on some of
these test scenarios.
The number of test
cases that are part of
a test package and
are prepared for
implementation
before the beginning
of system testing is
referred to as the
number
of planned test cases,
or NPT cases.
This measure can be
helpful when planning
the implementation of
tests. As the
testing progresses,
new test cases that
weren't originally
intended might need
to be
developed. When
compared to NPT, the
significant increase in
the number of new
test instances
suggests that the
original planning was
inaccurate.
A Test Suite's (CTS)
Level of Coverage:
This measure
calculates the
proportion of
all requirements that
are validated by the
full set of test cases or
by a specific
number of those
instances.
The critical test suite,
or CTS, is a
measurement of the
number of test cases
that
need to be chosen or
developed in order to
have adequate
coverage of system
specifications.
The objectives of the
test case design
effectiveness metric
are to (i) quantify the
"defect revealing
ability" of the test
suite and (ii) use the
metric to enhance the
test
create state, to when it is considered to be useable, which is the released state. This information is
referred to as the average time spent in the design of a test case. This measure is helpful in
allocating time to the test preparation activity in a succeeding test project, which is why it is being
discussed here. As a result, it is beneficial to the preparation of the exam. Number of Available Test
(NAT) Cases: This refers to the total number of test scenarios that have been completed and
published by previously completed initiatives. For the purpose of the ongoing testing endeavor, we
have chosen to perform regression testing on some of these test scenarios. The number of test cases
that are part of a test package and are prepared for implementation before the beginning of system
testing is referred to as the number of planned test cases, or NPT cases. This measure can be helpful
when planning the implementation of tests. As the testing progresses, new test cases that weren't
originally intended might need to be developed. When compared to NPT, the significant increase in
the number of new test instances suggests that the original planning was inaccurate. A Test Suite's
(CTS) Level of Coverage: This measure calculates the proportion of all requirements that are
validated by the full set of test cases or by a specific number of those instances. The critical test
suite, or CTS, is a measurement of the number of test cases that need to be chosen or developed in
order to have adequate coverage of system specifications. The objectives of the test case design
effectiveness metric are to (i) quantify the "defect revealing ability" of the test suite and (ii) use the
metric to enhance the test

design process. Both

of these objectives are
intended to be
accomplished by using
the metric. Whenever
scheduled test cases
are carried out, it is
possible for defects
to become apparent
during system-level
testing. During
testing, in addition to
these
defects, new defects
are discovered that
had not been
prepared for by any of
the
test scenarios. These
newly discovered
flaws require the
development of brand
new
test cases, which are
referred to as test
case escaped. (TCE).
Test failures are
usually the result of
flaws in the procedure
used to create the
tests. This occurs as a
result of the test
engineers coming up
with novel concepts
while they are
carrying
out the scheduled test
cases. The test case
design yield,
abbreviated as TCDY,
is a
metric that is
frequently used in the
business to measure
the effectiveness of
test
case design
design process. Both of these objectives are intended to be accomplished by using the metric.
Whenever scheduled test cases are carried out, it is possible for defects to become apparent during
system-level testing. During testing, in addition to these defects, new defects are discovered that
had not been prepared for by any of the test scenarios. These newly discovered flaws require the
development of brand new test cases, which are referred to as test case escaped. (TCE). Test
failures are usually the result of flaws in the procedure used to create the tests. This occurs as a
result of the test engineers coming up with novel concepts while they are carrying out the scheduled
test cases. The test case design yield, abbreviated as TCDY, is a metric that is frequently used in the
business to measure the effectiveness of test case design.

MODELING A TEST
DESIGN PROCESS
Create State It is the
creator of a test case,
also referred to as the
owner or creator,
who is responsible for
initiating the creation
of the test case and
putting it into this
original condition. The
following required
variables affiliated
with the test case are
initialized by the
creator:
requirement_ids, tc_id,
tc_title,
originator_group,
creator,
and test_category. It
is anticipated that the
test case will validate
the requirements
that are listed in the
field labeled
"requirement_ids."
The group that first
recognized the need
for the exam is known
as the originator
group. By filling out
the eng_assigned
column, the creator of
the test case has the
ability to allocate it to
a particular test
engineer, including
himself, and to
transition the test
case from the
create state to the
draft state.
Draft State The test
group, also known as
the system test
squad, is the entity in
charge of maintaining
this condition. During
this phase of the
process, the
designated test
engineer is
responsible for
entering the following
data: tc_author,
objective, setup,
test_steps, cleaning,
pf_criteria,
candidate_for_automa
tion, and
automation_priority.
After the creator of
the test case has
finished filling out all
of
the required sections,
the test engineer may
transfer the test case
to the creator so
that the creator can
run through the test
case. The test case
will remain in this
condition until the
developer examines it
and moves through
each step. After that,
the creator has the
ability to change the
status of the
document from the
draft state
to the review state by
entering all of the
names of the
approvers into the
section
labeled
"approver_names."
States That Were
Reviewed and
Eliminated The person
who initially
developed the
test scenario is also
the proprietor of the
evaluation state. The
proprietor extends an
invitation to the test
engineers and
developers to look
over the test case and
alteration. In the
event that this is not
the case, the test case
will be put through an
additional review,
which can be
accomplished by
shifting it to the
review stage.
Every time a test case
is run, it is possible to
make one revision to
it.
Former State Now
Deprecated A test
case that is no longer
relevant could be
shifted to a
deprecated state. In
an ideal scenario, the
test case should be
examined
to determine whether
or not it continues to
exist if it has not been
run for at least a
year. Because of the
factors listed below, a
test case might
become irrelevant
over
the course of time.
First, the functionality
of the system being
tested has undergone
significant revisions,
and second, an
insufficient amount of
test case maintenance
has led to an outdated
test case. Second,
when an older test
case is changed, it's
possible that some of
the requirements of
the first test case will
no longer be met.
Third, as the
circumstances evolve
over time, the
reusability of test
instances has a
tendency to
deteriorate. This is
particularly true of
test cases that were
not
developed with
sufficient
consideration given to
the possibility of
reuse. In
conclusion, test cases
may be haphazardly
brought forward for a
considerable
amount of time after
the original
justifications for them
have vanished. It's
possible
that nobody knows
the reason a particular
test case was created
in the first place,
but that doesn't stop
people from using it.
After a test factory
has been established,
a test manager is able
to develop a test
suite with the
assistance of a test
suite template. In
order to combine test
cases for
the purpose of
evaluating a specific
version, a test suite
schema is utilized, as
can
be seen in Table 11.7.
A test suite ID, a title,
an objective, and a
collection of test
cases that need to be
handled by the test
suite are all necessary
components of the
structure. Additionally,
one determines the
individual test cases
that will need to be
carried out (test
rounds 1, 2, 3, and/or
regression), as well as
the specifications that
each test case must
meet. The plan is to
compile a new
project's test suite
from a
Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
1 Which is not test case variable? d K2
 a. requirement_ids,
b. tc_id, tc_title,
c. originator_group
d. customer_id
After a test case has been designed or selected, its execution
2 True K2
status is reset to its original state. (Truse /False)

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 Elaborate the test modeling of test design process. 13 3 K1
2 Describe the model of test results. 13 3 K1

Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 232-270
 Unit Lecture
4 21
No No
Topic Compatibility Testing, Usability Testing
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Explain Compatibility Testing K2
LO2 Explain Usability Testing K4

Boundary Value Analysis and Equivalence Class Partitioning are the most common technique in
Black-box Testing Techniques for test case design. Both are used to design test cases for validating
a range of values for any given input domain. Both these techniques are used together at all levels
of testing.

Boundary Value Analysis (BVA)

It is used to check the behavior of application using test data that exist at boundary values or in
more easy words, for a range of input data values, boundary values (extreme end values) are used
as input for testing. It is mostly used design technique as it is believed that software is most likely
to fail at upper and lower limits of input data values.

Example: A software allows people of age 20 to 50 years (both 20 and 50 are inclusive) to fill a
form, for which the user has to enter his age in the age field option of the software.
The boundary values are 20 (min value) and 50 (max value).

Invalid Valid Value

Value Invalid Value
(min, min+1, nominal value, max-1,
(min-1) max) (max+1)

19 20, 21, 30, 49, 50 51

In the above table, one can clearly identify all valid and invalid test values (values consider
during testing the system).
1. Valid value: Test values at which the system does not fail and function properly as per user
requirement.
2. Invalid Values: test values that do not meet the system requirement.
 Boundary Value Analysis Sample
Consider an example where a developer writes code for an amount text field which will accept and
transfer values only from 100 to 5000. The test engineer checks it by entering 99 into the amount
text field and then clicks on the transfer button. It will show an error message as 99 is an invalid test
case, because the boundary values are already set as 100 and 5000. Since 99 is less than 100, the
text field will not transfer the amount.

The valid and invalid test cases are listed below.

Valid Test Cases

1. Enter the value 100 which is min value.

2. Enter the value 101 which is min+1 value.
3. Enter the value 4999 which is max-1 value.
4. Enter the value 5000 which is max value.

Invalid Test Cases

1. Enter the value 99 which is min-1 value.

2. Enter the value 5001 which is max+1 value

Equivalence Partitioning
This black-box testing technique is also referred to as Equivalence Class Partitioning (ECP). This
test case design technique is typically used to reduce the total number of test cases to a finite set
of testable test cases, still covering maximum requirements.
In this method, the input domain data containing a range of input values is divided into different
equivalence data classes (at times also referred to as split sets). Test cases should be written in such
a way that they cover each equivalence partition (also called equivalence data class) at least once.

During test case execution, each value of every equivalence partition must display the same output
behavior as the other one. This method is established on the assumption that if one condition/value
in an equivalence partition passes, then all others will as well. Similarly, if one of the partition’s
conditions fails, the partition’s other condition/value will likewise fail.

In short, it is the process of picking all possible test cases and carefully placing them into
equivalence classes. One test value is picked from each class while testing.

This means a QA person tests a random value from each defined equivalence data class and if the
verification of the output value is successful for that input value, then the entire equivalence
class/partition is considered valid and vice versa.

Example #1: If you are testing for an input box accepting numbers from 1 to 1000, then there is no
use in writing thousands of test cases for all 1000 valid input numbers plus other test cases for
invalid data.
Using the Equivalence Partitioning method discussed above, test cases can be divided into three sets
of input data, called equivalence data classes. Each test case is representative of the respective
equivalence class.

So in the above example, we can divide our test cases into three equivalence classes of some valid
and invalid input values.

Test cases for input box accepting numbers between 1 and 1000 using Equivalence
Partitioning:
#1) Valid data test case (value between 1 and 1000): This includes one input data class with all
valid inputs. Pick a single value from the range of 1 to 1000 (say 99) as a valid test case. If you
select other values between 1 and 1000, then the result is going to be the same. So one test case for
valid input data should be sufficient.
#2) Invalid data test case (value less than 1): Here, input data class with all values below the
lower limit. i.e., any value below 1 (say zero), as an invalid input data test case.
#3) Invalid data test case (value greater than 1000): Input data with any value greater than 1000
(say 1001) to represent the invalid input class and the third equivalence class.

Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
What is an equivalence partition (also known as an
equivalence class)?
a) A set of test cases for testing classes of objects.
b) An input or output range of values such that only one
1 value in the range becomes a test case. b K2
c) An input or output range of values such that each
value in the range becomes a test case.
d) An input or output range of values such that every
tenth value in the range becomes a test case.
2. One of the fields on a form contains a text box which
accepts numeric values in the range of 18 to 25.
Indentify the invalid Equivalence class
a) 17 a K2
b) 19
c) 24
d) 21
3. In a Examination a candidate has to score minimum of c K2
24 marks inorder to clear the exam. The maximum that
he can score is 40 marks. Identify the Valid Equivalence
values if the student clears the exam.

a) 22,23,26
b) 21,39,40
c) 29,30,31
 d) 0,15,22
Equivalence partitioning is:
a. A black box testing technique used only by developers
b. A black box testing technique than can only be used
during system testing
2 c. A black box testing technique appropriate to all levels
c K2
of testing
d. A white box testing technique appropriate for
component testing
Which of the following is a valid collection of
equivalence classes for the following problem: An
integer field shall contain values from and
including 1 to and including 15
a. Less than 1, 1 through 15, more than 15
a K2
b. Negative numbers, 1 through 15, above 15
c. Less than 1, 1 through 14, more than 15
d. Less than 0, 1 through 14, 15 and more

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 Consider an example where a developer writes code for an 7 3 K3
amount text field which will accept and transfer values
only from 100 to 5000.
Write the BVA test cases for the above.
2 What is BVA? 2 3 K1
3 Define Equivalence class partitioning. 2 3 K1
4 Compare BVA & Equivalence partitioning test. 5 3 K2

Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 232-270

alteration. In the
event that this is not
the case, the test case
will be put through an
additional review,
which can be
accomplished by
shifting it to the
review stage.
Every time a test case
is run, it is possible to
make one revision to
it.
Former State Now
Deprecated A test
case that is no longer
relevant could be
shifted to a
deprecated state. In
an ideal scenario, the
test case should be
examined
to determine whether
or not it continues to
exist if it has not been
run for at least a
year. Because of the
factors listed below, a
test case might
become irrelevant
over
the course of time.
First, the functionality
of the system being
tested has undergone
significant revisions,
and second, an
insufficient amount of
test case maintenance
has led to an outdated
test case. Second,
when an older test
case is changed, it's
possible that some of
the requirements of
the first test case will
no longer be met.
Third, as the
circumstances evolve
over time, the
reusability of test
instances has a
tendency to
deteriorate. This is
particularly true of
test cases that were
not
developed with
sufficient
consideration given to
the possibility of
reuse. In
conclusion, test cases
may be haphazardly
brought forward for a
considerable
amount of time after
the original
justifications for them
have vanished. It's
possible
that nobody knows
the reason a particular
test case was created
in the first place,
but that doesn't stop
people from using it.
After a test factory
has been established,
a test manager is able
to develop a test
suite with the
assistance of a test
suite template. In
order to combine test
cases for
the purpose of
evaluating a specific
version, a test suite
schema is utilized, as
can
be seen in Table 11.7.
A test suite ID, a title,
an objective, and a
collection of test
cases that need to be
handled by the test
suite are all necessary
components of the
structure. Additionally,
one determines the
individual test cases
that will need to be
carried out (test
rounds 1, 2, 3, and/or
regression), as well as
the specifications that
each test case must
meet. The plan is to
compile a new
project's test suite
from a

Unit Lecture
4 22
No No
Topic Testing the Documentation
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Explain Testing the Documentation K2
LO2 Design a test case for given problem K4

Data Flow Testing:

Is a type of structural testing. It is a method that is used to find the test paths of a program
according to the locations of definitions and uses of variables in the program. It has nothing to do
with data flow diagrams. Furthermore, it is concerned with:
 Statements where variables receive values,
 Statements where these values are used or referenced.
To illustrate the approach of data flow testing, assume that each statement in the program
assigned a unique statement number. For a statement number S-
DEF(S) = {X | statement S contains the definition of X}
USE(S) = {X | statement S contains the use of X}

If a statement is a loop or if condition then its DEF set is empty and USE set is based on the
condition of statement s. Data Flow Testing uses the control flow graph to find the situations that
can interrupt the flow of the program. Reference or define anomalies in the flow of the data are
detected at the time of associations between values and variables. These anomalies are:
 A variable is defined but not used or referenced,
 A variable is used but never defined,
 A variable is defined twice before it is used
Types of Data Flow Testing:
1. Testing for All-Du-Paths: It Focuses on “All Definition-Use Paths. All-Du-Paths is an
acronym for “All Definition-Use Paths.” Using this technique, every possible path from a
variable’s definition to every usage point is tested.
2. All-Du-Path Predicate Node Testing: This technique focuses on predicate nodes, or decision
points, in the control flow graph.
3. All-Uses Testing: This type of testing checks every place a variable is used in the application.
4. All-Defs Testing: This type of testing examines every place a variable is specified within the
application’s code.
5. Testing for All-P-Uses: All-P-Uses stands for “All Possible Uses.” Using this method, every
potential use of a variable is tested.
6. All-C-Uses Test: It stands for “All Computation Uses.” Testing every possible path where a
variable is used in calculations or computations is the main goal of this technique.
7. Testing for All-I-Uses: All-I-Uses stands for “All Input Uses.” With this method, every path
that uses a variable obtained from outside inputs is tested.
8. Testing for All-O-Uses: It stands for “All Output Uses.” Using this method, every path where
a variable has been used to produce output must be tested.
9. Testing of Definition-Use Pairs: It concentrates on particular pairs of definitions and uses for
variables.
10. Testing of Use-Definition Paths: This type of testing examines the routes that lead from a
variable’s point of use to its definition.
Advantages of Data Flow Testing:
Data Flow Testing is used to find the following issues-
 To find a variable that is used but never defined,
 To find a variable that is defined but never used,
 To find a variable that is defined multiple times before it is use,
 Deallocating a variable before it is used.
Disadvantages of Data Flow Testing
 Time consuming and costly process
 Requires knowledge of programming languages
Example:
1. read x, y;
2. if(x>y)
3. a = x+1
else
4. a = y-1
5. print a;
Control flow graph of above example:
Define/use of variables of above example:
Variable Defined at node Used at node

x 1 2, 3

y 1 2, 4

a 3, 4 5

Test Design Preparedness Metrics

• Metrics are tracked
– To know if a test project is progressing according to schedule
– Plan the next project more accurately
• The following metrics are monitored
– Preparation status of test cases (PST)
– Average time spent (ATS) in test case design
– Number of available test (NAT) cases
– Number of planned test (NPT) cases
– Coverage of a test suite (CTS)

Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
Analyzing data flow in a program is done using ____
A. White box testing
B. Gray box testing
1 C. Black box testing b K2
D. Data flow testing
Answer: D) Data flow testing

Which of the testing techniques comes under white box

testing?
A. Data flow testing
2 B. Control flow testing a K2
C. Both
Answer: C) Both

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 What are the Test Design Preparedness Metrics? 7 3 K3
2 def factorial(n): 5 3 K3
if n == 0:
return 1
 else:
return n * factorial(n - 1)

print(factorial(5))
Draw data flow testing for the above problem
3 Explain the concept of Data flow testing with example. 13 3 K1

Reference Book

Author(s) Title of the book Page numbers

Kshirasagar Naik Software testing 112-150
And quality
Assurance

Unit Lecture
4 23
No No
Topic Testing in the Agile Environment
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Elaborate Testing in the Agile Environment K2

What is Model-Driven Test Design?

MDTD is built on the idea that designers will become more effective and efficient if they can raise
the level of abstraction. This approach breaks down the testing into a series of small tasks that
simplify test generation. Then test designers isolate their tasks and work at a higher level of
abstraction by using mathematical engineering structures to design test values independently of the
details of the software or design artifacts, test automation, and Test Execution.
Different phases in MDTD
MDTD can be done in 4 different phases. Each type of activity requires different skills, background
knowledge, education, and training. It is better to use different sets of people depend on the situation.
1. Test Design — This can be done in either Criteria-Based where Design test values satisfy
coverage criteria or other engineering goals or in Human-Based where Design test values based
on domain knowledge of the program and human knowledge of testing which is comparatively
harder. This the most technical part of the MDTD process better to use experienced developers
in this phase.
2. Test Automation — This involves embedding test values to scripts. Test cases are defined based
on the test requirements. Test values are chosen such that we can cover a larger part of the
application with fewer test cases. We don’t need that much domain knowledge in this phase,
however, we need to use technically skilled people.
3. Test Execution — The test engineer will run tests and records the results in this activity. Unlike
the previous activities, test execution not required a high skill set such as technical knowledge,
logical thinking, or domain knowledge. Since we consider this phase comparatively low risk, we
can assign junior intern engineers to execute the process. But we should focus on monitoring,
log collecting activities based on automation tools.
4. Test Evaluation — The process of evaluating the results and reporting to developers. This phase
is comparatively harder and we expected to have knowledge in the domain, testing, and User
interfaces, and psychology

Test automation process, make it easy to do regression testing in less time compared to manual
testing, and also it avoids the chance of missing the previous passed test cases to be tested in the
current testing process. MDTD defines a simple framework to automate the testing process in a
structured manner.

What are Software Testing Procedures?

The various testing practices, processes, & techniques used by testers to ensure that the software
application is tested and validated before its release or deployment is known as software testing
procedure. It is a combination of several test cases based on a certain logical reason. These are
complete, self-contained, self validating and can be executed automatically, with the assistance of
automated tools. Moreover, the software testing procedures are the deliverables produced of
the software development process and are used for both initial evaluation and
subsequent regression testing of target program module or modifications. Hence, software testing
procedures must be defined, planned, constructed, tested & reported regularly to achieve desired
results.
Test Procedure/Script Specification:
As reporting and documenting software testing procedure is important for the success of the
software testing and development process, the team publishes a test procedure/script specification
report, which is a document providing detailed instructions for the execution of one or more test
cases. This report defines the purpose of various software testing techniques used by testers and
makes them understandable for the client and other stakeholders of the project. IEEE standard
for Software Test Documentation (829-1998) defines the format for this report, which is used
rigorously followed by individuals/testers all over the globe.
Format for Test Procedure / Script Specification:
With its aim to define and specify the steps used for executing test cases as well as the measures
taken to analyze the software item in order to evaluate its set of features, the test procedure / script
specification document is prepared by software testers after the accomplishment of the software
testing phase. The template/format of this document is universally acknowledged and accepted as it
is defined by the IEEE standard 829-1998. Therefore, the format for test procedure / script
specification is:
 Identifier: To avoid confusion each test procedure / script specification document is
provided a unique company generated number, which helps define procedure specification
level as well as the the software it is related to.
 Purpose: Once a distinctive identification is generated for the document, the purpose of test
procedure is defined. It consists a detailed list of all the test cases covered during testing
procedure as well as the description of each test procedure.
 Special Requirements: Any special requirements and specification mentioned by the client
or stakeholders of the project before the commencement of the testing process are recorded
here with proper evidence and documentation. Hence, the details included here are:
o Type of testing: Manual or automated.
o The test environment.
o Any prerequisites of the test procedure.
o The stages where the test is to be executed, such as pre-testing, regression testing,
future compliance testing, etc.
o It also includes details about the special skills and training required by the team for
the test procedure.
 Procedures/Script Steps: Finally the actual steps used for the execution of the procedure as
well as the activities related to it are defined by the team at the end of the specification
document. It includes various procedure/script steps that are defined by IEEE are:
o Log.
o Set Up.
o Proceed.
o Measure .
o Shut down.
o Restart.
o Stop.
o Wrap-up.

Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
1 Test automation process, make it hard to do regression False K2
testing in less time compared to manual testing . (True /
 False)
Which of the following phase is not under MDTD?
a) Test design
2 b) Test correction b K2
c) Test Execution
d) Test Verification

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 What are the Phased of Modern test design? Explain 7 3 K2
in detail.
2 Elaborate in detail the testing procedures of software. 5 3 K2
3 Which phase of MDTD is harder? Why? 13 3 K2

Reference Book

Author(s) Title of the book Page numbers

Kshirasagar Naik Software testing 112-150
And quality
Assurance
 Unit Lecture
4 24
No No
Topic Testing Web and Mobile Applications.
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Illustrate the process of Testing the web applications K2
LO2 Illustrate the process of Testing the Mobile applications K2

Writing Test Case

There are certain practices that one could follow while writing the test cases that would be
considered beneficial.
1. 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.
2. Maintaining the client/customer/end-user requirements must be unique: While writing the
test cases, it’s necessary to make sure that they aren’t being written over and over again and
that each case is different from the others.
3. Zero Assumptions: Test cases should not contain assumed data, and don’t come up with
features/modules that don’t exist.
4. Traceability: Test cases should be traceable for future reference, so while writing it’s
important to keep that in mind,
5. Different input data: While writing test cases, all types of data must be taken into
consideration.
6. Strong module name: The module name should be self-explanatory while writing the test
case.
7. 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.
8. Maximum conditions: All kinds of conditions should be taken into consideration while
writing a test, increasing the effectiveness.
9. Meeting requirements: While writing the test case the client/customer/end-user requirements
must be met.
10. Repetitive Results: The test case must be written in such a way that it should provide the
same result.
11. 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.
12. Create test cases with the end user’s perspective: Create test cases by keeping end-user in
mind and the test cases must meet customer requirements.
13. Use unique Test Case ID: It is considered a good practice to use a unique Test Case ID for
the test cases following a naming convention for better understanding.
14. Add proper preconditions and postconditions: Preconditions and postconditions for the test
cases must be mentioned properly and clearly.
15. Test cases should be reusable: There are times when the developer updates the code, then
the testers need to update the test cases to meet the changing requirements.
16. Specify the exact expected outcome: Include the exact expected result, which tells us what
will be result of a particular test step.
Test Case Management Tools
Test management tools help to manage the test cases. These tools are automated tools that
decrease the time and effort of a tester as compared to the traditional way. Some test case
management tools include advanced dashboards, easier bug, and progress tracking as well as
management, custom test case templates, integration of test cases, inviting guest testers, managing
team requirements and plans, and much more.
Below are some of the test case management tools:
 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. A 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, 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 manage their
requirements, test plans, test cases, and test runs all in one single place and with no user limit.
The basic features of TestLodge include Test Plans, Test Runs, a Dashboard, a Test Suite, and
many more.

Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
Test automation process, make it hard to do regression
1 testing in less time compared to manual testing . (True / False K2
False)
Which of the following phase is not under MDTD?
e) Test design
2 f) Test correction b K2
g) Test Execution
h) Test Verification

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 Define zero assumption. 2 3 K1
2 Explain about Test Case Organization and Tracking 13 3 K2

Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 332-260