sss ssss      rrrrrrrrrrr
                      ssss    ss       rrrr   rrrr
                     sssss     s       rrrr    rrrr
                     ssssss            rrrr    rrrr
                      ssssssss         rrrr   rrrr
                          ssssss       rrrrrrrrr
                    s      ssssss      rrrr  rrrr
                    ss      sssss      rrrr   rrrr
                    sss    sssss       rrrr    rrrr
                    s  sssssss        rrrrr     rrrrr
         +=======    Quality Techniques Newsletter    =======+
         +=======            December 2000            =======+

QUALITY TECHNIQUES NEWSLETTER (QTN) is E-mailed monthly to Subscribers
worldwide to support the Software Research, Inc. (SR), TestWorks,
QualityLabs, and eValid user communities and other interested parties to
provide information of general use to the worldwide internet and
software quality and testing community.

Permission to copy and/or re-distribute is granted, and secondary
circulation is encouraged by recipients of QTN provided that the entire
document/file is kept intact and this complete copyright notice appears
with it in all copies.  Information on how to subscribe or unsubscribe
is at the end of this issue.  (c) Copyright 2003 by Software Research,


   o  Yes, Virginia, There is a Santa Claus, by F. P. Church

   o  Quality on the Internet: Key to Survival or an Urban Myth, by
      Marco Dekkers

   o  The Engineering of Software: A Technical Guide for the Individual

   o  CNSS Software Engineering Education Study, by Larry Bernstein

   o  Call for Contributions: 8th ESEC & 9th FSE

   o  Call for Contributions: Case Based Reasoning

   o  QTN Article Submittal, Subscription Information


                 Yes, Virginia. There Is A Santa Claus.
                              F. P. Church

        The New York Sun, December 1897.

        Dear Editor,

        I am 8 years old.

        Some of my little friends say there is no Santa Claus.

        Papa says, 'If you see it in The Sun, it's so'.
        Please tell me the truth.  Is there a Santa Claus?

        Virginia O'Hanlon,
        115 West 95th Street,
        New York, New York

Dear Virginia,

Your little friends are wrong.  They have been affected by the
skepticism of a skeptical age.  They do not believe except what they
see.  They think that nothing can be which is not comprehensible by
their minds.  All minds, Virginia, whether they be men's or children's,
are little.

In this great universe of ours man is a mere insect, an ant, in his
intellect, as compared with the boundless world about him, as measured
by the intelligence capable of grasping the whole of truth and

Yes, Virginia, there is a Santa Claus.  He exists as certainly as love
and generosity and devotion exist, and you know that they abound and
give to your life its highest beauty and joy.  Alas! How dreary would be
the world if there were no Santa Claus!  It would be as dreary as if
there were no Virginia's.

There would be no childlike faith then, no poetry, no romance to make
tolerable this existence.  We should have no enjoyment, except in sense
and sight.  The eternal light with which childhood fills the world would
be extinguished.

Not believe in Santa Claus!  The most real things in the world are those
that neither children nor men can see.  Did you ever see fairies dancing
on the lawn?  Of course not, but that's not no proof that they are not
there.  Nobody can conceive or imagine all the wonders there are unseen
and unseeable in the world.

Only faith, fancy, poetry, love, romance, can push aside that curtain
and view and picture the supernatural beauty and glory beyond.  Is it
all real?  Ah, Virginia, in all this world there is nothing else real
and abiding.

No Santa Claus!  Thank God he lives, and he lives forever.  A thousand
years from now, Virginia, nay, 10 times 10,000 years from now, he will
continue to make glad the heart of childhood.

Francis P. Church,
Editor, The New York Sun


       Quality on the Internet: Key to Survival or an Urban Myth?

                            By Marco Dekkers
                        Product-Manager, Testing
                        KZA Kwaliteitszorg B.V.

