 |
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
|
Session |
|
|
PLENARY
SESSION Special
Session - Book Early
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As
testers we love to evaluate the quality of software products. In this
presentation, Lee first addresses common types of metrics that we,
as testers, often use to evaluate the quality of software products.
These include counts, counts over time, ratios, and customer satisfaction.
Specific metrics include the number of defects (raw, weighted, and
grouped by severity, module occurrence, and status), the number of
defects over time showing possible trends, defects/KLOC and defects/Function
Points, surveys, and number of support calls.
It's
impossible to test everything - even in the most trivial of systems.
Tight time schedules and shortages of trained testing personnel exacerbate
this problem; so do changing priorities, feature creep, and loss of
resources. In many companies, test professionals either begin their
work on whichever components they encounter first, or the parts they're
most familiar with. Unfortunately, these approaches may result in
the delivery of a system where the most critical components remain
untested. Or, at the very least, critical components are tested later
in the lifecycle when there may not be time to fix the problems found.
All of this adds to the risk of a project. One way to overcome every
one of these challenges is to employ the use of risk analysis. Rick
Craig demonstrates the basics of a usable process for assigning testing
priorities based on relative risk. He helps you ensure the capability
of your test team to do a reasonably comprehensive test, no matter
what the circumstance.
IBM
Rational's test automation tools have been in commercial use since
19,90. In the past 14 years, successful traits of individual customers
have coalesced into patterns of successful test automation strategies.
Brian Bryson, with IBM Rational since 19,95, will discuss key observations
made throughout the years. Attendees will benefit from years of collective
automation experience leaving with a list of test automation do's
and don'ts.
Given that all programming languages are a part of mathematics,
and that mathematicians do not face problems of testing, the fact
that software developers do is paradoxical. The resolution of this
paradox lies in developing more powerful programming languages, which
are closer to or identical to the symbolic systems used by the domain
experts. As an example, the overwhelming superiority of Arabic over
Roman numerals for doing arithmetic is immediately obvious to all.
We produce far fewer bugs when we use Arabic numerals. Therefore the
issue in software testing is not one of finding people better versed
in testing protocols or about developing better testing tools; it
is essentially about creating better programming languages and providing
professional level training in those languages. It is about understanding
how the best minds in mathematics work, and how they go about their
job.
The topic will bring out the intricacies of Product Testing.
It will highlight specifically the areas of planning, validation &
verification, version control & release mechanism, entry criteria
and exit criteria for testing which will covers a unique internal
Product Rating - module-wise based on the module sizing. The Release
would culminate with a Release number, base-lined and termed 'ready
for customer' or for forming base for the next release.
The
dynamic nature of Web applications, their cost effectiveness, efficiency,
convenience and end-user reach demands that their quality management
become equally dynamic. After all, significant business revenue, not
to mention business image, rests on the performance and correct functioning
of contemporary Web-based applications and systems.
Software
testing is the process of sampling the input data space and possible
behaviours of a software system in an attempt to ensure that it conforms
to its requirements. The effectiveness of a testing exercise is directly
dependent on the effectiveness of the sampling. A specification based
approach to selecting a 'good' test sample is presented. This approach,
which can be largely automated, can be used both when systems are
built from
While testing of applications
developed for specific requirements is a challenging task, testing
products which implement requirements in a generic way is much tougher.
If so, how do you go about testing a product which builds an application?
Do 'Applications' become test cases and test data for this product?
Such products are typically application-building frameworks, which
will have all complexities of product testing and much more. Can
you afford to develop all possible applications using such a product
to test the framework? If so how would you test the applications
built using such products? As a product, time-to-market is critical
and you really don't have enough time to test. How do you approach
such demanding testing needs? The speaker will explore the various
aspects of this seemingly complex job and will share some experiences
in developing test strategy and performing testing of such application
development frameworks."
Abstracts:
Information technology has been taking charge of more and more mission
critical systems that warrant very high degree of quality. While the
IT industry is making great efforts to assure quality for such systems,
it is still relying on controlling quality through testing. 
CYBERLAB
is an innovative testing concept used by Delphi in embedded software
development. It is an automated test bench, which can be run from
any Delphi center globally with virtually transparent control. The
test equipment is located at one site and it is accessible from other
sites, globally. One of the applications equipment consists of a vehicle
simulator from Pi Technologies, target ECU, measuring instruments
and power supply. The connectivity is established by Delphi intranet.
Using Pi Simulator it is possible to automate the testing enabled
by scripts. 
Product
organizations have to innovate product development and maintenance
practices to thrive in this harsh environment.
