Unit II

TEST CASE DESIGN

 Test Case Design Strategies
Test case:

It a document, which has a set of test data, pre conditions, expected

results and post conditions, developed for a particular test scenario in order
to verify compliance against a specific requirement.

Needs of Test Case Design:

• Used for regression testing
• Early buy detection
• Reusability of test cases
• It can be reviewable
• It provide traceability to requirement
• Higher quality software product can be delivered
Test case parameters are,

• Test case ID
• Test scenario
• Test case description
• Test steps
• Test data
• Expected result
• Test parameters
• Actual result
• Environment information
• Comments.ets
Testing Strategies:
Basic testing strategies,
1. Black Box Testing (BBT)
2. White Box Testing (WBT)

Black Box Testing Strategies:

It focus on functional requirement’s of the software
It is attempts to find,
• Incorrect or missing function
• Errors in data structures
• DB access errors
• Initialization / Termination errors
White Box Testing Strategies:
• It focus on inner structure of the software to be tested
• It examines basic programs structure and it drives the test data from the
program
USING BLACK BOX APPRAOCHES TO TETS CASE DESIGN

• Black box approach is a build level testing technique

• Inputs and outputs are taken to design the test cases
• There is no time to test all possible inputs, because it is expensive
• The methods of black box testing are,
– Equivalence class partitioning
– Boundary value analysis
– State transition testing
– Cause is effect graphing
– Error guessing
– Requirement based testing
– Positive/ negative testing
– Random Testing
– User Documentation testing
RANDOM TESTING
• It is also called as monkey testing
• It is performed when there is no enough time to write and execute the tests and test cases
• All the test inputs are generated randomly (often using tool)
Characteristics:
• It is performed where the defects are NOT identified in regular intervals
• Random input is used to test the systems reliability and performance
• it saves time and effort
Steps:
• Random inputs are identified to be evaluated against the system
• Test inputs are selected independely from test domain
• Tests are executed using those random inputs
• Record the results and compare against the expected outcomes
• Reproduce / replicate the issue and raise defects, fix and retest
REQUIREMENT BASED TESTING
• Requirements based testing is a testing approach in which test cases,
conditions and data are derived from requirements
Stages:
1. Defining test completion criteria
2. Design test cases
3. Execute tests
4. Verify the results
5. Verify test coverage
6. Track and manage tracks
Process:
7. Validate requirement against objectives
8. Apply scenario against requirement
9. Perform initial ambiguity review
10. Perform domain expert reviews
11. Create cause – effect graph
6. Logical consistency check by RBT
7. Review of test cases by specification writes
8. Review of test cases by users
9. Review of test cases by developers
10. Walk test cases through design
11. Walk test cases through code
12. Execute test cases against code

Types:
1. Explicit requirement – as a part of requirement specification
2. Implicit requirement – not documented

It checks,
• Consistency
• Correctness
• Completeness
• Traceability
RTM: Requirement Traceability Matrix

• RTM is a table that shows the many to many relationship between

requirement and test cases.
• Each requirement is mapped to one or more test cases
• Each test tests one or more requirement
RTM work flow:

Requirements

Request for proposal

Verification
Tasks

Deliverables

Testing
 Sample requirement specification format
S.No Requirement Description Priority (high, med,
identifier low)

Sample requirement traceability matrix

Requirement Description Priority Test Test cases Phase of

ID (H,M,L) condition ID’s testing
 Boundary value analysis (BVA)
• It is black box testing
• Used to find errors at the boundaries of input domain rather than finding
errors at center
• Based on boundaries between partitions
• Here we test both valid and invalid boundaries
Eg:
consider a printer that has a input option of no of copies to be made from 1 to
99.
Invalid boundary valid boundary invalid

. . . . . . . . . . . . 0 1 2 3 . . . . . . . . . . . . . . . . . . . . . . . . .99 100 . . . . . . . . . .
Boundary value conditions

Min - pass
Min – 1 - fail
Min + 1 - pass
Max - pass
Max +1 - fail
Max – 1 - pass

In above example,
Min= 1
Max = 99

Find the solution.

Guidelines for BVA:

