PDC-C.

S
Department
SOFTWARE
TESTING
SEE6B
UNIT-I

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

What is software testing?

The purpose of debugging is to find

the error (or) misconception that lead

Software testing is a process of executing a

to programs failure

program or application with the intent of finding

the software bugs. It can also be stated as the

Testing
Starts with known condition,

Debugging
Debugging starts from

program or applications or products: Meets the

user predefined procedures

unknown initial condit

business and technical requirements that guided

and

predictable

end cannot be predicted

its design and development.

2.

outcomes
Testing is a demonstration of

Debugging is a deductiv

error or apparent correctness

Testing
proves
a

Debugging is the pro

programmers failure
Much of testing can be done

vindication
Debugging is impossib

without design knowledge

Testing can and should be

detailed design knowled

The procedure for and

planned,

debugging

process of validating and verifying that a software

1.1. PURPOSE OF TESTING:

Testing is the process to prove that software
does not work.
Aim of test engineer is to prove that the

S.No
1.

software does not work then testing process can

be considered good
Testing is the process to detect the defects
and minimize the risks associated with the
residual defects.
Testing starts once the software product has

has

designed

and

scheduled
Testing can be done by an

constrained
Debugging must be d

outsider

insider

reached a mature stage of development

What do we do?
Keep track of the number of bugs
detected
Keep correcting the software
Finally conclude that software isgood
enough to be released into the market

1.2. TESTING VS DEBUGGING:

The purpose of testing is to show that
a program has bugs.

Prepared by, L.Vaishnavi

Page 2

cannot

1.3. MODEL OF TESTING:

1.3.1. The project:
Test methods are characterized by the
following model project.
a) Application
b) Staffs
c) Schedule
d) Specification
e) Acceptance Test
f) Personnel
g) Standards
h) Objectives
i) Source

PDC-C.S Department
TESTING

SOFTWARE
SEE6B
required criteria for delivery to
the end users
f) Personnel:
The staffs should be professional
and experienced in programming
and in the application
g) Standards:
Programming and tests standards

a) Application:
The specifics of the application are

exists and are usually followed

h) Objectives:
The system will have many
similar systems that will be

not important
It is a real time system that must

implemented in future
No 2 will be identical, but they

provide timely response to user

request of services
b) Staffs:
The programming staff consists

i)

have 75% of code in common

Source:
One third of code is new and one
third extracted from previous,

of twenty to thirty programmers

c) Schedule:
The project will take 24 months

reliable but poorly documented

The process starts with a

from the start of design to formal

program

acceptance by the customers

Acceptance will be followed by 6
months cutover period
d) Specification:
The specification is good
Its functionally detailed
e) Acceptance test:
The system will be accepted only

whether the software system has

met

the

an

, an OS or a calling program
Human errors lead to create
3 models: a) a model for environment
b) a model of the program
c) a model of the expected bugs
From these models we create a set of tests and
executed

requirement

specifications or not
The main purpose of the test is to
evaluate the systems compliance
with the business requirements
and verify if it has met the
Prepared by, L.Vaishnavi

in

environment , such as a computer

after a formal acceptance test

The customer will intend to
design the acceptance test
It is a technique to determine

embedded

Page 3

The result of each test is either expected or

unexpected
1.3.2.

The Environment:

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

A programs environment is the hardware

d. Lingua salator est-The hopeful belief

and software required to make it run

It also includes all programs that interact

that language syntax and semantics

with and used to create the program under

test, such as OS, loader, linkage editor ,
compiler, utility routines
1.3.3. The program:
Most programs are too complicated to
understood in detail
We must simplify our concept of the
program in order to test it

eliminate most bugs

e. Correction abide-The mistaken belief
f.

that a corrected bug remains corrected

Silver bullets-The mistaken belief that
language, design method, representation ,

environment grants immunity from bugs.

g. Angelic testers: The belief that testers are
better at test design than programmers are
at code design
Different types of bugs:

1.4. BUG:

1. Show Stopper/ Critical Bugs:

The core dumps, products abnormally

A Software bug is an error, flaw , failure or fault

shutdown and no work around will be

in a computer program or system that causes it to

found out, like OS automatically freezing

2. Major Bugs-The work around is found

produce an incorrect or unexpected result or to

but implementation can be done, like

behave it unintended ways

A bad specification may lead us to bugs

performance dependency
3. Medium Bugs- These bugs include DB

Some belief about bugs,

errors, link errors, low response time

4. Low/Minor Bugs-These are simple GUI

a. Benign bug hypothesis:

The belief that bugs are nice,
tame and logical
Subtle bugs have no definable
pattern-they are wild cards
b. Bug locality hypothesis:
The belief that a bug discovered
with a component affect only that
components behavior

errors
A bug occurs when,
A

bug

caused

because

of

not

understanding requirement
Null pointer exceptions
Access violation exceptions
Incorrect format of dates
Bugs due to incorrect syntax
1.5. LEVELS OF TESTING:

c. Control bug dominance-The belief that

errors

in

the

control

structures

of

Levels of testing include different methodologies

that can be used while conducting software

programs dominate the bugs.

testing. FUNCTIONAL TESTING:

Prepared by, L.Vaishnavi

Page 4

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

What is Functional Testing?

Unit

testing

is

performed

by

the

respective developers on the individual

Functional Testing is a testing technique that is
used to test the features/functionality of the

units of source code assigned areas.

The developers use test data that is

system or Software, should cover all the

different from the test data of the quality

scenarios including failure paths and boundary

assurance team.
The goal of unit testing is to isolate each

cases.

part of the program and show that

Functional Testing Techniques:

individual parts are correct in terms of

requirements and functionality.

There

are

two

major

Functional

Testing
Limitations of Unit Testing

techniques as shown below:

Testing cannot catch each and every bug

in an application.
It is impossible
execution

path

to
in

evaluate
every

every

software

application. The same is the case with unit

testing.
There is a limit to the number of scenarios
and test data that a developer can use to
verify a source code.
After having exhausted all the options,
there is no choice but to stop unit testing
and merge the code segment with other
units.

The main levels of software testing are:

1.5.2.Integration Testing:

1.5.1.Unit Testing:

Integration testing is defined as the testing of

This type of testing is performed by

developers before the setup is handed
over to the testing team to formally
execute the test cases.
Prepared by, L.Vaishnavi

Page 5

combined parts of an application to determine if

they function correctly.
Integration testing can be done in two ways:

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

a. Bottom-up integration testing

b. Top-down integration testing.

The

application

is

tested

in

an

environment that is very close to the

production

Integration Testing Method

environment

where

the

application will be deployed.

Bottom-up integration: This testing begins with unit testing, followed by tests of
System testing enables us to test, verify,
progressively higher-level combinations of units called modules or builds.
and validate
both the
business
requirements as well as the application
architecture.
Top-down integration : In this testing, the highest-level modules are tested first and
1.5.4.Regression Testing:
progressively, lower-level modules are tested thereafter.
Whenever a change in a software
application is made, it is quite possible

1.5.3.System Testing:

that other areas within the application

System testing tests the system as a
whole.
Once all the components are integrated,
the application as a whole is tested
rigorously to see that it meets the

have been affected by this change.

Regression testing is performed to verify
that a fixed bug hasn't resulted in another
functionality or business rule violation.
The intent of regression testing is to
ensure that a change, such as a bug fix

specified Quality Standards.

This type of testing is performed by a

should not result in another fault being

specialized testing team.

uncovered in the application.

System testing is important because of the

Regression testing is important because of the

following reasons:

following reasons:

System testing is the first step in the

Minimize the gaps in testing when an

Software Development Life Cycle, where

application with changes made has to be

the application is tested as a whole.

