SOFTWARE TESTING

Module Number: 02

Module Name: Test Case Design

Test Case Design

AIM:
• To familiarise students with fundamental test case design of software testing.

• To provide knowledge to students on various test case design approaches so to cover almost all the
aspects of software testing.

• Also provide knowledge to students on how to evaluate those designed test cases.

2
Test Case Design

Objectives:
The Objectives of this module are to understand:
• The test case design techniques.
• Designing a set of test cases irrespective of the software type and behaviour to test it efficiently.

3
Test Case Design

Outcome:
At the end of this module, you are expected to:
• Explain different approaches of test case design strategies such as Specification-Based,
Structure-Based approach and Experience-Based.
• Describe different categories of the mentioned approaches and how it helps us in designing a
better test suites.
• Perform Test adequacy assessment using control flow, data flow, program mutations.
• Outline on how to go through a complexity testing of a particular program code.
• Evaluate Test Adequacy Criteria.

4
Test Case Design

Content
• Test case design strategies approaches such as Specification-Based or Black-box Testing,
Structure-Based or White-Box techniques and Experience-Based
• Additional techniques such as Random Testing, Requirements based Testing, Compatibility Testing,
Documentation Testing, and Domain Testing.
• Static testing vs. structural testing
• Test Adequacy Criteria
• Coverage and Control Flow Graphs
• Additional White Box Test Design Approaches
• Code complexity testing
• Evaluating Test Adequacy Criteria
5
Categories of software testing techniques
• 1. Static Testing Techniques: Testing of a component or system at
specification or implementation level without execution of the
software product, for example, different types of review, planning,
kick-off meetings, preparation for work etc.
• 2. Dynamic Testing Techniques: Testing that involves the execution
of the software product or the system.

6
• Dynamic Testing techniques are again subdivided into three more
categories:
• i) Specification-based Technique / Black box Testing
Technique/ Behavioral Testing Technique
• ii) Structure-based Technique/ White box Testing Technique/
Structural testing technique
• iii) Experience-based Testing Technique

7
Test Case Design

Did you know that in order to ensure a high-quality software, we need to have a set of
test case design strategies?
• Design an optimal test suite of reasonable size and uncover as many errors as possible as
exhaustive testing of any non-trivial system is impractical because the input data domain is
extremely large.
Approach

Specification-Based Structure-Based Experience-Based

• Lets start from the left

8
Test Case Design

Specification-Based
or
Black-box Testing

9
Test Case Design

Specification-Based or Black-box Testing:

• Test cases are designed using only functional specification of the software without any knowledge of
the internal structure of the software.
• For this reason, black-box testing is also known as functional testing.
It focuses on
• Technical specifications
• Design
• Client’s requirements to design test cases.
• Divided into 6 categories which is shown at the diagram (next slide).

10
Test Case Design

Specification-Based or Black-box Testing:

Boundary Value Analysis (BVA)

Equivalence Partitioning (EP)

Decision Table Testing

State Transition Diagrams

Use Case Testing

Cause-Effect Graph

11
Example of Black Box Testing
• A simple black box testing example for a login functionality of a web
application. In this scenario, we will test the login page without
having access to the internal code or implementation details.

12
Test Case Name: Verify successful login with
valid credentials.
Test Steps:
1. Open the web browser.
2. Enter the URL of the application’s login page.
3. Enter a valid username in the username field.
4. Enter a valid password in the password field.
5. Click on the “Login” button.
6. Wait for the application to process the login request.

13
• Expected Result: The user should be successfully logged into the
application’s dashboard/homepage.
• Test Case Status: PASS (if the user is redirected to the
dashboard/homepage)

14
Test Case Name: Verify unsuccessful login
with invalid credentials.
Test Steps:
1. Open the web browser.
2. Enter the URL of the application’s login page.
3. Enter an invalid username (e.g., “invaliduser”) in the username
field.
4. Enter an invalid password (e.g., “wrongpassword”) in the password
field.
5. Click on the “Login” button.
Wait for the application to process the login request.
15
• Expected Result: The login attempt should fail, and an appropriate
error message (e.g., “Invalid username or password”) should be
displayed on the login page.
• Test Case Status: PASS (if the error message is displayed)

16
 Equivalence Partitioning
• Equivalence Partitioning or Equivalence Class Partitioning is type
of black box testing technique which can be applied to all levels
of software testing like unit, integration, system, etc.
• In this technique, the input domain of a program is divided into
equivalence data partitions (also called equivalence class) that can be
used to derive test cases which reduces time required for testing
because of small number of test cases are needed.
• Test case design is based on an evaluation of equivalence classes
for an input condition.
• An equivalence class represents a set of valid or invalid states for
input conditions.

Jain (Deemed-to-be University), Department of BCA 17

 Guidelines for Defining Equivalence Classes
• If an input condition specifies a range, one valid and two invalid
equivalence classes are defined
• Input range: 1 – 10 Eq classes: {1..10}, {x < 1}, {x > 10}
• If an input condition requires a specific value, one valid and two
invalid equivalence classes are defined
• Input value: 250 Eq classes: {250}, {x < 250}, {x > 250}
• If an input condition specifies a member of a set, one valid and one
invalid equivalence class are defined
• Input set: {-2.5, 7.3, 8.4} Eq classes: {-2.5, 7.3, 8.4}, {any other
values x}
• If an input condition is a Boolean value, one valid and one invalid
class are defined
• Input: {true condition} Eq classes: {true condition}, {false condition}

Jain (Deemed-to-be University), Department of BCA 18

Boundary Value Analysis
• Another frequently used black-box testing
• A greater number of errors occur at the boundaries of
the input domain rather than in the "center"
• Boundary value analysis is a test case design method
that complements equivalence partitioning
• It selects test cases at the edges of an input
domain

Jain (Deemed-to-be University), Department of BCA 19

Test Case Design

Specification-Based or Black-box Testing:

Boundary Value Analysis(BVA):

• Some typical programming errors occur:

• At boundaries of equivalence classes.

• It might be purely due to psychological factors.

• Programmers often fail to see:

• Special processing required at the boundaries of equivalence classes

• Programmers may improperly use < instead of <=

• Boundary value analysis:

20
• Select test cases at the boundaries of different equivalence classes.
 Guidelines for Boundary Value Analysis
