14737_module 2 - types of testing

7/28/2019 14737_Module 2 - Types of Testing

1/46

WCTCopyright Webtek Labs Pvt Ltd

1

Module 2

Types of Testing


2/46


2

Different Types of Testing

Dynamic v/s Static testing Development v/s Independent testing

Blackv/s White Box testing

Behavioral v/s Structural testing

Automated v/s Manual testing

Sanity/Smoke and Acceptance testing

Regression testing

Exploratory and Monkey testing

Debugging v/s Bebugging


3/46


3

Dynamic v/s Static

Static Testing: This testing refers to testing

something thats not running i.e. examining and

reviewing it.

Dynamic Testing: Testing that involves testing,

running and using the software. These are theValidation activities. Unit Tests, Integration Tests,

System Tests and Acceptance Tests are few of the

Dynamic Testing methodologies.


4/46


4

Dynamic v/s Static (Contd.)

Static Testing:

Also known as Dry Run Testing

This is a form of Software Testing where the software

isnt actually used.

Methods like Code Review, Inspection, Walkthrough

are used.

Also applies to White Box Testing techniques- Syntax

checking and manually reading the code are methods

of static testing


5/46


5

Code Review :

Systematic examination of source code

In a code review, a defect is a block of code which does not

properly implement its requirements, which does not function

as the programmer intended, or which is not incorrect but

could be improved (e.g. it can be made more readable or its

performance could be improved).

Static Testing (Contd.)


6/46


6

Inspection :

Refers to review of any work product by trainedindividuals who look for defects using a well

defined process. The goal of the inspection is for all of the

inspectors to reach consensus on a work productand approve it for use in the project.

For example, if the team is inspecting a softwarerequirement specification, each defect will be textin the document which an inspector disagreeswith.



7/46WCTCopyright Webtek Labs Pvt Ltd7

Walkthrough :

A form of software peer review in which adesigner or programmer leads members of thedevelopment team and other interested partiesthrough a software product.

Software product might be a software designdocument or program source code, use cases,business process definitions, test casespecification etc.

Participants ask questions and make comments

about possible errors, violation of developmentstandards and other problems.

Objective of walkthrough is to gain feedbackabout the technical quality of document and/ or to

familiarize the audience with the content.




Participants in Walkthrough :

The Walkthrough Leader: conducts thewalkthrough, handles administrative tasks andensures orderly conduct (he is often the author)

The Recorder notes all anomalies (potentialdefects), decisions and action items identifiedduring the walkthrough meeting.

The Author presents the software product instep-by-step manner at the walkthrough meeting,and is probably responsible for completing mostaction items.




Development v/s Independenttesting

Development testing denotes the aspects of test design and implementation

most appropriate for the team of developers to undertake. This is in contrast to

Independent Testing. In most cases, test execution initially occurs with the developer

testing group who designed and implemented the test, but it is a good practice for the

developers to create their tests in such a way so as to make them available to

independent testing groups for execution.

Independent testing denotes the test design and implementation most appropriately

performed by someone who is independent from the team of developers. You can

consider this distinction a superset, which includes Independent Verification &

Validation. In most cases, test execution initially occurs with the independent testing

group that designed and implemented the test, but the independent testers should

create their tests to make them available to the developer testing groups for execution.



Black v/s White box testing



Black v/s White box testing

The purpose of a black-box test is to verify the unit's specified

function and observable behavior without knowledge of how the

unit implements the function and behavior. Black-box tests focus

and rely upon the unit's input and output.

A white-box test approach should be taken to verify a unit'sinternal structure. Theoretically, you should test every possible

path through the code, but that is possible only in very simple

units. At the very least you should exercise every decision-to-

decision path (DD-path) at least once because you are then

executing all statements at least once. A decision is typically an if-

statement, and a DD-path is a path between two decisions.



Behavioral v/s Structural testing

Behavioral Testing: This is another name commonly

given to Black Box Testing as you are testing the

behavior of the software when its used without knowing

the internal logics how they are implemented.

Structural Testing: This is another name commonlyused for white Box testing in which you can see and use

the underlying structure of the code to design and run

your tests.



Automated v/s Manual

Automated Testing: Software testing assisted with

software tools that require no operator input, analysis,or evaluation.

Manual Testing: That part of software testing that

requires human input, analysis, or evaluation.



Sanity/Smoke, Acceptance testing

Sanity/Smoke Testing: The testing that exercise the system end to

end, that is non-exhaustive, ascertaining that the most crucial