tested.

The application is tested thoroughly to

Testing the new changes to verify that the

verify that it meets the functional and

changes made did not affect any other

technical specifications.

area of the application.

Prepared by, L.Vaishnavi

Page 6

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

Mitigates risks when regression testing is

Cloudy Directions

The Application will be tested on

performed on the application.

Test

coverage

is

increased

without

machines with the lowest specification to

compromising timelines.

test loading times and any latency

problems.

Increase speed to market the product.

1.5.7.Beta Testing:

1.5.5.Acceptance Testing:
This test is performed after alpha testing has been
Acceptance tests are not only intended to
point

out

simple

spelling

successfully performed.

mistakes,

cosmetic errors, or interface gaps, but also

In beta testing, a sample of the intended audience

to point out any bugs in the application

tests the application. Beta testing is also known

that will result in system crashes or major

as pre-release testing.

errors in the application.

By performing acceptance tests on an

Users will install, run the application and

send their feedback to the project team.

application, the testing team will deduce

how the application will perform in

production

Typographical errors, confusing

application flow, and even crashes.

1.5.6.Alpha Testing:

Getting the feedback, the project team can

This test is the first stage of testing and will be

fix the problems before releasing the

performed amongst the teams (developer and QA

software to the actual users.

teams).

The more issues you fix that solve real

Unit testing, integration testing and system testing

user problems, the higher the quality of

when combined together is known as alpha

your application will be.

testing. During this phase, the following aspects

will be tested in the application:

Having a higher-quality application when

you release it to the general public will

Spelling Mistakes

Broken Links

Prepared by, L.Vaishnavi

increase customer satisfaction.

Page 7

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

STRUCTURAL TESTING:

Reveals errors in "hidden" code

Spots the Dead Code or other issues with

respect to best programming practices.

What is Structural Testing ?

Structural testing, also known as glass box
testing or white box testing is an approach where

Disadvantages of Structural Box Testing:

the tests are derived from the knowledge of the

Expensive as one has to spend both time

and money to perform white box testing.

software's structure or internal implementation.

The other names of structural testing includes

missed accidentally.

clear box testing, open box testing, logic driven

testing or path driven testing.

Every possibility that few lines of code is

In

depth

knowledge

about

the

programming language is necessary to

perform white box testing.
Structural Testing Techniques:

IMPORTANCE OF BUGS:

Statement Coverage - This technique is

aimed at exercising all programming
statements with minimal tests.

The importance of bugs depends on frequency ,

correction cost, installation cost & consequences.
(i)

running a series of tests to ensure that all

How often does that kind of

branches are tested at least once.

Frequency:

Branch Coverage - This technique is

Path

Coverage

- This

bug occur?

technique

Pay more attention to the

corresponds to testing all possible paths

more frequent bug types

which means that each statement and

(ii)

branch are covered.

Correction Cost:
What does it cost to correct the bug

Advantages of Structural Testing:

after it is found?

Forces test developer to reason carefully

about implementation

Prepared by, L.Vaishnavi

Page 8

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

The cost depends on sum of 2

Eg: credit card declared invalid

factors:
5.Serious: It loses track of its transactions
(a) The correction cost
Eg: Accontability is lost
(b) The Cost of discovery
6.Very serious: The bug causes the system to do
(iii)

Installation Cost:

the wrong transactions

Installation cost depends on

into another account

the number of installations:

Fixing

one

bug

and

distributing the fix could

exceed the entire systems
development cost
Importance=Frequency*(correction

Eg; Instead of your pay check, the system credits

7.Extreme: The problem once affects a single

user can be spread to other users.
8.Intolerable:

Long

term

unrecoverable

corruption of the database occurs and the

cost+

corruption is not easily discovered & system has

installation cost+ consequential cost)

to be shut down

CONSEQUENCES OF BUGS:

9. Catastrophic: The decision to shutdown is

taken out by our hands because the system fails