• 1. If an input condition specifies a range bounded by values a and b, test cases should be designed with
values a and b as well as values just above and just below a and b
• Consider an example where a program under test accepts values only from 100 to 5000.
• The valid and invalid test cases are listed below.
❑ Valid Test Cases
a) Enter the value 100 which is min value.
b) Enter the value 101 which is min+1 value.
c) Enter the value 4999 which is max-1 value.
d) Enter the value 5000 which is max value.
❑ Invalid Test Cases
a) Enter the value 99 which is min-1 value.
b) Enter the value 5001 which is max+1 value

• 2. If an input condition specifies a number of values (i.e. a set), test case should be developed that exercise
the minimum and maximum numbers. Values just above and just below the minimum and maximum are also
tested

Jain (Deemed-to-be University), Department of BCA 21

Decision Table Testing:
• Decision table testing is a software testing technique used to test
system behavior for different input combinations.
• This is a systematic approach where the different input combinations
and their corresponding system behavior (Output) are captured in a
tabular form.
• That is why it is also called as a Cause-Effect table where Cause and
effects are captured for better test coverage.

22
Test Case Design

Decision Table Testing:

• Here, test cases are designed on the basis of the decision tables that are formulated using different
combinations of inputs and their corresponding outputs based on various conditions and scenarios
adhering to different business rules.

23
• Let’s take the example of a login screen of an application.
• The condition states that if the user provides the correct username
and password the user will be redirected to the homepage.
• If any of the input is wrong, an error message will be displayed on
the screen.

24
Decision table

25
Another way

26
In the above example:
• T stands for correct Email id/password.
• F stands for incorrect Email id/password
• H stands for Home screen to be displayed to the user
• E stands for the Error message to be displayed to the user
• TC stands for the Test case.

27
Test cases
• Test Case 1 – The email id and password both are correct. Hence, the
user should be directed to Homepage.
• Test Case 2 – The email id was correct, but the password was wrong.
Hence, an error message should be shown to the user mentioning
“Incorrect Password”.
• Test Case 3 – The email id was wrong, but the password was correct.
Hence, an error message should be shown to the user mentioning
“Incorrect Email Id”.
• Test Case 4 – The email id and password both are incorrect. Hence,
an error message should be shown to the user mentioning “Incorrect
Email Id”.
28
Decision Table to upload an image
Consider a dialogue box that will ask the user to upload a photo with
certain conditions like –
1. You can upload only ‘.jpg’ format image
2. file size less than 32kb
3. resolution 137*177.

29
30
• For this condition, we can create 8 different test cases and ensure
complete coverage based on the above table.
• Upload a photo with format ‘.jpg’, size less than 32kb and resolution
137*177 and click on upload. Expected result is Photo should upload
successfully
• Upload a photo with format ‘.jpg’, size less than 32kb and resolution
not 137*177 and click on upload. Expected result is Error message
resolution mismatch should be displayed
• Upload a photo with format ‘.jpg’, size more than 32kb and resolution
137*177 and click on upload. Expected result is Error message size
mismatch should be displayed

31
• Upload a photo with format ‘.jpg’, size more than equal to 32kb and
resolution not 137*177 and click on upload. Expected result is Error
message size and resolution mismatch should be displayed
• Upload a photo with format other than ‘.jpg’, size less than 32kb and
resolution 137*177 and click on upload. Expected result is Error
message for format mismatch should be displayed
• Upload a photo with format other than ‘.jpg’, size less than 32kb and
resolution not 137*177 and click on upload. Expected result is Error
message format and resolution mismatch should be displayed
• Upload a photo with format other than ‘.jpg’, size more than 32kb
and resolution 137*177 and click on upload. Expected result is Error
message for format and size mismatch should be displayed
• Upload a photo with format other than ‘.jpg’, size more than 32kb
and resolution not 137*177 and click on upload. Expected result is
Error message for format, size and resolution mismatch should be
displayed
32
Importance of Decision table testing
• Decision Table Testing is Important because it helps to test different
combinations of conditions and provides better test coverage for
complex business logic.
• When testing the behavior of a large set of inputs where system
behavior differs with each set of inputs, decision table testing
provides good coverage and the representation is simple so it is easy
to interpret and use.

33
Advantages of Decision Table Testing
• When the system behavior is different for different inputs and not the
same for a range of inputs, both equivalent partitioning, and boundary
value analysis won’t help, but a decision table can be used.
• The representation is simple so that it can be easily interpreted and is used
for development and business as well.
• This table will help to make effective combinations and can ensure better
coverage for testing
• Any complex business conditions can be easily turned into decision tables
• In a case we are going for 100% coverage typically when the input
combinations are low, this technique can ensure the coverage.

34
Disadvantages of Decision Table Testing
• The main disadvantage is that when the number of inputs increases
the table will become more complex

35
State Transition Diagrams:
• Here, the software is perceived as a system having a finite number of
states of different types. The transition from one state to another is guided
by a set of rules.

• The rules define the response to different inputs.

• It can be implemented on the systems which have certain workflows
within them.

36
When to Use State Transition
• This can be used when a tester is testing the application for a finite
set of input values.
• When the tester is trying to test sequence of events that occur in the
application under test. I.e., this will allow the tester to test the
application behavior for a sequence of input values.
• When the system under test has a dependency on the events/values
in the past.

37
When to Not Rely On State Transition
• When the testing is not done for sequential input combinations.
• If the testing is to be done for different functionalities like exploratory
testing

38
Four Parts Of State Transition Diagram
• There are 4 main components of the State Transition Model as below:

39
40
State Transition Diagram and State
Transition Table
• There are two main ways to represent or design state transition,
• State transition diagram,
• state transition table.
• In state transition diagram the states are shown in boxed texts, and
the transition is represented by arrows.
• It is also called State Chart or Graph. It is useful in identifying valid
transitions.
• In state transition table all the states are listed on the left side, and
the events are described on the top.
• Each cell in the table represents the state of the system after the
event has occurred. It is also called State Table. It is useful in
identifying invalid transitions. 41
How to Make a State Transition (Examples
of a State Transition)
• Example
• Let’s consider an ATM system function where if the user enters the
invalid password three times the account will be locked.
• In this system, if the user enters a valid password in any of the first
three attempts the user will be logged in successfully.
• If the user enters the invalid password in the first or second try, the
user will be asked to re-enter the password.
• Finally, if the user enters incorrect password 3rd time, the account will
be blocked.

42
43
State Transition Table

44
• Example:
• In the flight reservation login screen, consider you have to enter
correct agent name and password to access the flight reservation
application.
• It gives you the access to the application with correct password and
login name, but what if you entered the wrong password.