• The rationale behind boundary value analysis is that errors tend to occur
near the extreme values of an input variables
• Programs written in non strongly typed language are more appropriate
candidate for BVA
• In our discussion we assume a program p accepting 2 inputs,
• Boundary in equalities of ‘n’ input variables define an n-dimensional input
space
• BVA is to select input variables values for min, above min, normal value,
below max, max.
• Variables are program dependent, language dependant, bounded discrete
unbounded discrete and logical variables
State Based Testing
• State Transition is based on the concepts of states and finite-state machines.

• allows the tester to view the developing software in

– term of its states,

– transitions between states, and

– the inputs and events that trigger state changes.

Use

Gives the tester an additional opportunity to develop test cases to detect

defects that may not be revealed using the input/output condition as well
as cause-and-effect views presented by equivalence class partitioning
and cause-and-effect graphing.
 Definition
• A state is an internal configuration of a system or component. It is defined
in terms of the values assumed at a particular time for the variables that
characterize the system or component.
• A finite-state machine is an abstract machine that can be represented by a
state graph having a finite number of states and a finite number of
transitions between states.
 When STG developed
• During the specification phase a state transition graph (STG) may be generated

for the system as a whole and/or specific modules.

• In object oriented development the graph may be called a state chart.

STG/state charts are commonly depicted by a set of nodes (circles, ovals,

rounded rectangles) which represent states.

• These usually will have a name or number to identify the state.

• A set of arrows between nodes indicate what inputs or events will cause a

transition or change between the two linked states.

• Outputs/actions occurring with a state transition are also depicted on a link

or arrow.
Simple state transition
graph
• S1 , S2 - two states of interest.

• Black dot – is a pointer to the initial state from outside the machine.

• The arrows display inputs/actions that cause the state transformations in the
arrow directions

– For example, the transition from S1 to S2 occurs with input, or event B.

Action 3 occurs as part of this state transition. This is represented by
the symbol “B/act3.
• For large systems and system components, state transition graphs can
become very complex.
• Developers can nest them to represent different levels of abstraction.
• This approach allows the STG developer to group a set of related states
together to form an encapsulated state that can be represented as a single entity
on the original STG.

• The STG developer must ensure that this new state has the proper connections
to the unchanged states from the original STG.

• Another way to simplify the STG is to use a state table representation which
may be more concise

State Table
• The state table lists the inputs or events that cause state transitions.
• For each state and each input the next state and action taken are listed.
• Therefore, the tester can consider each entity as a representation of a state
transition
A state
table
 Review
s
• We will assume that the STGs have been prepared by developers or analysts as
a part of the requirements specification.
• TheSTGs should be subject to a formal inspection when
the requirement/specification is reviewed.
• This step is required for organization assessed at TMM level 3 and higher
 Points to be analyzed in
reviews
• It is essential that testers be present at the reviews.

• From the tester’s view point the review should ensure that
– the proper number of states are represented,

– each state transition (input/output/action) is correct,

– equivalent states are identified, and

• unreachable and dead states are identified.

• After the STG has been reviewed formally the tester should plan
appropriate test cases.
• A simple approach might be to develop tests that insure that all states
are entered.
 Transitions to be tested
are
• Input A in S1

• Input A in S2

• Input B in S1

• Input B in S2

• Input C in S1

• Input C in S2
Cause-and-effect
graphing
 Cause-and-effect
graphing
Weakness with equivalence class partitioning is

• it does not allow testers to combine conditions.

• Cause-and-effect graphing is a technique that can be used to
combine conditions and derive an effective set of test cases.
• The specification must be transformed into a graph.
• Tester should have knowledge of Boolean Logic.
• The graph must be converted to a decision table that the tester uses to
develop test cases.
• Disadvantage – Developing the graph for a complex module with
many combinations of inputs is difficult and time consuming.
The steps in developing test cases with a cause-and-effect graph

1. The tester must decompose the specification of a complex software