1.Mild: The symptoms of bug offend us gently, a

THE TAXONOMY OF BUGS:

misspelled output or misaligned printout

2.Moderate:

Outputs

redundant. The

are

misleading

bug impacts

the

or

systems

Bug taxonomies help in providing fast and

effective feedback so that they can easily identify
possible reasons for failure of the software. Using

performance

bug taxonomy, a large number of potential bugs

3.Annoying: The systems behavior can be

can be grouped into few categories. At the end of

annoying due to bug because of human behavior

testing, testers can understand the type of

categories of bugs that frequently occurred and

Eg: Names are truncated or modified

thereby in successive rounds of testing he can

4.Disturbing: It refuses to handle legimate

transaction

Prepared by, L.Vaishnavi

Page 9

focus on writing more test cases that would help

to detect such bugs.

PDC-C.S Department
TESTING
a)

SOFTWARE
SEE6B

Requirements, Features, and Functionality

Bugs

Even when there are no bugs like

ambiguous, unclear or incomplete
requirements, we may expect new

b) Structural Bugs
c)

type of bugs because of changing

features are new change requests.

Data Bugs

ii)Feature Bugs:

d) Coding Bugs
e)
f)

Each requirement is made up of

Interface, Integration, and System Bugs

many features.
Whenever there are specification

Test and Test Design Bugs

related bugs, corresponding to

that there will be feature related

g) Testing and Design Style

a) Requirements, Features, and Functionality

bugs.
Corresponding to bugs related to
requirement specification, there

Bugs:

will be feature related bugs like

Requirements expressed by client and

wrong feature, missing feature,

user are captured by requirements study

or

team and then they are segregated,

feature is relatively easy to

documented, reviewed, and approved so

identify and also, to address.

In case of wrong feature, based

as to formalise into a requirements

extra

feature.

Missing

on the phase where we detect that

specification.

the particular feature is wrongly

i) Requirements and Specification related
Bugs:

implemented,

the

may be deep.
In order to

implications

address

wrong

The bugs in requirements are a

features, one needs to change all

contributing cause to the failure

earlier documents till that phase

of many projects.
Ambiguous,
unclear
incomplete

requirements

or
are

serious problems but they are not

the sole source of requirements
bugs.
Prepared by, L.Vaishnavi

Page 10

where wrong feature is detected

and

also,

addressing

wrong

features may include changes in

design and code.

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

iii)Feature Interaction Bugs:

Required
software

b)Structural Bugs:

functionality
is

an

in

outcome

of

In

structured

composition

of

each

of

structural

elements

Each feature is not independent

statements, loops and their nesting play an

but interdependent.
Though many a times feature

important role in ensuring better quality

unambiguous,

implementable,

traceable, and testable even then

statements,

the

interaction of many features.

specification is clear, correct,

like

programming

compound

structure.
Also, while structuring, one shall ensure
no redundancy in logic, computation,
representation and declaration.

the system may not be showing

required functionality.
The possible reasons may be

i) Control and Sequence Bugs:

because of incorrect interaction

Control flow specifies a sequence in

among features that are grouped

which instructions (events or paths) are

together or because of incorrect

executed in a component or system.

Control flow and sequence are the most

interaction between feature in a

particular group with another
feature in the other group .

common but can be easily found during

unit testing. These bugs are less in old
software.
Control flow bugs include unreachable or

iv)Functional Bugs:

dead code, improper nesting of loops, un-

Requirements, Features, and Functionality

tested paths, loop-back and loop exit

Bugs can be detected by using functional

criteria, incorrect or missing process

testing techniques, namely, transaction

steps, duplicated processing, un-necessary

flow testing, syntax testing, domain

processing, use

testing, logic testing, and state testing.

Also, formal technical reviews which are

of

Go-TOs

without

justification and so on.

part of static testing are capable of finding

Example

bugs in requirements and also, traceability