45
• The application allows three attempts, and if users enter the wrong
password at 4th attempt, the system closes the application
automatically.
• The State Graphs helps you determine valid transitions to be tested.
In this case, testing with the correct password and with an incorrect
password is compulsory. For the test scenarios, log-in on 2nd, 3rd and
4th attempt anyone could be tested.
• You can use State Table to determine invalid system transitions.

46
47
48
Advantages and Disadvantages of State
Transition Technique

49
Test Case Design

Specification-Based or Black-box Testing:

Use Case Testing:
• It is a description of a particular use of the software by a user.
• Here, the test cases are designed to execute different business scenarios and end-user
functionalities.
• It helps to identify test cases that cover the entire system.

50
What is Use Case Testing?
• Use Case Testing is generally a part of black box testing and that helps
developers and testers to identify test scenarios that exercise the
whole system on each transaction basis from start to finish.
• Business experts and developers must have a mutual understanding
of the requirement, as it’s very difficult to attain.

51
• Use case testing is a functional testing technique that helps in
identifying and testing scenarios on the whole system or doing
start-to-end transactions.
• It helps to identify the gaps in software that might not be identified
by testing individual components.
• It is used to develop test cases at the system level or acceptance
level.

52
Feature of Use Case Testing
• Use case testing is not testing that is performed to decide the quality
of the software.
• Although it is a type of end-to-end testing, it won’t ensure the entire
coverage of the user application.
• Use case testing will find out the defects in integration testing.
• It is very effective in identifying the gaps in the software that won’t
be identified by testing individual components in isolation.

53
Benefits of Use Case Testing
• Helps manage complexity: Use case-driven analysis that helps manage
complexity since it focuses on one specific usage aspect at a time.
• Testing from the user’s perspective: Use cases are designed from the
user’s perspective. Thus, use case testing is done from the user’s
perspective and helps to uncover the issues related to the user experience.
• Reduced complexity of test cases: The complexity of the test cases will be
reduced as the testing team will follow the path given in the use case
document.
• Test functional requirements: Use cases help to capture the functional
requirements of a system. Thus, use case testing tests the functional
requirements of the system.
• Starts from a simple view of the system: Use cases start from the simple
view of the system and are used primarily for the users.

54
Drawbacks of Use Case Testing
• Missing use case: If there is a use case missing from the use case
document, then it will impact the testing process as there is a high
possibility that the test cases for the missing use case will also be left
out.
• Cover only functional requirements: Since use cases cover only
functional requirements so use case testing by default is functional
requirements oriented.
• Use cases are from the user’s perspective: 100% test coverage is not
possible in cases as use cases are written from the user’s perspective
and there may be some scenarios that are not from the user’s
perspective, so then it may not be included in the test document.

55
Example

56
Test Case Design

Specification-Based or Black-box Testing:

Cause-Effect Graph:
• The technique involves graphical Identify and Define the Effect

illustration of the relationship

Fill in the effect Box and Draw the Spine
between a given outcome and all
the factors that influence the Identify the main causes contributing to the
outcome. effect being studied.

• Steps for drawing cause-Effect

For each major branch, identify other specific
Diagram: (on the right side) factors which may be the causes of the effect.

Categorize relative causes and provide detailed

levels of causes. 57
Test Case Design

Self Assessment Question

1. Which one of the given options are the test case design approaches in order to ensure a high-quality
software?
i. Specification-Based
ii. Structure-Based

a. Only i
b. Only ii
c. All i and ii
d. Neither i nor ii

Answer: All i and ii 58

Test Case Design

Self Assessment Question

2. Which one of the given options is focused by Specification-Based approach?
i. Technical specifications
ii. Design
iii. Client’s requirements to design test cases

a. Only i
b. Only ii
c. Only i and ii
d. All i, ii and iii

Answer: All i, ii and iii 59

Test Case Design

Self Assessment Question

3. Which one of the given options belongs to Boundary value analysis?
i. White Box Testing
ii. Black Box Testing

a. Only i
b. Only ii
c. All i and ii
d. Neither i nor ii

Answer: Only ii
60
Test Case Design

Self Assessment Question

4. Steps to draw cause-Effect Diagram is given below. Arrange the steps in the correct order.
i. Categorize relative causes and provide detailed levels of causes.
ii. For each major branch, identify other specific factors which may be the causes of the effect.
iii. Identify the main causes contributing to the effect being studied.
iv. Fill in the effect Box and Draw the Spine
v. Identify and Define the Effect

a. ii, iv, iii, i, v

b. iv, iii, i, v, ii
c. v, iv, iii, ii, i
d. ii, i, iv, iii, v

Answer: v, iv, iii, ii, i 61

Test Case Design

Structure-Based
or
White-Box techniques

62
Test Case Design

Structure-Based or White-Box techniques

• It is based on the internal structure of the software.
Statement testing and
• This technique focuses on testing the developed Coverage
code. Developers who have complete information of
Decision testing
the software code, its internal structure, and design Coverage
help to design the test cases.
Condition testing
• This technique is further divided into five categories
and those are shown on the right side: Multiple Condition
testing

All Path Testing

63
Test Case Design

Structure-Based or White-Box techniques

Statement Testing and Coverage:
• This technique involves execution of all the executable statements in the source code at least
once.
• The percentage of the executable statements is calculated as per the given requirement. This is
the least preferred metric for checking test coverage.
Decision Testing Coverage:
• This technique is also known as branch coverage and it is a testing method in which each one of
the possible branches from each decision point is executed at least once to ensure all reachable
code is executed.
• This helps to validate all the branches in the code. This helps to ensure that no branch leads to
unexpected behaviour of the application. 64
Test Case Design

Structure-Based or White-Box techniques

Condition Testing:
• Condition testing also is known as Predicate coverage testing, each Boolean expression is
predicted as TRUE or FALSE.
• All the testing outcomes are at least tested once. This type of testing involves 100% coverage
of the code. The test cases are designed as such that the condition outcomes are easily
executed.
Multiple Condition Testing:
• The purpose of Multiple condition testing is to test the different combination of conditions to
get 100% coverage. To ensure complete coverage, two or more test scripts are required which
requires more efforts.
All Path Testing
• In this technique, the source code of a program is leveraged to find every executable path. This
helps to determine all the faults within a particular code.
65
Test Case Design

Self Assessment Question

5. Which one of the given options is also called as White Box Techniques?

a. Error guessing technique

b. Design based technique
c. Structural testing
d. Experience based technique

Answer: Structural testing

66
Test Case Design

Self Assessment Question

6. ____________ testing is not a white box technique.