component into lower-level units.
2. For each specification unit, the tester needs to identify causes and their effects.
• A cause is a distinct input condition or an equivalence class of
input conditions.
• An effect is an output condition or a system transformation.
Putting together a table of causes and effects helps the tester to
record the
necessary details.
3. From the cause-and-effect information, a Boolean cause-and-effect graph
is created.
• Nodes in the graph are causes and effects.
• Causes are placed on the left side of the graph and effects on the right.
• Logical relationships are expressed using standard logical operators.
(AND , OR , NOT)
4. The graph may be annotated with constraints that describe combinations
of causes and/or effects
5. The graph is then converted to a decision table.
6. The columns in the decision table are transformed into test
cases.
• The input conditions, or causes are as follows:
– C1: Positive integer from 1 to 80
– C2: Character to search for is in string
• The output conditions, or effects are:
– E1: Integer out of range
– E2: Position of character in string
– E3: Character not found
• The rules or relationships can be described as
follows:
– If C1 and C2, then E2.
– If C1 and not C2, then E3.
– If not C1, then E1.
• Based on the causes, effects, and their relationships, a cause-and-effect
graph to represent this information is shown in Figure 4.5
• The next step is to develop a decision table.
• The decision table reflects the rules and the graph and shows the
effects for all possible combinations of causes.
• Columns list each combination of causes, and each column
represents a test case.
• Given n causes this could lead to a decision table with 2n entries,
thus
indicating a possible need for many test cases.
• In this example, since we have only two causes, the size and
complexity of the decision table is not a big problem.
• Environmental constraints and unlikely combinations may reduce the
number of entries and subsequent test cases.
• A decision table will have a row for each cause and each effect.
• The entries are a reflection of the rules and the entities in the
cause and effect graph.
– “1” for a cause or effect that is present
– “0” for a cause or effect that is absent
• If the existing string is “abcde,” then possible tests are the
following:
Inputs Length Character to search for Outputs
T1 5 c 3
T2 5 w Not found
T3 90 Integer out of
range

• Advantages
– development of the rules and the graph from the specification allows a
thorough inspection of the specification.
Compatibility Testing
•Compatibility is the ability of living and work together without any
discrepancy.
•Compatible software applications also work on same setups. For example, if
Google.com site is compatible, then it should open in all browsers
and
operating system.
•Compatibility is a non- functional testing to ensure customer satisfaction.
•It is to determine whether your software application or product is proficient
enough to run in different browsers, database, hardware, operating system,
mobile devices and networks.
•Application could also impact due to different versions, resolution, internet
speed and configuration etc.
•Hence it’s important to test the application in all possible manners to reduce
failures and overcome from embarrassments of bug’s leakage.
Parameters of Software
compatibility testing:
Hardware :
It checks software to be compatible with different hardware configurations .
Operating Systems:
It checks your software to be compatible with different Operating Systems like
Windows , Unix , Mac OS etc.
Software:
It checks your developed software to be compatible with other software's.
For example: MS Word application should be compatible with other software like
MS Outlook,MS Excel , VBA etc.
Network:
Evaluation of performance of system In network with varying parameters such as
Bandwidth, Operating speed, Capacity.
It also checks application in different networks with all parameters mentioned earlier.
Browser:
It checks compatibility of your website with different browsers like Firefox ,
Google Chrome , Internet Explorer etc.
Devices :
It checks compatibility of your software with different devices like USB port
Devices, Printers and Scanners, Other media devices and Blue tooth.
Mobile:
Checking you software is compatible with mobile platforms like Android , iOS
etc.
• Versions of the software:

– It is verifying you software application to be compatible with

different versions of software.For instance checking your Microsoft
Word to be compatible with Windows 7, Windows 7 SP1 , Windows

7 SP 2 , Windows 7 SP 3.
• Backward compatibility Testing

– Testing of the application or software in old or previous versions. It is

also known as downward compatible.

• Forward Compatibility Testing

– Testing of the application or software in new or upcoming versions. It

is also known as forward compatible.

Techniques for Compatibility Testing

 Horizontal combination
 Intelligent Sampling
Compatibility matrix for a mail
application
 Tools for compatibility testing
Adobe Browser Lab - Browser Compatibility Testing:

This tool helps us to check your application in different browsers.

Virtual Desktops - Operating System Compatibility:

This is used to run the applications in multiple operating systems as

virtual machines. N Number of systems can be connected and compare the
results.

Common Compatibility testing defects

 Changes in UI ( look and feel)

 Change in font size
 Alignment related issues
 Change in CSS style and color
 Scroll bar related issues
 Content or label overlapping
 Broken tables or Frames
User Documentation Testing
 Documentation Testing
• Documentation Testing involves testing of the documented artifacts that
are usually developed before or during the testing of Software.
• It is a type of non-functional testing.
• Documentation is as important to a product’s success as the product itself.
• If the documentation is poor, non-existent, or wrong, it reflects on the quality
of the product and the vendor.
• Much of the non-code is the software documentation, which requires
much effort to produce.
• Documentation is now a major part of a software system.
– It might exceed the amount of source code!
– It might be integrated into the software (e.g., help system)
• Testers have to cover the code and the documentation.
– Assuring that the documentation is correct is part of a software
tester’s job.
 Classes of software documentation

• Packaging text and graphics

• Marketing material, ads, and other inserts
• Warranty/registration
• End User License Agreement (EULA)
• Labels and stickers
• Installation and setup instructions
• User’s manual
• Online help
• Tutorials, wizards, and computer-based training
• Samples, examples, and templates
• Error messages
 Importance of documentation
testing

• Improves usability
– Not all software was written for the Mac :-)

• Improves reliability
– Testing the documentation is part of black-box testing.

– A bug in the user manual is like a bug in the software.

• Lowers support cost

• The exercise of writing the documentation
helped debug the system.
 Testing software
documents

• Loosely coupled to the code:

– E.g., user manuals, packaging fliers.

– Apply techniques on specification testing and software inspection.
– Think of it as technical editing or proofreading.

• Tightly coupled to the code:

– E.g., documents are an integral part of the software, such as a training

system or TurboTax Deluxe (fancy videos, hyperlinked manual, etc).
– Apply techniques such as black-box and white-box testing.
Documentation testing checklist
• Audience:
– E.g., make sure documentation is not too novice or too advanced.
• Terminology:
– Is it suitable for the audience?
– Terms used consistently?
– Abbreviations for acronyms?
• Content and subject matter:
– Appropriate subjects covered?
– No subjects missing?
– Proper depth?
– Missing features described accidentally?
Advantages
• This is one of the most cost effective approaches to testing. If the
documentation is not right: there will be major and costly
problems.
• Documentation testing can start at the very beginning of the
software process and hence save large amounts of money, since
the earlier a defect is found the less it will cost to be fixed.
 Domain Testing
• It is software testing technique in which selecting a small no of test
cases from a infinite group of test cases.
• It is a type of functional testing
• It tests the product based on,
1. specified domain on,
2. domain/ application experience
3. testing skill
• To do this test you must understand the day by day business activities
for which the software is written
• This testing requires domain knowledge
Eg: domain
Banking, insurance, logistics, supply chain management
Steps:
• Start with obvious & simple tests
• Test each function sympathetically
• Test broadly before deeply
• Look for more powerful tests
• Expand your scope
• A domain might involve the values of any one variable or combination
of variables.
• The values that we pick to represent each equivalence class are the
most powerful members of each set.
• It exposes an error as any other member of its set.
Using White Box Approach To Test Design
White Box Testing:
• It is based on an analysis of internal structure of the component or
system
• It examines the program structure and drives test data from the
program logic code.
Other names:
• Glass box testing
• Clear box
• Open box
• Logic driven
• Path driven
• Structural testing
Testing techniques:
• Statement coverage
• Path coverage
• Program technique coverage
• Condition coverage
• Loop coverage
• Function coverage

 It is coding level testing strategy

 It ensures all the statements and condition have been executed
at least once.
 it helps to test small components / modules
 This strategy is implemented for design and code based control