Unreachable or Dead Code, Redundant

related issues

Conditionals
ii)Logic Bugs:

Prepared by, L.Vaishnavi

Page 11

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

Logic bugs are related to misunderstanding on behavior of case

statements and logic operators either singly or in Example
combination and also,
misunderstanding of the semantics of the order in which
Boolean- Execute malicious code
Buffer aoverflow
expression is evaluated for specific compiler.
Examples of logic bugs include- improper lay-out of cases improper
c) Data Bugs:
negation of Boolean expression, improper simplification and combination
Data is represented in code as: data types,
of cases etc.
constants, variables, and records.
Data bugs arise while selecting

Example
Switch Case with No Default, Empty Conditional

appropriate

Statements, Enumerated Data Types

specifications, their formats, the number

These bugs include- arithmetic bugs, algebraic

bugs, wrong evaluation of mathematical formula,
and inappropriate selection of algorithm, ignoring
over-flow, improper use of logical and relational
operators.

types,

the

values.
In addition, data representation in the
form of data bases and normalization also
plays a very crucial role.
i)Dynamic Vs. Static Data
Dynamic data are

Examples:
outside

proper

of such data objects, and their initial

iii)Processing Bugs:

Value

and

created

during

the

transaction and stored in the shared

the

domain,

Buffer

Exceptions,

memory.
At the end of the transaction, dynamic

Wrong Assumptions on Operator Precedence,

data has no relevance and shared memory

Overflow/Underflow,

Arithmetic

is released back to the system.

If the results are not as per our

String Handling Errors

expectation, it is hard to locate the cause

iv)Data Flow Bugs and Anomalies:

Data flow is a representation of the
sequence and possible changes of state of
data objects, where the state of an object
is any of creation, usage, modification or
destruction..

behind these bugs and as such bugs

produced by dynamic data are hard to find
and also, performing root cause analysis
is not easy.
Roles:
Parameter,
Information

Bugs like referencing a variable with an undefinedExample:

value and variables
that are never used , initialization bugs, modifying data and not using
the result, attempting to using the variable without defining it, double
initialization are some example of data flow anomalies and bugs.
Prepared by, L.Vaishnavi

Page 12

Control,

and

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

Memory leaks(related with freeing the memory),

Freeing the already freed resource, NULL

Content: Content of data at the lowest level is in the fo

While accepting to store or accessing to process, the da

hardware or software processor before storing it or pro

dereferencing

program.
While doing so there can be data bugs that may

ii) Parameter, Control, and Information:

encryption and decryption of one form to another.

Parameter Data: Parameter is the input and out data to characterize a particular
well-defined function/procedure in a component.

Structure: Structure of data is about organization of the data. I

While passing parameters, care shall be taken to ensure

that exact
typethat can be stored in the structure.
and number
of items
Attribute: This part specifies meaning or semantics associated
and required number of data for inputs and outputs are defined and also,
structure.
the same shall be provided in a defined order.
For example, integer, string, alphanumeric etc.
Control Data: Control Data (Reference Data) is stored to support the business

rules for the maintenance of the information

Data testing focuses on selection of appropriate and proper type
Examples of control data are: in a payroll application, it would be the
for storing data for a specified usage.
d) Coding
Bugs:
data stored on the government tax rates for each pay
scale and
the date

the tax rate became effective; in a retail shop, item-wise rate. Control
The internal structure of the code consists of process an
data contains business rules telling the application whatto While
do or how
to
performing
testing, one need to specify execution
behave.
based on program logic, coding standards, programm

check for complexity of code using techniques like cycl

Information Data: Information type of data is usually
dynamic
it may include- non-conformance of
Codingandbugs
frequently changes in response to changes in processing, external functional
standards; programming style; syntactical bugs; sem
processes and/or business rules in the form of control data.
code; mathematical and logical mistakes in the code;
Information data is produced by the code by using parameter data and
that is too complex to manage; failure to execute all in
processing it using control data.
least once; non-fulfilment of single entry and sing