Studies show that between 60% and 80% of online purchases initiated by
consumers never reach the point were a product or service is actually
delivered (and paid for). These are shocking numbers, even more so
because nobody seems to take notice. The reasons for this failure rate
are simple and fall into two categories. The first category consists of
transactions that are canceled by buyers before they commit themselves.
Usually this is because of inadequate performance, complexity of the
purchase process, anxiety about security and/or a larger number of steps
in the process than is absolutely necessary (during which time the
customer has time to change his of her mind). The second category
consists of orders which were actually placed, but never fulfilled. This
can be due to technical difficulties and/or failure to integrate the
front-office (website) and the back-office (systems and procedures). In
all cases loss of revenue is the end result. If ever there has been a
reason for quality on the internet, this is it people.  Lack of quality
will cost you $$$$$$.

A company presence on the internet means visibility and an opportunity
for doing business. However, it can also constitute a threat to customer
loyalty and satisfaction if the website does not live up to customer
expectations.  Quality as perceived by the customer depends on several
factors. Interesting content, a unique product or service at a
reasonable price and swift and reliable fulfillment are key elements.
With regard to the underlying technology the aspects of greatest concern
are usability, performance, security, availability and inter-
operability. From the company's perspective one might add scale-ability
and maintainability. The remainder of this article will focus on these
quality aspects which relate to technology.

The main question is whether quality on the internet can be attained.
Long story short: yes it can. This is not an easy task though. The rate
at which things move on the internet, both from a business and a
technological perspective, is phenomenal. Software projects with regard
to internet development are notorious for their lack of documentation
and clarity about requirements. Software is developed as swift as
possible, there is little time for testing and there is a "we'll fix it
when it breaks" attitude. This sets the stage for failure. A number of
companies has suffered from headaches after going live with their new
website. Sites being unable to handle the load, security violations and
customers leaving the site because of poor performance or usability
issues are just a few examples of problems which may occur. This does
not have to be the case though. Some different approaches to web
development and quality assurance can make a world of difference.

With regard to web development the use of standards can have a
significant impact in making software more maintainable, thus reducing
the time needed to fix bugs. Designing for scalability helps to
anticipate load and performance issues. Performance can be further
improved by applying some simple rules to development. One of these
rules might be that web pages may not exceed a certain size in
kilobytes. Another is to arrange for the most important information (for
instance navigation buttons) on a web page to appear first when that
page is loaded. Action can be taken to optimize availability, for
instance by using multiple hardware and software environments (if one
fails the other takes over). Separating content and software
significantly contributes to maintainability and therefore is a must do.

With regard to quality assurance several actions can be taken. One is to
promote and enforce the use of standards, another to insist on
documentation which at the very least describes the structure, goal and
the underlying architecture of the system. Also clarity is required with
regard to the intended use of the website (for instance by writing use
cases). The look and feel of the website also needs to be documented.
Quality assurance can play a role in validating this with respect to
usability aspects. Testing needs to be performed early on during
development. Testers can start by performing "static" tests. This is a
method in which checklists are used to investigate certain quality
issues. The checklists contain questions and the job of the tester is to
find the answers to them. This can be done by conducting interviews,
studying documentation or any other viable means of gathering
information. A checklist might for instance contain questions with
regard to usability aspects of the interaction design. The answers to
these questions provide insight into the status quo. Based on these
results testers might report bugs before they ever present themselves in
an application running under test. Checklists can be drawn up for almost
every aspect of website quality, thus enabling testers to detect
problems early on. Other examples of test techniques which can be
applied to website testing are usability testing, performance testing,
penetration testing, link checking, HTML validation and GUI testing.
Security can also be validated by conducting a security audit.
Collecting metrics on the effort needed to fix bugs and performance
leads to a better understanding of the quality of the system with regard
to these aspects.