a. Data flow
b. Path
c. Statement
d. State transition

Answer: State transition

67
Test Case Design

Self Assessment Question

7. All Path Testing: In this technique, the source code of a program is leveraged to find most of the
executable path within a program code. State whether True or False.

a. True
b. False

Answer: False

68
Test Case Design

Experience-Based techniques

69
Test Case Design

Experience-Based techniques:
These techniques are highly dependent on tester’s experience to understand the most important areas of
the software.
• The outcome of these techniques are based on the skills, knowledge, and expertise of the people
involved.
• The types of experience-based techniques are as follows:
• Error Guessing
• Exploratory Testing

70
Test Case Design

Experience-Based techniques:
Error Guessing:
• The testers anticipate errors based on their experience, availability of data and their knowledge
of product failure.
• Error guessing is dependent on the skills, intuition, and experience of the testers
Exploratory Testing:
• This technique is used to test the application without any formal documentation.
• There is minimum time available for testing and maximum for test execution. In such scenario,
the test design and test execution are performed concurrently.

71
Test Case Design

Self Assessment Questions

8. Which one of the given options are dependent on Error guessing technique?
i. Skills of the testers
ii. Intuition of the testers
iii. Experience of the testers

a. Only i
b. Only ii
c. Only i and ii
d. All i, ii and iii

Answer: All i, ii and iii 72

Test Case Design

Additional techniques such as:

• Random Testing
• Requirements based Testing
• Compatibility Testing
• Documentation Testing
• Domain Testing

73
Test Case Design

Random Testing:
It is performed when there is not enough time to write and execute the tests.
• Characteristics of Random Testing are:
• It is performed where the defects are NOT identified in regular intervals.
• Random input is used to test the system's reliability and performance.
• Saves time and effort than actual test efforts.
• Stages in Random Testing:

Execute Tests Result

Random Input Test Input Comparison
with the decided against expected
Raise defects Fix and retest
identification selection
Inputs outcomes

74
Test Case Design

Requirements based Testing:

In this approach, test cases, conditions and data are derived from requirements. It includes functional
tests and also non-functional attributes such as performance, reliability or usability.
Stages in Requirements based Testing are:

Defining
Track and
Test Design Test Verify Test Verify Test
Execute Tests Manage
Completion Cases Results Coverage
Defects
Criteria

75
Test Case Design

Compatibility Testing:
• It involves checking whether your software is capable of running on different hardware, operating
systems, applications, network environments or mobile devices.

Types of version checking:

Backward compatibility Testing: To Forward compatibility Testing : To

verify the behaviour of the developed verify the behaviour of the developed
hardware/software with the older hardware/software with the newer
versions of the hardware/software. versions of the hardware/software.

• Tools for compatibility testing: Browser Stack, Secure Platform, Virtual Desktops .

76
Test Case Design

Compatibility Testing:
Compatibility testing process are:
1. The initial phase of compatibility testing is to define the set of environments or platforms the
application is expected to work on.
2. The tester should have enough knowledge on the platforms / software / hardware to understand
the expected application behaviour under different configurations.
3. The environment needs to be set-up for testing with different platforms, devices, networks to
check whether your application runs well under different configurations.
4. Report the bugs. Fix the defects. Re-test to confirm Defect fixing.

77
Test Case Design

Documentation Testing:
• It covers all the manuals, user guides, installation guides, setup guides, read me files, software
release notes, and online help that are provided along with the software to help the end user to
understand the software system.
• User Documentation Testing should have two objectives:-
• To check if what is stated in the document is available in the software.
• To check if what is there in the product is explained correctly in the document.
• This testing plays a vital role as the users will refer this document when they start using the
software at their location.
• A badly written document can put off a user and bias them against the product even the product
offers rich functionality.
78
Test Case Design

Domain Testing:
• Involves testing software in which a minimum number of inputs are used to test the output of a
system, to be sure that the system does not accept invalid and input values that are out of range.
• Soul objective is to confirm if the system accepts input within the acceptable range and delivers the
output that is needed. It equally confirms that inputs, indices, and conditions that are outside the
valid or specified range are not accepted by the system.
Skills needed for domain testing:
• Testing skill, domain knowledge, automation skill, ability to work under pressure, bug hunting
skill, programming skill, communication skill, technical skill, quick grasping.

79
Test Case Design

Self Assessment Question

9. Which one of the given options is involved in requirement based testing process?
i. Testing process should be manageable
ii. A timely testing must be entertained.

a. Only i
b. Only ii
c. All i and ii
d. Neither i nor ii

Answer: All i and ii

80
Usability Testing
• You need to interact with a software program and for
that a user interface or UI is required.
• The computer UI we're all familiar with has changed
over time.
• Although the UIs may be very different, technically
they all provided the same interaction with the
computer the means to give it input and receive
output.
What Makes a Good UI?
• List of seven important traits common to a good UI:
1. Follows Standards and Guidelines
2. Intuitive
3. Consistent
4. Flexible
5. Comfortable
6. Correct
7. Useful
Testing for the Disabled: Accessibility
Testing
• A serious topic that falls under the area of usability
testing is that of accessibility testing or testing for the
disabled.

• Although there are many types of disabilities, the