Test adequacy criteria:
• It depends on program specification
• Test data adequacy criterion is a stooping rule.
• These rules are generally applied to know that whether enough
testing are done or not
Program based adequacy criterion:
• If the test data adequacy criterion deals structural prosperities
then it is known as “program based adequacy criterion”.
• It is white box testing.
• Here the focal point of adequacy criterion evaluation are,
1. logic and control structures
2. data flow
3. program flow
Uses:
• To reach the objectives of testing
• In terms of coverage that can be measured
• It’s a two level of testing
– Stooping rule
– Test cases
Categories :
1. Specification based
– All combination criterion
– Each choice used criterion
2. Program based
– Statement
– Branch
Coverage analysis:
• Prosperities of code by using test cases
• Used to set testing goals, develop and evaluate test data
Eg:
• Function coverage
• Condition coverage
• Path coverage
• Entry / exit coverage
Degree of coverage:
• If the coverage related testing goals is given as in the form of percentage then
it is said to be “ degree of coverage”
• Planned degree of coverage is given in the test plan
• When the test adequacy is fulfilled then planned degree of coverage is 100%.
• Sometimes it is not 100% due to
– Nature of units
– Lack of resources
– Project related issues
 STATIC TSTING VS STRUCTURAL TESTING
Static Testing:
• It is the testing of the software work products manually or with a set of
tools, but they are not executed
• It is done during verification process
• It does not need computer as the testing of program is done without
executing the program.
Eg:
– Reviewing
– Walkthrough
– Inspection, etc
Uses:
–It can start early in life cycle so early feedback an quality issues can be
established
–The rework cost most often relatively low
–Development productivity is increased
– different types of defects easily find.
When?
–Code work as per the functional requirement
–Code developed based on the design
–Code for any functionality has been missed out
–Code handles the errors properly or not

Static testing accesses the following:

–Requirement document
–Design documents
–User manuals
–Static testing tools

Static testing tool takes application code as input generates a varity of data
in the test process.
Static Testing:
1. Humans
2. Tools

Methods- human
3. Desk checking of the code
4. Code walkthrough
5. Code review
6. Code inspection

Desk checking of the code

• It helps to check the correctness of code
• It is done by person who produced the code
• It a comparison technique, to compare with code, design and specification
Code walkthrough

• It is a informal process to review any application and its related document

Eg: peer code review

•The meeting is usually led by the author of the document under review and
attended by other members of the team

•Before walkthrough meeting, the preparation by reviewers and then review report
with a list of findings

Formal inspection
• Inspection is the most formal form of reviews, strategy adopted during static
testing phase
• It helps to find all faults, violation and defects
• This inspection plan helps to,
•Statement purpose
•Work product to be inspected
•Team formation, roles and tasks to be done.

•Data collection forms

Stages of inspections:
• Planning
• Overview meeting
• Preparation
• Inspection meeting
• Rework
• Follow-up

Steps :
• Inspection team assembles at the agreed time of the inspection meeting
• Moderator asks the team to look the code , find any defect
1. Minor / Major
2. Systematic / Misexecution
• A scribe / recorder will document the defects found in an inspection meeting
2. Static Analysis By Tools:
It reduces the manual work , errors like
• If any unreachable code is available or not
• Variables declared but not used
• Mismatch in definition and assignment of values to variables.
• Use of non portable programming constructs
• Memory allocated
• Calculation of cyclomatic complexity

II. Structural testing:

It is a white box testing technique which takes into account the internal structure
of a system or components and ensures that each program statement performs its
intended function.
Code Functional Testing:

• It is called as “unit functional testing”

• It is a initial part of structural testing

• It is done by developers. They perform before subjecting the code to more

extensive code coverage testing or code complexity testing

Several methods,

• By knowing the input variables and expected output variables,

developers, develops does some test.

• It is possible to build a “debug version” of product by placing

intermediate print statements and making sure the program is passing
through the right loop and iterations right no of times

• The initial test is to run the product under a debugger or an integrated

development environment (IDE)
Coverge and Control Flow Graphs:

• “Code coverage” is a measure used to describe the degree to which the

source code of a program is tested by a particular test suite

• “Test coverage” measures the amount of testing performed by a set of

test.

For example,

(i) program statements;

(ii) decisions/branches (these influence the program flow of control);

(iii) conditions (expressions that evaluate to true/false, and do not contain any
other true/false-valued expressions);