It is very important to test on multiple browsers (i.e. Internet
Explorer and Netscape Navigator) and platforms to validate whether the
website looks and functions correctly in the target user environments.
An alternative to using multiple browsers would be to use Opera (no,
we're not talking about music all of a sudden). Opera is an internet
browser which can only interpret standard HTML. Since all other browsers
support standard HTML (and their own extensions), a website which
functions well in Opera is likely to do so in any browser.

As with any test effort internet testing has to be risk-based. Taking
into account the internet business strategy and the risks associated
with it therefore is a good starting point for developing a test
strategy. Because internet software development is an iterative process,
the test process should match this. This implies short test cycles
consisting of test development and execution and possibly the use of
time-boxing techniques.  Using "static" testing as part of the test
effort and modern testtools enables testers to do a lot of work under
considerable time pressure.

Internet testing needs to start early on during development and never
ends!  This is because after the website goes live, it's performance
might degrade, links can be broken, security can be infringed and
availability might fall short of expectations. However, without
monitoring (= testing after implementation) the company might not find
out about these problems until they have led to loss of revenue and
damage to corporate image.

A final thought on tools. I have personally been a skeptic with regard
to tool use for software testing for years. In the past I have often
concluded that the use of tools would be too expensive and contribute
little to the test effort. However, in this era of internet testing I
have had to change my position. Testing internet-based systems without
testtools is simply impossible, or at the very least impractical.
Conducting a performance test on a website is a must. Doing so manually
would require thousands of people simultaneously executing test scripts.
I don't know about you, but I have never had such a large testteam at my
disposal. Tools can also be used for checking the syntax of HTML code
(an otherwise boring and time-consuming task), to check links and to
automate regression testing. An automated regression test is a must-have
for performing 24 hour x 7 days a week post-implementation monitoring.

In conclusion quality on the internet is a key to corporate success, and
perhaps in some cases even to survival. Instead of being an urban myth,
as it would seem at times, quality can be reached once some common sense
actions are taken with regard to web design and development and testing
is performed in a professional manner which takes into account the
peculiarities of the internet.


   The Engineering of Software: A Technical Guide for the Individual

                      by Dick Hamlet & Joe Maybee
             Addison-Wesley, 2001 (Published October, 2000)
                           ISBN 0-201-70103-0

In this book, the authors provide an introduction to the essential
activities involved in a software engineering project. Readers will come
to understand technical skills in requirements/specification, analysis,
design/implementation, and testing. These methods are treated fully,
with a multitude of examples for readers to emulate. The book is divided
into four parts--Software and Engineering; Requirements and
Specification; Design and Coding; and Software Testing--to discuss the
phases (besides coding) of the software lifecycle. It covers modern
topics like Capability Maturity Model, Java, Automated and Regression
testing, and Safety for mission critical projects. This book is designed
to hone the skills of the software engineer by reinforcing the methods
and techniques used throughout the software lifecycle. It is also
suitable for "crossover" engineers trained in other technical fields who
now find themselves working with software.


               CNSS Software Engineering Education Study
                            Larry Bernstein

The Rochester Institute of Technology hopes to have certification for
their undergraduate program this year and the University of Michigan has
a new program that will graduate 300 students this year.  Monmouth has
graduated more than 400 hundred students with a Masters in Software
Engineering and have begun an ingratiate Software Engineering program.

The belief is that there are not enough qualified instructors to teach
software engineering. Undergraduate university programs are suffering.
The pay offered, particularly with adjunct programs,is too low to
attract qualified people.   Adjunct salaries at some schools  top at
$35K/course but they can attract good instructors with adjunct pay of
$10K/course  to $20K/course.  Too many schools expect to pay less than
$5K/course.  While they can attract adjuncts for other courses,
including engineering and science, the short supply of experts in the
area of software engineers demands higher pay.


                         CALL FOR CONTRIBUTIONS

       Joint 8th European Software Engineering Conference (ESEC)
               9th ACM SIGSOFT International Symposium on
            the Foundations of Software Engineering (FSE-9)

    Vienna University of Technology, Austria, September 10-14, 2001


General Chair: A Min Tjoa, Vienna University of Technology, Austria

Program Committee

PC Chair: Volker Gruhn, University of Dortmund, Germany

Tutorial Chair: Harald Gall, Vienna University of Technology, Austria

Workshop Chair: Bashar Nuseibeh, The Open University, United Kingdom

Members:  Israel Ben-Shaul, Israel Institute of Technology, Israel;
Alfred Brvckers, Adesso AG, Germany; Johannes Bummiller, DaimlerChrysler
AG, Germany; Christine Choppy, Universiti Paris XIII, France; Gianpaolo
Cugola, Politecnico di Milano, Italy; Premkumar Devanbu, University of
California, USA; Wolfgang Emmerich, Univ. College London, United
Kingdom; Carlo Ghezzi, Politecnico di Milano, Italy; Paul Grefen,
University of Twente, Netherlands; Mary Jean Harrold, Georgia Institute
of Technology, USA; Wilhelm Hasselbring, University of Oldenburg,
Germany; George T. Heineman, WPI, USA; Katsuro Inoue, Osaka University,
Japan; Mehdi Jazayeri, Vienna University of Technology, Austria; Stefan
Jablonski, Univ. of Erlangen-Nurenberg, Germany; Jens H. Jahnke,
University of Victoria, Canada; Gerti Kappel, University of Linz,
Austria; Rudolf K. Keller, Universite de Montreal, Canada; Axel van
Lamsweerde, University of Louvain, Belgium; Nenad Medvidovic, Univ. of
Southern California, USA; Walcelio L. Melo, Oracle and UCB, Brazil;
Carlo Montangero, University di Pisa, Italy; David Notkin, University of
Washington, USA; Dewayne E. Perry, The University of Texas at Austin,
USA; Flavio Oquendo University of Savoie, France; Leon J. Osterweil,
Univ. of Massachusetts,  Amherst, USA; David M. Raffo, Portland State
University, USA; Debra J. Richardson, University of California,  Irvine,
USA; David S. Rosenblum, University of California,  Irvine, USA; Wilhelm
Schdfer, University of Paderborn, Germany; Tetsuo Tamai, University of
Tokyo, Japan; Alexander L. Wolf, Univ. of Colorado at Boulder, USA; Yun
Yang, Swinburne Univ. of Technology, Australia; Pamela Zave, AT&T
Laboratories, USA.

Important Dates:


        Paper submission     March 15, 2001
        Authors notified     May 25, 2001
        Camera-ready copy    June 15, 2001


        Workshop proposal    February 15, 2001
        Workshop acceptance  February 28, 2001
        Workshop material    June 1, 2001


        Tutorial submission  March 15, 2001
        Authors notified     May 25, 2001
        Final material       July 31, 2001

Further Information:

        Ms. Irene Sudra or Ms Karin Sudra
        Osterreichische Computer Gesellschaft
        (Austrian Computer Society)
        Wollzeile 1-3      Phone:  +43 1 512 02 35
        A-1010 Vienna      Fax:    +43 1 512 02 35 9
        Austria            email:


                            Call for Papers
        Fourth International Conference on Case-Based Reasoning
                  Vancouver, British Columbia, Canada
                        30 July - 2 August 2001

ICCBR'01 is the preeminent international meeting on case-based
reasoning.  This four-day conference will be held at Simon Fraser
University's campus in Vancouver, immediately prior to IJCAI'01 (which
will be held in nearby Seattle).

The four-day program will include separate days devoted to workshops and
to the Second Workshop on Innovative Customer-Centered Applications,
formally known as "ICCBR Industry Day".  Announcements concerning these
events are being distributed and are posted at the ICCBR'01 website.

Submission Topics:

The ICCBR'01 Program Committee invites submissions of original research
and application papers on all aspects of Case-Based Reasoning.  Example
submission areas include, but are not limited to:

  * CBR system design issues (e.g., retrieval, similarity assessment,
    adaptation, and indexing)
  * Case and knowledge representation, acquisition, modeling, maintenance,
    and management for CBR
  * CBR inference and process formalization
  * Case-based approaches for planning, scheduling, and design
  * System architectures and integration of CBR with other methods
  * Case-based and lazy/instance-based learning, index learning, and
    integration with other learning methods
  * Collaborative agent architectures involving CBR
  * Adaptive interfaces, user modeling and visualization techniques
    for/using CBR
  * Analogical reasoning, cognitive models, and creative reasoning
    approaches based on CBR
  * CBR-related areas (e.g., corporate memories, decision support,
    intelligent retrieval, networked information discovery, software
  * Case-based reasoning-inspired approaches to education
  * Applications of CBR (e.g., in customer support, education,
    electronic commerce, image processing, legal reasoning, knowledge
    management, manufacturing, medicine, natural language processing,
    quality management, robotics/navigation, WWW)
  * Formal, empirical, and psychological evaluations of CBR models and
  * Methodologies for developing CBR applications

Important Dates:

    Submission Deadline: 17 March 2001
    Notification of acceptance: 13 April 2001
    Camera ready copy due: 11 May 2001

Submission Procedure:

    Authors must submit a full paper plus a title page by the end of
    17 March 2001.  The title page must include: name(s) of the
    author(s); name, address, phone and FAX number, and email of the
    contact person; title and abstract of the paper; a set of
    keywords; a statement whether the submission is to be reviewed as
    a "research" paper or an "application" paper.

    Full papers may be submitted in either of two ways:

    1. Electronically, as a PostScript or PDF file submitted by FTP
       via the ICCBR'01 website (
       This is the preferred mode of submission.

    2. Electronically, as a PostScript or PDF file emailed to

    Electronic paper submissions and title pages may be submitted by
    FTP or be sent by email to  The title
    page may also be submitted using an online form at


                          XSRXXSR                 MERRY
                       XSRXXSRXXSRXX            CHRISTMAS
                    XSRXXSRXSRXSRXXSRXX            AND
                            XSR                   HAPPY
                         XSRXXSRXX              NEW YEAR!

      All of us at SR (TestWorks, eValid, QualWeek) wish you the
      very best for the Holiday Season and for a Happy New Year!

      ------------>>> QTN ARTICLE SUBMITTAL POLICY <<<------------

QTN is E-mailed around the middle of each month to over 9000 subscribers
worldwide.  To have your event listed in an upcoming issue E-mail a
complete description and full details of your Call for Papers or Call
for Participation to .

QTN's submittal policy is:

o Submission deadlines indicated in "Calls for Papers" should provide at
  least a 1-month lead time from the QTN issue date.  For example,
  submission deadlines for "Calls for Papers" in the January issue of
  QTN On-Line should be for February and beyond.
o Length of submitted non-calendar items should not exceed 350 lines
  (about four pages).  Longer articles are OK but may be serialized.
o Length of submitted calendar items should not exceed 60 lines.
o Publication of submitted items is determined by Software Research,
  Inc., and may be edited for style and content as necessary.

DISCLAIMER:  Articles and items appearing in QTN represent the opinions
of their authors or submitters; QTN disclaims any responsibility for
their content.

STW/Regression, STW/Coverage, STW/Advisor, TCAT, and the SR logo are
trademarks or registered trademarks of Software Research, Inc. All other
systems are either trademarks or registered trademarks of their
respective companies.

          -------->>> QTN SUBSCRIPTION INFORMATION <<<--------

To SUBSCRIBE to QTN, to UNSUBSCRIBE a current subscription, to CHANGE an
address (an UNSUBSCRIBE and a SUBSCRIBE combined) please use the
convenient Subscribe/Unsubscribe facility at:


As a backup you may send Email direct to  as follows:

   TO SUBSCRIBE: Include this phrase in the body of your message:

   TO UNSUBSCRIBE: Include this phrase in the body of your message:

Please, when using either method to subscribe or unsubscribe, type the
 exactly and completely.  Requests to unsubscribe that do
not match an email address on the subscriber list are ignored.

	       Software Research, Inc.
	       1663 Mission Street, Suite 400
	       San Francisco, CA  94103  USA
	       Phone:     +1 (415) 861-2800
	       Toll Free: +1 (800) 942-SOFT (USA Only)
	       Fax:       +1 (415) 861-9801
	       Web:       <>

                               ## End ##