following ones make using computers and software
especially difficult:
Visual impairments
• Color blindness, extreme near and far sightedness,
tunnel vision, dim vision, blurry vision, and cataracts
are examples of visual limitations.
• People with one or more of these would have their
own unique difficulty in using software.
• E.g. trying to see where the mouse pointer is located
or where text or small graphics appear onscreen.
Hearing impairments
• Someone may be partially or completely deaf, have
problems hearing certain frequencies, or picking a
specific sound out of background noise.
• Such a person may not be able to hear the sounds or
voices that accompany an onscreen video, audible
help, or system alerts.
Motion impairments
• Disease or injury can cause a person to lose fine,
gross, or total motor control of his hands or arms.
• It may be difficult or impossible for some people to
properly use a keyboard or a mouse.
• For example, they may not be able to press more
than one key at a time or may find it impossible to
press a key only once.
• Accurately moving a mouse may not be possible.
Cognitive and language
• Dyslexia and memory problems may make it difficult
for someone to use complex user interfaces.
• Think of the issues outlined previously discussed and
how they might impact a person with cognitive and
language difficulties.
Legal Requirements
• Fortunately, developing software with a user
interface that can be used by the disabled isn't just a
good idea, a guideline, or a standardit's often the
law.
Making the Words and Pictures Make
Sense
• At time there is poor translation, and software can
look bad.
• If little effort is put into building the software for
foreign languages, It's easy to individually convert all
the words, but to make the overall instructions
meaningful and useful requires much more work and
attention.
• Usually the translations should be sufficient.
• Unfortunately, what you'll find in the software
industry is that even a good translation isn't
sufficient.
• Take Spanish, for example. It should be a simple
matter to convert English text to Spanish, right?
• Well, which Spanish are you referring to? Spanish
from Spain? What about Spanish from Costa Rica,
Peru, or the Dominican Republic?
• They're all Spanish, but they're different enough that
software written for one might not be received well
by the others.
• What needs to be accounted for, besides the
language, is the region or locale the user's country or
geographic area.
• The process of adapting software to a specific locale,
taking into account its language, dialect, local
conventions, and culture, is called localization or
sometimes internationalization.
• Testing the software for this is called localization
testing.
Translation Issues
• Although translation is just a part of the overall
localization effort, it's an important one from a test
standpoint.
• The most obvious problem is how to test something
that's in another language.
• It's important that you or someone on your test team
be at least a little familiar with the language you're
testing.
• Of course, if you're shipping your program in a
number of different languages, they may be difficult.
• The solution is to contract out this work to a
localization testing company.
Issues
• Text Expansion
• ASCII, DBCS, and Unicode
• Hot Keys and Shortcuts
• Extended Characters
• Computations on Characters
• Reading Left to Right and Right to Left
• Text in Graphics
• Keep the Text out of the Code
Localization Issues
• Well translated and tested software is precise and
reliable, but, if the programmers don't consider
localization issues, it's probably not accurate or of
high quality.
• It might look and feel great, read perfectly, and never
crash, but to someone from another locale, it might
just seem plain old wrong.
• Assuring that the product is correctly localized gets
you to this next step.
Content:
• Example:
• In the United States, a soccer ball isn't the same thing
as a football!
• You don't drive on the left!
• These may not seem right to you, but in other
countries they would be perfectly accurate.
• If you're testing a product that will be localized, you
need to carefully examine the content to make sure
it's appropriate to the area where it will be used.
• The following list shows various types of content that
you should carefully review for localization issues.
• Don't consider it a complete list; there can be many
more examples depending on the product.
• Think about what other items in your software might
be problematic if it was sent to another country.
• Sample documents
• Icons
• Pictures
• Sounds
• Video
• Help files
• Maps with disputed boundaries
• Marketing material
• Packaging
• Web links
A NOSE TOO LONG
• Data Formats
• Configuration and Compatibility Issues
• Foreign Platform Configurations
• Data Compatibility

102
Test Case Design

Self Assessment Question

10. Which one of the given options is a type of version checking involved in compatible testing?
i. Backward compatibility Testing
ii. Forward compatibility Testing

a. Only i
b. Only ii
c. All i and ii
d. Neither i nor ii

Answer: All i and ii

103
Test Case Design

Self Assessment Question

11. Which one of the given options is the objective of User Documentation Testing?
i. To check if what is stated in the document is available in the software
ii. To check if what is there in the product is explained correctly in the document

a. Only i
b. Only ii
c. All i and ii
d. Neither i nor ii

Answer: All i and ii

104
Test Case Design

Static testing Dynamic testing

1. It is all about prevention.

2. More cost effective.
1. Whereas it is all about care.
3. Here, code is being examined without
2. Less cost effective.
being executed.
3. The code is being executed and tested
4. It takes shorter time as it tests each
Vs. without necessarily being examined.
case separately.
4. It takes longer time than static testing.
5. It is done before the code
5. It is done after the code deployment.
deployment.
6. It is done in validation stage.
6. It is done in verification stage.
7. It covers less areas in shorter time.
7. It covers more areas in shorter time.
8. It finds less bugs than static testing.
8. It finds more bugs than dynamic
testing.

105
Test Case Design

Test Adequacy Criteria

106
Test Case Design

Test Adequacy Criteria:

It exists in the form of framework for deciding which structural elements to select as the focus of testing
for choosing the appropriate test data, and for deciding when the testing efforts are adequate enough to
terminate the process with confidence that the software is working properly.
The scope of adequacy criteria also includes:
• Helping testers to select properties of a program to focus on during test.
• Helping testers to select a test data set for a program based on the selected properties.
• Supporting testers with the development of quantitative objectives for testing.
• Indicating to testers whether or not testing can be stopped for that program.

107
Test Case Design

Coverage and Control Flow Graphs

108
Test Case Design

Coverage and Control Flow Graphs: is associated with the use of control and data flow models to
represent program structural elements and data.
Control flow graph:
• It shows all the paths that can be traversed during a program execution.
• It can also be viewed as a directed graph in which edges portray control flow paths and the nodes
portray basic blocks, which are straight line segments without any jumps or branching.
• Here, two specially designated blocks exist:
entry blocks and exit blocks.

It allows the control to enter Conditions that must be met before

into the control flow graph. leaving the exit block.

Advantages:
1. It can easily summarize the information per each basic block.
2. It can easily locate unreachable codes of a program, and syntactic structures such as loops are easy
to find in a control flow graph.
109
Test Case Design

Control flow graph: example