functions of a program work, but not bothering with finer details is

referred to as Smoke/Sanity testing. It is a cursory testing; it is

performed whenever a cursory testing is sufficient to prove the

application is functioning according to specifications. It normally

includes a set of core tests of basic GUI functionality to demonstrate

connectivity to the database, application servers, printers, etc.

Acceptance testing: Acceptance testing is the final test action

before deploying the software. The goal of acceptance testing is to

verify that the software is ready and can be used by your end users

to perform those functions and tasks for which the software was built.



Regression testingThe selective retesting of a software system that has been

modified to ensure that any bugs have been fixed and that

no other previously working functions have failed as a

result of the modifications and that newly added features

have not created problems with previous versions of the

software.

Regression testing is initiated after a programmer has

attempted to fix a recognized problem or has added source

code to a program that may have inadvertently introduced

errors. It is a quality control measure to ensure that the



Exploratory and monkey testing

Exploratory testing involves simultaneously learning,planning, running tests, and reporting /troubleshooting results.

Monkey testing- This is another name for "Ad HocTesting"; it comes from the joke that if you put 100monkeys in a room with 100 typewriters, randomly

punching keys, sooner or later they will type out aShakespearean sonnet. So every time one of your adhoc testers finds a new bug, you can toss him abanana. The use of monkey testing is to simulatehow your customers will use your software in realtime.



Debugging v/s bebugging

Debugging: The process of finding and removing the

causes of failures in software. The role is performed by a

programmer.

Bebugging: The process of intentionally adding known

faults to those already in a computer program for thepurpose of monitoring the rate of detection and removal,

and estimating the number of faults remaining in the

program


18/46WCTCopyright Webtek Labs Pvt Ltd

18

Black Box & White BoxTesting Techniques



19

Black-Box Testing

Program viewed as a Black-box, whichaccepts some inputs and produces someoutputs

Test cases are derived solely from the

specifications, without knowledge of theinternal structure of the program.



20

Functional Test-Case Design Techniques

Equivalence class partitioning

Boundary value analysisCause-effect graphing

Error guessing



21

Equivalence Class Partitioning

Partition the program input domain into equivalenceclasses (classes of data which according to thespecifications are treated identically by the program)

The basis of this technique is that test of a representativevalue of each class is equivalent to a test of any othervalue of the same class.

Identify valid as well as invalid equivalence classes

For each equivalence class, generate a test case to

exercise an input representative of that class



22

Example

Example: input condition 0



23

Guidelines for Identifying Equivalence Classes

Input Condition Valid Eq. Classes Invalid Eq. ClassesRange of values

(eg. 1 - 200)

One Valid

(value within range)

Two Invalid

(one outside each end ofrange)

number N valid values

One valid Two invalid

(none, more than N)

Set of input values eachhandled differently bythe program (Eg. A, B,

C)

One valid

(for each value)

One invalid

(any value not in validinput set )

Must be condition

(Eg. Id name must begin

with a letter )

One

(Eg. It is a letter)

One

(Eg. It is not a letter)


24/46

WCTCopyright Webtek Labs Pvt Ltd24

Identifying Test Cases forEquivalence Classes

Assign a unique number to each equivalenceclass

Until all valid equivalence classes have beencovered by test cases, write a new test casecovering as many of the uncovered validequivalence classes as possible.

Each invalid equivalence class cover by aseparate test case.


25/46


Boundary Value Analysis

Design test cases that exercise values that lie atthe boundaries of an equivalence class and for

situations just beyond the ends.

Example: input condition 0


26/46


Cause Effect Graphing

A technique that aids in selecting test cases for

combinations of input conditions in a systematicway.


27/46


Cause Effect Graphing Technique

1. Identify the causes (input conditions) and effects(output conditions) of the program under test.

2. For each effect, identify the causes that canproduce that effect. Draw a Cause-Effect Graph.

3. Generate a test case for each combination ofinput conditions that make some effect to betrue.


28/46


Example

Consider a program with the following:

Input conditions (Cause) Output conditions

(Effect)

c1: command is credit e1: print invalidcommand

c2: command is debit e2: print invalid A/C

c3: A/C is valid e3: print debitamount not valid

c4: Transaction amount e4: debit A/C

e5: credit A/C


29/46


Example: Cause-Effect Graph

C2

C3

C4

E1

E2

E3

E4

OR

C1 NOT

NOT

NOT

AND

AND

NOT

AND

E5AND

AND

AND


30/46


ExampleDecision table showing the combinations of input conditionsthat make an effect true. (summarized from Cause EffectGraph)