(iv)combinations of decisions and conditions;

(v)paths (node sequences in flow graphs).

A program prime is an atomic programming unit.
All structured programs can be built from three basic primes-
• sequential (e.g., assignment statements),
• decision (e.g., if/then/else statements), and
• iterative (e.g., while, for loops).
Flow graph
• The flow graph can be used by the tester to evaluate the code with respect
to its testability as well as to develop white box cases.
• The nodes represent sequential statements, as well as decision
and looping predicates.
• For simplicity, sequential statements are often omitted or
combined as a block that indicates that if the first statement in
the block is executed, so are all the following statements in
the block.
• Edges in the graph represent transfer of control.
• The direction of the transfer depends on the outcome of the
condition in the predicate (true or false).
Covering Code Logic:

Two major payoffs for the tester:

(i) quantitative coverage goals can be proposed, and

(ii) commercial tool support is readily available to facilitate the tester‘s

work .

• The tester selects the logic element program statements to design

tests that focus on the execution of program statements.

• If the goal is to satisfy the statement adequacy/ coverage criterion,

then the tester should develop a set of test cases so that when the
module is executed, all (100%) of the statements are executed at
least once.
• Each decision element (if-then, case, loop) executes with all
possible outcomes at least once.
• In control flow model, all the edges in flow graph must be
exercised at least once.
• If the defect is a missing statement it may remain undetected
by tests satisfying complete statement coverage.
• Input values must ensure execution the true/false possibilities
for the decisions in line 4 (while loop) and line 5 (if
statement).
• Note that the if statement has a full else component, that is,
there is no else part. However, we include a test that covers
both the true and false conditions for the statement.
• test satisfies both the branch adequacy criterion and the
statement adequacy criterion
Below is a simple example showing the test cases for a decision
statement with a compound predicate.
• three conditions in its predicate:
(i) x <MIN,
(ii) y> MAX, and
(iii) not INT Z.
• Decision coverage only requires that we exercise at least once
all the possible outcomes for the branch or loop predicates as
a whole, not for each individual condition contained in a
compound predicate.
X=5 Min=6 y=8 MAX=7 z=8(All conditions true)
Note that these tests would not exercise the possible outcome for
married as false.
 Paths: Their Role in White Box-Based Test Design

• These tools typically calculate a value for a software attribute

called McCabe‘s Cyclomatic Complexity V(G) from a flow
graph.
• The cyclomatic complexity attribute is very useful to a tester.
• The complexity value is usually calculated from the control
flow graph (G) by the formula
V(G)=E-N+2 or V(G)=E-N+P
• The value E is the number of edges in the control flow
graph and N is the number of nodes.
• Uses - to provide an approximation of the number of test cases needed for branch
coverage in a module of structured code.

• Cyclomatic complexity provides an approximation of the effort of testability of a

module.

• The value of V(G) is used to approximate the testing time and resources required to test
a software module.

• The cyclomatic complexity value and the control flow graph give the tool for
developing test cases using the concept of a path.

• A path is a sequence of control flow nodes usually beginning from the entry node of a
graph through to the exit node.

• A path may go through a given segment of the control flow graph one or more times.
We usually designate a path by the sequence of nodes it encompasses.
1-2-3-4-5-7-4-8
• 1-2-3-4-8

• R represents the edge between nodes 4 and 8 .

Cyclomatic complexity is a measure of the number
of so-called independent paths in the graph.
• A set of independent paths for a graph is sometimes called a basis set.
• For most software modules it may be possible to derive a number of
basis sets.
• set of independent paths starting with the first path identified above.

(i) 1-2-3-4-8
(ii) 1-2-3-4-5-6-7-4-8
(iii)1-2-3-4-5-7-4-8
• The number of independent paths in a basis set is equal to the
cyclomatic complexity of the graph.
• Every path (as distinguished from independent paths) in a module
must be exercised by the test set at least once.
• It is the strongest program-based testing criterion, and it calls for

complete path coverage;

• Even in a small and simple unit of code there may be many paths

between the entry and exit nodes.

• Adding even a few simple decision statements increases the number

of paths.