begin
1 2 3 4
1. int a, b, power;
2. float c;
3. input(a, b);
4. if(b<0) { 5 6
5. power=-y;
else
6. power=y;
7
7. c=1;
8. while(power!=0){
9. c=c*a; 11 8 9
10. power=power-1;}
11. If(y<0)
12. z=1/z; 13 12 10
13. Output(z);
110
end
Test Case Design

Control flow graph: example

In the above example:
• Each instruction is represented by a node.
• The set of arrows i.e., path represents the order of Program code execution.
• There are 13 number of instruction; hence there are 13 nodes in the control flow diagram.

Paths: Their Role in White Box-Based Test Design

• A path is a sequence of control flow nodes usually beginning from the entry node of a graph through
to the exit node.
• In the previous example, we can derive the following set of independent paths starting with the first
path identified above.
• 1-2-3-4-5-7-8-11-12-13
• 1-2-3-4-6-7-8-11-12-13
• 1-2-3-4-5-7-8-9-10-8-11-12-13
• 1-2-3-4-6-7-8-9-10-8-11-12-13
111
Test Case Design

Additional White Box Test Design Approaches:

• Data flow testing
• Mutation testing

112
Test Case Design

Data flow testing

113
Test Case Design

Data flow testing:

• It comes under white box testing which helps us in determining many logical bugs in the code which
can go hidden if we do not follow the provided steps involved in the testing.

Data flow testing

Definition: involves initializing a use

variable with some content. E.g.->
int x=1; or read(x); or x=x+1;

P-use: Predicate use- use of C-use: Computation use-> use of

variable in predicate logic variable in computation

114
Test Case Design

Let us discuss an example to get a deep knowledge of data flow testing.

Def-use: stands for definition Example 1: Def C-use P-use
C-use: for computation use x,y
P-use: for predicate use 1. Read (x,y); z x
2. z=x+2;
Note: z,y
3. If(z<y)
We can choose any strategy like 4. w=x+1; w x
5. Else
statement coverage, branch 6. y=y+1;
7. Print(x,y,w,z); y y
coverage and many more. Here,
x,y,w,z
we are using statement coverage.

115
Test Case Design

Example 1:
1. read (x,y); Some Def-Use Associations: read (x,y) 1
2. z=x+2; • (x,1,2),(x,1,4),…….
3. if(z<y) • (y,1,(3,t)),(y,1,(3,f)),(y,1,5),…. z=x+2 2
4. w=x+1; .
5. else • (z,2,(3,t)),….. z<y 3
6. y=y+1;
7. print(x,y,w,z);
T F
Note: w=x+1 4 5 y=y+1
• (x,a,b): x is defined at instruction a and used in the
instruction b.
• (y,a,(b,t)): y is defined at the instruction a and used in the print(x,y,w,z 6
)
instruction b if the condition turns out to be true.
• (y,a,(b,f)): y is defined at the instruction a and used in the
instruction b if the condition turns out to be false.
116
Test Case Design

Mutation Testing

117
Test Case Design

Mutation Testing
• A structural testing method mainly to improve test suite adequacy.
• Estimates the number of faults present in the system under test.
The process is as follows:
• Given a Program P and test suite T.
• Apply mutation to the program P to obtain a sequence P1, P2,....Pn mutants of P.
• Each mutant is generated by applying single mutant operation to P.
• Run the test suite T on each mutants. T is said to kill mutant Pj if it detects an error.
• If we kill k mutants out of n mutants, then adequacy of T can be determined by (k/n).
• If it turns out to be k=n then, T is said to be mutation adequate.
• It can be almost completely automated.
118
Test Case Design

Mutation Testing

Types of Mutation

Value Mutation Decision Mutation Statement Mutation

119
Test Case Design

Mutation Testing
Value Mutation:
• It involves changing the values to reflect errors in reasoning about programs.
• Example such as swapping values in initializations.
• The most common approach is to change constants by one in an attempt to generate a one-off
error (particularly common in accessing arrays).
Coverage criterion:
• Here, our intention is to perturb all constants in the program or unit at least once or twice.
• Example is provided in the next slide.

120
Test Case Design

Mutation Testing
Public int Segment (int t[], int l, int u) {
// Assume t is in ascending order, and l<u,
//counts the length of the segment
// of t with each element l<t[i]<u
int k=0; Mutating to k=1 will cause miscounting
for(int i=0; i< t.length && t[i]<u; i++) {
if(t[i]>l) {
k=k+1;
}
} Here we might mutate the code to read i=1, a test
return k; that would kill this would have t.length 1 and
} have l<t[0]<u, then the program would fail to
count t[0] and return 0 rather than 1 as a result

121
Test Case Design

Mutation Testing
Decision Mutation:
• Mutants are designed to model failures in reasoning about conditions in programs.
Example: > modeling ‘one-off’ error by changing
• ‘< ‘ to ‘<=’ or vice versa.
• ‘<’ to ‘>’ or vice versa.
• ‘&&’ to ‘||’ or vice versa.
• Example is provided in the next slide.

122
Test Case Design

Mutation Testing
Public int Segment (int t[], int l, int u) {
// Assume t is in ascending order, and l<u,
//counts the length of the segment Mutating to t[i]>u will cause
// of t with each element l<t[i]<u miscounting
int k=0;
for(int i=0; i< t.length && t[i]<u; i++) {
if(t[i]>l) {
k=k+1; We can model “one-off” errors in the loop
} bound by changing this condition to
i<=t.length provided array bounds are
}
checked exactly this will provoke an error on
return k; every condition.
}

123
Test Case Design

Mutation Testing
Statement Mutation:
• Goal is to primarily model editing slips. Typically this arises when the developer is cutting and
pasting code. So the result is usually omitted or duplicate code.

Examples

Duplicating a Deleting a line of Permuting the order

line of code code of statement.
• In detail example is provided in the next slide.

124
Test Case Design

Mutation Testing
Public int Segment (int t[], int l, int u) {
// Assume t is in ascending order, and l<u,
//counts the length of the segment
// of t with each element l<t[i]<u
int k=0;
for(int i=0; i< t.length && t[i]<u; i++) {
if(t[i]>l) {
k=k+1;
} Here, we might consider deleting this
} statement then count would be zero for all
inputs, we might duplicate this line in which
return k;
case all counts will be doubled.
}

125
Test Case Design

Self Assessment Question

12. Which one of the given options is Mutation Testing?

a. Structural testing method

b. Specification-Based testing method
c. Experience-Based testing method

Answer: Structural testing method

126
Test Case Design

Self Assessment Question

13. Which one of the given options is the type of mutation testing?
i. Value Mutation
ii. Decision Mutation
iii. Statement Mutation

a. Only i
b. Only ii
c. Only i and ii
d. All i, ii and iii

Answer: All i, ii and iii 127

Test Case Design

Self Assessment Question

14. “Value Mutation involves changing values to reflect errors in reasoning about programs”. State
whether True or False.

a. True
b. False

Answer: True

128
Test Case Design

Self Assessment Question

15. Which one of the given options is/are is relevant to Statement Mutation?
i. Duplicating a line of code
ii. Deleting a line of code
iii. Permuting the order of statement.

a. Only i
b. Only ii
c. Only i and ii
d. All i, ii and iii

Answer: All i, ii and iii 129

Test Case Design

Code Complexity Testing

130
Test Case Design

Code Complexity Testing:

• It is the measurement of how complex a program code is.
• It is more likely a method to differentiate between more and less complex code as well as helps the
developer by giving the knowledge about the complexity of the developed code, so that they can
minimize it in later point in time.
• Lower the complexity of a program code reflects higher the quality of the program code.
• Approach: Cyclomatic complexity
• It is a software matrix developed by Thomas to measure the complexity of a program.
• It directly measures the number of independent path in a program i.e., in our source code.
• It is calculated using control flow graph.

131
Test Case Design

Code Complexity Testing:

Cyclomatic complexity
• Consists of nodes which are collection of commands and edges which indicates which should
be indicated next.
• We can calculate Cyclomatic complexity with the help of two formula: M=E-N+ 2*P
• Where M = complexity
• E = number of edges in the flow graph.
• N = number of nodes in the flow graph.
• P = number of nodes that have exit points
• In detail example is shown in the next slide.

132
Test Case Design

Code Complexity Testing:

• Cyclomatic complexity: Example I = 50

• IF I = 50 THEN J>
• IF J > K THEN K
• I=J
• ELSE
I=J I=K
• I=K
• ENDIF
• ENDIF END IF
• Print I
• Print J
• Print K END IF

• cyclomatic
complexity : PRINT I J K
• 8-7+2=3 133
Test Case Design

Self Assessment Question

16. ___________ Box Testing is Cyclomatic complexity.

a. Black
b. White
c. Yellow
d. Green

Answer: White

134
Test Case Design

Self Assessment Question

17. Cyclomatic complexity approach takes the help of control flow graph in order to calculate how
complex a program is. State whether True or False.

a. False
b. True

Answer: False

135
Test Case Design

Evaluating Test Adequacy Criteria

136
Test Case Design

Evaluating Test Adequacy Criteria.

• Testers are often faced with the decision of which criterion to apply to a given item under test given
the nature of the item and the constraints of the test environment (time, costs, resources).
• One source of information, the tester can use to select an appropriate criterion is the test adequacy
criterion hierarchy as shown in figure (next slide) below which describes a subsumes relationship
among the criteria.
• Satisfying an adequacy criterion at the higher levels of the hierarchy implies a greater thoroughness
in testing.
Example:
• Achieving all definition-use (def-use) path adequacy means the tester has also achieved both
branch and statement adequacy.
137
Test Case Design

A partial ordering for test adequacy criteria

All paths
Strong mutation

All def-use paths

All uses
Weak mutation

All c-uses, All p-uses,

some p-uses some c-uses

All c-uses all defs All p-uses

All branches

All statements 138

Test Case Design

• Support for evaluating test adequacy criteria comes from a theoretical treatment developed by Weyuker.
• She presents a set of axioms that allow testers to formalize properties which should be satisfied by any
good program-based test data adequacy criterion.
Testers can use the axioms to:
• Recognize both strong and weak adequacy criteria.
• Focus attention on the properties that an effective test data adequacy criterion should exhibit.
• Select an appropriate criterion for the item under test.
• Stimulate thought for the development of new criteria.

139
Test Case Design

Axioms are based on the following set of assumptions:

• Programs are written in a structured programming language.
• Programs are sese (single entry/single exit).
• All input statements appear at the beginning of the program.
• All output statements appear at the end of the program.

140
Test Case Design

The axioms/properties described by Weyuker are as follows:

Applicability Property:
• Whenever there is a program, there exists an adequate test set.
• Axiom means for all programs we should be able to design an adequate test set that properly tests
it.
• The test set may be very large so the tester will want to select representable points of the
specification domain to test it.
• If we test on all representable points, that is called an exhaustive test set.
• The exhaustive test set will surely be adequate since there will be no other test data that we
can generate.
• However, in past discussions we have ruled out exhaustive testing because in most cases it is
too expensive, time consuming, and impractical. 141
Test Case Design

2. Non exhaustive Applicability Property:

• For a program P and a test set T, P is adequately tested by the test set T, and T is not an exhaustive
test set.
• To paraphrase, a tester does not need an exhaustive test set in order to adequately test a program.
3. Monotonicity Property:
• If a test set T is adequate for program P, and if T is equal to, or a subset of T , then T is adequate for
program P
4. Inadequate Empty Set:
• In empty test set is not an adequate test for any program.
• If a program is not tested at all, a tester cannot claim it has been adequately tested.
• Note that these first four axioms are very general and apply to all programs independent of
programming language and equally apply to uses of both program- and specification-based testing.
For some of the next group of axioms this is not true. 142
Test Case Design

5. Anti-extensionality Property:
• There are programs P and Q such that P is equivalent to Q.
• T is adequate for P, but T is not adequate for Q.
• We can interpret this axiom as saying that just because two programs are semantically equivalent
(they may perform the same function) does not mean we should test them the same way.
• Their implementations (code structure) may be very different.
• If programs have equivalent specifications then their test sets may coincide using black box testing
techniques, but this axiom applies to program-based testing and it is the differences that may occur in
program code that makes it necessary to test P and Q with different test sets.

143
Test Case Design

6. General Multiple Change Property:

• There are programs P and Q that have the same shape, and there is a test set T such that T is
adequate for P, but is not adequate for Q.
• Here, Weyuker introduces the concept of shape to express a syntactic equivalence.
• It states that two programs are the same shape if one can be transformed into the other by applying
the set of rules shown below any number of times:
1. Replace relational operator r1 in a predicate with relational operator r2.
2. Replace constant c1 in a predicate of an assignment statement with constant c2.
3. Replace arithmetic operator a1 in an assignment statement with arithmetic operator a2.
• Axiom 5 says that semantic closeness is not sufficient to imply that two programs should be tested in
the same way.
• Given this definition of shape, Axiom 6 says that even the syntactic closeness of two programs is not
strong enough reason to imply they should be tested in the same way. 144
Test Case Design

7. Anti-decomposition Property:
• There is a program P and a component Q such that T is adequate for P,.
• T is the set of vectors of values that variables can assume on entrance to Q for some t in T, and T is
not adequate for Q.
• This axiom states that although an encompassing program has been adequately tested, it does not
follow that each of its components parts has been properly tested.
Implications for this axiom are:
• A routine that has been adequately tested in one environment may not have been adequately
tested to work in another environment, the environment being the enclosing program.
• Although we may think of P, the enclosing program, as being more complex than Q it may not
be. Q may be more semantically complex; it may lie on an unexecutable path of P, and thus
would have the null set, as its test set, which would violate Axiom 4. 145
Test Case Design

8. Anti-decomposition Property:
• There are programs P and Q, and test set T, such that T is adequate for P.
• The set of vectors of values that variables can assume on entrance to Q for inputs in T is adequate for
Q.
• T is not adequate for P; Q (the composition of P and Q).
• Paraphrasing this axiom we can say that adequately testing each individual program component in
isolation does not necessarily mean that we have adequately tested the entire program (the program as
a whole).
• When we integrate two separate program components, there are interactions that cannot arise in the
isolated components. Axioms 7 and 8 have special impact on the testing of object oriented code.

146
Test Case Design

9. Renaming Property:
• If P is a renaming of Q, then T is adequate for P only if T is adequate for Q.
• A program P is a renaming of Q if P is identical to Q expect for the fact that all instances of an
identifier, let us say a in Q have been replaced in P by an identifier, let us say b, where b does not
occur in Q, or if there is a set of such renamed identifiers.
• This axiom simply says that an inessential change in a program such as changing the names of the
variables should not change the nature of the test data that are needed to adequately test the
program.
10. Complexity Property:
• For every n, there is a program P such that P is adequately tested by a size n test set, but not by any
size n 1 test set.
• This means that for every program, there are other programs that require more testing. 147
Test Case Design

10. Statement Coverage Property:

• If the test set T is adequate for P, then T causes every executable statement of P to be executed.
• Ensuring that their test set executed all statements in a program is a minimum coverage goal for a
tester.
• A tester soon realizes that if some portion of the program has never been executed, then that portion
could contain defects: it could be totally in error and be working improperly.
• Testing would not be able to detect any defects in this portion of the code.
• This axiom implies that a tester needs to be able to determine which statements of a program are
executable. It is possible that not all of program statements are executable. Unfortunately, there is no
algorithm to support the tester in the latter task, but Weyuker believes that developers/testers are quite
good at determining whether or not code is, or is not, executable.
148
Test Case Design

Self Assessment Questions

18. Which one of the given options is used are used by Tester?
i. Recognize both strong and weak adequacy criteria.
ii. Focus attention on the properties that an effective test data adequacy criterion should exhibit.
iii. Select an appropriate criterion for the item under test.

a. Only i
b. Only ii
c. Only i and ii
d. All i, ii and iii

Answer: All i, ii and iii 149

Test Case Design

Assignment
1. Explain black box and white box approach.
2. Explain the addition techniques that must be considered while designing quality test cases.
3. Give a comparative study between static and dynamic testing.
4. Explain test adequacy criteria in detail.
5. Explain data flow testing with an suitable example.
6. Take a c program which generates a prime number from 1 to 100.
a. Perform data flow testing on it.
b. Explain the definition use association as well as the definition use paths of each variable for
the mentioned program with proper diagram step by step.
c. Perform mutation testing on the mentioned program.
d. Perform cyclomatic testing on the mentioned program.
7. Explain the strategies involved while evaluating test adequacy criteria.
150
Test Case Design

Summary
The initial phase of compatibility testing is to define the set of environments or platforms the application is
expected to work on.
• Condition testing also is known as Predicate coverage testing, each Boolean expression is predicted as
TRUE or FALSE.
• Test adequacy criteria is for choosing the appropriate test data.
• The purpose of Multiple condition testing is to test the different combination of conditions to get 100%
coverage. To ensure complete coverage, two or more test scripts are required which requires more efforts.
• White Box technique involves execution of all the executable statements in the source code at least once.
• Domain Testing Involves testing software in which a minimum number of inputs are used to test the output
of a system, to be sure that the system does not accept invalid and input values that are out of range.
• Testers are often faced with the decision of which criterion to apply to a given item under test given the
nature of the item and the constraints of the test environment (time, costs, resources).

151
Test Case Design

Document Links

Topics URL Notes

Test-case-design-te https://reqtest.com/testing-blog/test-case-design-
chniques techniques/
Requirements https://www.tutorialspoint.com/software_testing
based testing _dictionary/requirements_based_testing.htm
https://www.tutorialspoint.com/software_testing
Random testing
_dictionary/random_testing.htm
https://www.tutorialspoint.com/software_testing
Cause effect graph
_dictionary/cause_effect_graph.htm
https://www.guru99.com/compatibility-testing.ht
Compatible testing
ml
https://www.tutorialspoint.com/software_testing
_dictionary/documentation_testing.htm
Document testing
http://myowntestingspot.blogspot.com/2011/11/
what-is-user-documentation-testing.html
This link explains about
test-case-design-techniques
This link explains about requirements
based testing
This link explains about random
testing.
This link explains about cause effect
graph
This link explains about compatible
testing in software testing
This link explains about document
testing in software testing.
152
Test Case Design

Document Links
Topics URL Notes
http://www.testingbrain.com/blackbox/domain-testing This link explains about domain
Domain testing
.html testing
http://www.brainkart.com/article/Test-adequacy-criter This link explains about
Test-adequacy-criteria
ia_9154/ Test-adequacy-criteria
https://www.360logica.com/blog/difference-between-s This link draw a comparison
Static vs. Dynamic testing
tatic-testing-and-dynamic-testing/ between static and dynamic testing
Coverage and control flow http://www.brainkart.com/article/Coverage-and-Contr This link explains about coverage
graph ol-Flow-Graphs_9155/ and control flow graph in detail.
https://www.tutorialspoint.com/software_testing_dicti This link explains about Cyclomatic
Cyclomatic Complexity
onary/cyclomatic_complexity.htm Complexity
This link explains how definition
Definition usage path in http://www.inf.ed.ac.uk/teaching/courses/st/2017-18/ usage path is computed for each
data flow testing Ch13.pdf variable involved in a program
code.
This link explains about how to
Evaluating test adequacy https://www.brainkart.com/article/Evaluating-Test-Ade
evaluate test adequacy criteria in
criteria quacy-Criteria_9159/
software testing.
153
Test Case Design

Video Links

Topics URL Notes

https://www.youtube.com/watch?v=TIDAG This link explains coverage and control
Control flow graph
aXiPWA flow graph.

https://www.youtube.com/watch?v=LRlToF This link explains how to start with data

Data flow testing
zm3lg&t=3s flow testing.
This link explains about definition use
https://www.youtube.com/watch?v=0-Yzb association for a variable involved in a
Data flow testing
A_9Ogs&t=1s program code in the context of data flow
testing.
This link draw a comparison between
Static VS Dynamic https://www.youtube.com/watch?v=olmkr
static and dynamic testing
Testing eRoTFQ

Cyclomatic https://www.youtube.com/watch?v=x3Kr3 This link explains about coverage and

Complexity Etm2Cg control flow graph in detail
154
Test Case Design

E-Book Links

Topics URL Page Number

Overview of https://www.tutorialspoint.com/software_testing/softw
All
software testing are_testing_tutorial.pdf

http://www.softwaretestinggenius.com/download/staqtpsn
Software testing All
.pdf

155