Write test cases to exercise each Rule in decision Table.Example:

C1C2C3C4

00--

1-

0

-

-1

1

0

-1

1

1

1-

1

1

E1E2E3E4E5

1

1

1

1

1


31/46


Error Guessing

From intuition and experience, enumerate a listof possible errors or error prone situations andthen write test cases to expose those errors.


32/46


White Box Testing

White box testing is concerned with the degree towhich test cases exercise or cover the logic (sourcecode) of the program.

White Box Test case design techniques

Statement coverage Basis PathTesting

Decision coverage Loop testingCondition coverage Data flow testingDecision-condition coverageMultiple condition coverage


33/46


White Box Test-Case Design

Statement coverage

write enough test cases to execute everystatement at least once

TER (Test Effectiveness Ratio)

TER1 = statements exercised / total statements


34/46


Example

void function eval (int A, int B, int X )

{

if ( A > 1) and ( B = 0 )

then X = X / A;if ( A = 2 ) or ( X > 1)

then X = X + 1;

}

Statement coverage test cases:

1) A = 2, B = 0, X = 3 ( X can be assigned any value)


35/46



Decision coverage

write test cases to exercise the true and falseoutcomes of every decision

TER2 = branches exercised / total branches

Condition coverage

write test cases such that each condition in a

decision takes on all possible outcomes at least once may not always satisfy decision coverage


36/46


Example

void function eval (int A, int B, int X)

{

if ( A > 1) and ( B = 0 ) then

X = X / A;if ( A = 2 ) or ( X > 1) then

X = X + 1;

}

Decision coverage testcases:

A > 1and

B = 0

A = 2or

X > 1

X = X+1

X = X/ A

a

cT

F

b

eT

F

d

2) A = 2, B = 1, X = 1 (abe)

1) A = 3, B = 0, X = 3 (acd)


37/46


Example

Condition coverage test casesmust cover conditions

A>1, A1, X 1and

B = 0

A = 2or

X > 1

X = X+1

X = X/ A

a

cT

F

b

eT

Y

d


38/46



Decision Condition coverage

write test cases such that each condition in adecision takes on all possible outcomes at least onceand each decision takes on all possible outcomesat least once

Multiple Condition coverage

write test cases to exercise all possiblecombinationsof True and False outcomes of conditions within adecision


39/46


Example

Decision Condition coverage testcases must cover conditions

A>1, A1, X 1 and B = 0) T, F( A = 2 or X > 1) T, F

Test cases:1) A = 2, B = 0, X = 4 (ace)

2) A = 1, B = 1, X = 1 (abd)

A > 1and

B = 0

A = 2or

X > 1

X = X+1

X = X/ A

a

cT

F

b

eT

Y

d


40/46


Example

Multiple Condition coveragemust cover conditions

1) A >1, B =0 5) A=2, X>1

2) A >1, B !=0 6) A=2, X


41/46


Basis Path Testing

1. Draw control flow graph of program from the

program detailed design or code.

2. Compute the Cyclomatic complexity V(G) of theflow graph using any of the formulas:

V(G) = #Edges - #Nodes + 2

or V(G) = #regions in flow graphor V(G) = #predicate Nodes + 1


42/46


Example

1

2

34

5 10

6

7

8

9

R4

R3

R2

11 12

13

R1

R6

R5

V(G) = 6 regions

V(G) = #Edges - #Nodes+ 2

= 17 - 13 + 2 = 6V(G) = 5 predicate-nodes

+ 1 = 6

6 linearlyindependent paths


43/46


Basis Path Testing (contd)

3. Determine a basis set of linearly independentpaths.

4. Prepare test cases that will force execution ofeach path in the Basis set.

.
http://localhost/var/www/apps/conversion/tmp/WCT%20Slides%20-%20Jan%2008/testing2_iitkh.ppthttp://localhost/var/www/apps/conversion/tmp/WCT%20Slides%20-%20Jan%2008/testing2_iitkh.ppt


44/46


Loop Testing

Aims to expose bugs in loops

Fundamental Loop Test criteria

1) bypass the loop altogether

2) one pass through the loop3) two passes through the loop before exiting

4) A typical number of passes through the loop, unlesscovered by some other test


45/46


Data Flow Testing

Select test paths of a program based onthe Definition-Use (DU) chain of variablesin the program.

Write test cases to cover every DU chainis atleast once.


46/46

Thank You

Any Questions ?

14737_module 2 - types of testing

Documents