Testing Techniques

Static Testing Techniques

Analysis of a program carried out without executing the program. Review Definition Review is a process or meeting during which a work product or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.

Types of Reviews
There are three general classes of reviews: Informal / peer reviews/technical Semiformal / walk-through Formal /inspections.

Peer Review
Simply giving a document to a colleague and asking them to look at it closely which will identify defects we might never find on our own.

Walkthrough
A review of requirements, designs or code

characterized by the author of the material under review guiding the progression of the review.
A 'walkthrough' is an informal meeting for evaluation

or informational purposes. Little or no preparation is usually required. These are led by the author of the document.

Inspection
An inspection is more formalized than a

'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes.
The subject of the inspection is typically a document

such as a requirements specification or a test plan, and the purpose is to find problems and see what's missing, not to fix anything.

 Attendees should prepare for this type of meeting by

reading thru the document; most problems will be found during this preparation. The result of the inspection meeting should be a written report.
Thorough preparation for inspections is difficult,

painstaking work, but is one of the most cost effective methods of ensuring quality.

Activities performed during review

Activities in Review: Planning, overview meeting,

Review meeting and follow-up.

Deliverables in Review: Product changes, source

document changes and improvements.

Factors for drawback of review: Lack of training,

documentation and management support.

Roles and Responsibilities

In order to conduct an effective review, everyone has a role to play. More specifically, there are certain roles that must be played, and reviewers cannot switch roles easily. The basic roles in a review are: The moderator The recorder The presenter Reviewers

 Moderator:
The moderator makes sure that the review follows its

agenda and stays focused on the topic at hand.

The moderator ensures that side-discussions do not

derail the review, and that all reviewers participate equally.

 Recorder:
The recorder is an often overlooked, but essential part

of the review team.

Keeping track of what was discussed and documenting

actions to be taken is a full-time task.

Assigning this task to one of the reviewers essentially

keeps them out of the discussion.

Presenter: The presenter is often the author of the artifact under review. The presenter explains the artifact and any background information needed to understand it . Reviewer: Reviewers raise issues. Its important to keep focused on this. Its important to keep focused on this, and not get drawn into side discussions of how to address the issue.

Dynamic Testing Techniques

The process of evaluating a system or component based upon its behavior during execution.

Black box Testing

The term Black Box refers to the software, which is

treated as a Black Box.

By treating it as a Black Box, we mean that the system

or source code is not checked at all.

It is done from the customers viewpoint. The test engineer engaged in Black Box testing only

knows the set of inputs & expected outputs & is unaware of how those inputs are transformed into outputs by the software.

It attempts to find: Incorrect or missing functions Interface errors Errors in data structures or external database access Performance errors Initialization and termination errors

Functional testing addresses the overall behavior of

the program by testing transaction flows, input validation and functional completeness. Which is known as Black box Testing. There are three important techniques, which are significantly important to derive minimum test cases and input data for the same.

Equivalence class partitioning Boundary value analysis Error Guessing

Equivalence Partitioning
An equivalence class data is a subset of a larger class. This data is used for technically equivalence

partitioning rather than undertaking exhaustive testing of each value in the larger set of data.

For example, a program which edits credit limits within a given range ($10,000-$15,000) would have three equivalence classes:
Less than $10,000 (invalid) Between $10,000 and $15,000 (valid) Greater than $15,000 (invalid)

 Partitioning system inputs and outputs into

equivalence sets
If input is a 5-digit integer between 10,000 and

99,999 equivalence partitions are <10,000, 10,00099,999 and >99,999

The aim is to minimize the number of test cases

required to cover these input conditions

Equivalence classes may be defined according to the following guidelines:

If an input condition specifies a range, one valid

and two invalid equivalence classes are defined.

If an input condition requires a specific value,

then one valid and two invalid equivalence classes are defined.
If an input condition is Boolean, then one valid

and one invalid equivalence class are defined.

Boundary value analysis

Bugs creep around in corners and assemble at boundaries

Boris Beizer

 A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function. In same credit limit example, boundary analysis would test:
Low boundary plus or minus one ($9,999 and

$10,001)
On the boundary ($10,000 and $15,000)
Upper boundary plus or minus one ($14,999

and $15,001)

 Large number of errors tend to occur at boundaries of the

input domain BVA leads to selection of test cases that exercise boundary values BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class Examples: For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1) If input conditions specify a number of values n, test with (n1), n and (n+1) input values Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size)

Example: Loan application

Customer Name Account number Loan amount requested Term of loan Monthly repayment
2-64 chars. 6 digits, 1st non-zero 500 to 9000

1 to 30 years
Minimum 10

Term:

Repayment:
Interest rate: Total paid back:

Account number
First character: valid: non-zero invalid: zero Number of digits: invalid
Valid Partitions 6 digits 1st non-zero Invalid Partitions < 6 digits > 6 digits 1st digit = 0 non-digit

6
valid

7
invalid
Invalid Boundaries 5 digits 7 digits 0 digits

Conditions Account number

Valid Boundaries 100000 999999

Error Guessing
Based on the theory that test cases can be

developed based upon the intuition and experience of the Test Engineer

Advantages of Black Box Testing

Tester needs no knowledge of implementation, including specific programming languages Tester and programmer are independent of each other .

Tests are done from a user's point of view

Will help to expose any ambiguities or inconsistencies in the specifications

Test cases can be designed as soon as the specifications are complete

Disadvantages of Black Box Testing

Only a small number of possible inputs can actually be

tested, to test every possible input stream would take nearly forever . Without clear and concise specifications, test cases are hard to design . There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried . May leave many program paths untested .

WHITE BOX TESTING

Testing based on an analysis of internal workings and structure of a piece of software. Synonyms for White Box Testing: Glass Box testing Structural testing Clear Box testing Open Box Testing

 White box testing is a way of testing the external

functionality of the code by examining and testing the program code that realizes the external functionality.
It is a methodology to design the test cases that uses

the control structure of the application to design test cases.

White box testing is used to test the program code,

code structure and the internal design flow

Test Case design techniques under White Box Testing

Statement coverage
Branch coverage Condition coverage Cyclomatic complexity

Statement Coverage:
A test case design technique for a component in which test cases are designed to execute statements. Design test cases so that every statement in a program is executed at least once.

Euclid's GCD computation algorithm

int f1(int x, int y){ while (x != y){ if (x>y) then x=x-y; else y=y-x; } return x ;}

By choosing the test set {(x=3, y=3), (x=4, y=3), (x=3, y=4)} all statements are executed at least once.

Branch Coverage:

A test case design technique for a component in which test cases are designed to execute branch outcomes.

Condition Coverage:
Condition: A Boolean expression containing no

Boolean operators. For instance, A<B is a condition but A and B is not. Test cases are designed such that: Each component of a composite conditional expression given both true and false values.

 Example
Consider the conditional expression ((c1.and.c2).or.c3): Each of c1, c2 and c3 are exercised at least once i.e.

given true and false values. Condition testing stronger than branch testing. Branch testing stronger than statement coverage testing.

Cyclomatic complexity
It simply measures the amount of decision logic in the

program module. McCabe's complexity used to define minimum number of test cases required for a module. Cyclomatic complexity is defined as
CC = E - N + P

 Where
E = the number of edges of the graph N = the number of nodes of the graph P = the number of connected component

 In simplified way it can be defined as

CC = D +1 Where D = the number of decision points in the grap

Example
IF A=354 Then IF B>C Then A=B Else A=C EndIF

Endif Print A

 Cyclomatic Complexity

1-10 without much risk 11-20 moderate risk 21-50 program Greater than 50 (very high risk)

Risk Evaluation A simple program,

More complex, Complex, high risk Un testable program

Grey Box Testing

Grey box Testing is the new term, which evolved due to

the different architectural usage of the system. This is just a combination of both Black box & White box testing. Tester should have the knowledge of both the internals and externals of the function.

Assignment Compare black box Testing and White box Testing?????? Write a note about Scrum model, Extreme programming, W model What is mutation Testing and Random Testing?