translation errors in converting design into code; docum

iii)Contents, Structure, and Attributes:

Data in code can be specified as: data
types, constants, variables, and records.
By
selecting
appropriate
data
specification, we ensure correctness in
accepting, providing, processing, and
storing the data.
When data specification is done, it
addresses three parts: contents, structure,
and attributes.
Prepared by, L.Vaishnavi

Page 13

e) Interface, Integration, and System Bugs:

We need to build the software by using appropriate soft

and also, build capability to show required behaviour by

level control and right sequencing to manage resources.

While ensuring this, we can come across many bugs a

integration level, system level, or interoperability level.

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

External Interfaces:

Operating system related bugs have origin

The software has to interface with many

external applications and hardware in

in hardware architecture and interfaces.

Operating system itself may be having

order to carry out its operations and also,

some bugs.
In addition, there can be missing device

to perform its intended functionality.

However, the information about these

drivers because of which interface related

external applications and hardware may

bugs may crop up.

These bugs can be controlled by having

not be available and also, even if

interface specialists to provide solutions,

available may not be complete.

The type of bugs may include- wrong

and also by understanding and defining

protocols; synchronization related bugs;

input and output data inappropriate
formats;

unavailability

of

serves;

restricted access or no access etc.

system level configuration.

Software Architecture:

There can be bugs like failure to support required num

concurrent users; slower response time during peak pe

Internal Interfaces:

to support some other languages; interoperability related

All these types of bugs can be addressed at software ar
Internal interface of software involves establishing interconnectivity
providing solutions like multi-layered architecture;
among different components that are within the boundary
of software
support;
providing loose coupling etc.
application that is under consideration and also, nature and type of these
C
components is known to developer. Also, developers
have control over

ontrol and Sequence Bugs

these components.
protocol
Systems design;
level controls and sequencing play a ver
Some of the bugs that may occur include- wrong

systems, real time systems, telecom syst

inappropriate input and output data formats; failure to embedded
recover against
systems.
wrong data; wrong sub-routine calls; synchronization computing
and sequencing
However there can be bugs like- failure of executio
related bugs; wrong parameter passing to initiate and also to exit.
required sequence; no activation of any event at th

process initiation even when pre-requisites are not fulfi

Hardware Architecture
Knowledge about particular hardware and its architecture
is very
even
whenmuch
pre-requisite conditions are satisfied etc.
essential so as to perform intended functionality.
most of the bugs are related to synchronization.
There can be many bugs like I/O device operation or
errors; bugs are hard to find bugs with a majo
instruction
Synchronization
inadequate buffer space; I/O device address error; no compatibility
among
occur where
multiple threads are accessing some co

hardware devices; failure to access the device and so on. Synchronization bugs are of three types: Deadlocks, Ra
Live lock.

Operating System:

Deadlock
Prepared by, L.Vaishnavi

Page 14

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

Deadlock is a situation in which one or more threads mutually

Systemlock
Bugs
each other,
System bugs cover all types of bugs including both
more frequently because of inconsistent locking sequence.
functional.

Some of the bugs are missing functionality; wrong

Race Condition

functionality;
This is an error which results when two threads try to access the same
resource failure to meet required performance; fa
and the result depends on the order of the execution of the threads. volumes of information; failure to handle peak volu
inappropriate documentation; system that is not
Live Lock

frequently fails etc.

These bugs are directly related to customer and user sat

This type of error results from in consistent synchronization, incorrect
initialization of static field, and method spins on field. These
are explained
f) Test
and Test below.
Design Bugs:

Inconsistent synchronization: Error related to inconsistent synchronization may

Testers and testing can be bug prone.
happen because of mix of locked and unlocked accesses in shared variable where
In testing, especially in business applications, exhaust
some are locked accesses and some other accesses are unlocked.
possible because of many reasons that may include lack
Incorrect initialization of static field: During synchronization, connection and
time, effort, test resources and so on.
release semantics are established by initializing a volatile static field. If a nonTest Criteria
volatile field that is shared by different threads are improperly
initialized
Testingthen
helps to detect as many bugs as possible so as to
there can be a synchronization problem.
testing does not prove that system is bug free.

If testing does not report bugs means it does not indicate

Method spins on field:
does not have bugs.
Control and sequence bugs can be addressed at design level. Using
path performing
testing
After
good enough testing, system will be rel
made
operational
in a production environment. Here sys
with the help of transaction flow graphs, one can detect system level
control
and
can cause many problems related to performance, stabili
sequence bugs.
so which were not seen during system testing.
Integration Bugs:

Resource Management Problems:

Remedies
and
As inter-modular
software
systems
more
more
there is anm
Integration bugs are related intra-module
interfaces.
Test bugs
canarebebecoming
addressed
by and
using
anycomplex,
of the remedial
Integration bugs can detected by integration
which verifies
inter- resources that include memory
ever testing
increasing
manage
debugging,need
test to
quality
assurance, test execution and automa
module interfaces, critical external interfaces
and availability
user and of
business
management,
links
and bandwidth, availability of server,
automation.
workflows and scenarios that would be helpful
into
evolving
the system.
access
other systems
through gateways, and so on.
Integration testing includes Functional
Testing.
Some of
resource
management
related is
bugs
of
Test Debugging: Test debugging
all are
aboutunavailability
finding any issu
Functional Testing at integration level focuses on verifying components that
requiredcases,
resource;
usage of wrong
resource;
resource
already
test coverage
and trying
to address
these
issues in
in use;
orde
are basically small groups of interdependent units that are functionally or
race conditions
efficiency. in getting resources; unavailability of server;
logically related.
unavailability
required
bandwidth;
failure;good
denied
to
of
Test
debugging
allows uslink
to perform
test access
design so
Function Test also exercises the behavior of
the component
based
on specific

server.
efficiency.
input including new functionality and that bug conditions
are properly
Some of the practices like collaborative approach invo
handled.
development
Test methods used in integration testing and functional testing at
integration team
level to strategise testing; review of test
include domain testing, syntax testing, data flow testing.
Prepared by, L.Vaishnavi

Page 15

training on system and domain would be of certain h

PDC-C.S Department
TESTING

SOFTWARE
SEE6B

good test cases, scenarios ad coverage.

g) Testing
and Design
Test Quality Assurance: Model based Test Maturity Models
(TMM)
is in Style
Bad design and bad code lead to bugs.
practice which is of use in test quality assurance.
Bugs that have origin in design are hard to find and add
Thus,
order to carry out effective testing, good de
Matured test related processes, building skills and competency
in intesters,

incorporating test automation, monitoring and controlling test practices

test
code using
is a prerequisite.
If testing is being done on bad design and bad code, the
metrics, measurements, and statistical process controls are the means by which we
stream of bugs in every round of testing showing ever
can bring in test quality assurance.

bugs and never ending testing.

of reporting more and more bugs will

Test Execution Automation: Whenever there is a need to carry outThis
manytrend
rounds
of testing on ensuring stable product with le
of testing on the same system, we can sense the possibility of objective
test execution

also increased confidence on using it.

Thus good testing requires good design and good code.
Here, by selecting appropriate commercial or open source testing
thatnot only inhibit or filter the bugs before
tools,
Goodtests
designs
are designed by testers can be recorded in these tools and the same thereby
can be played
reduce overall effort of software developme
automation.

back so as to complete testing in a shorter period.

rework effort.
In brief, it is always good recommend redesigning rath
Test Design Automation: Slowly but steadily more and more tools are getting
testing on bad design and code.
into test design automation. These tools are of use in automating test design at
code level and also, at system level.

Prepared by, L.Vaishnavi

Page 16