The Journal of Software Testing Professionals
December 2002 Issue
(Full articles are available in the "Members Only " area.)
The December 2002 issue includes:
Articles:
Departments:
Previous Issues:
JSTP is a quarterly publication of
The International Institute for Software Testing
Articles
Application
of the IEEE 829 Standard as a Basis for Structuring
the Testing Process
Adalberto Nobiato Crespo, Marcia Regina Martins
Martinez, Mario Jino, Miguel de Teive e Argollo Junior
The IEEE Std 829-1998 is a standard for software test
documentation which can be very useful to help software
houses to structure their software test projects. However,
its application on real projects is not straightforward
and many companies face difficulties when trying to
use it. These difficulties may be explained, at least
in part, by the fact that the standard is somewhat vague,
lacking many details about the contents of the sections
comprising the proposed documents.
Aiming to help alleviate this problem, the Software
Test Group at CenPRA has developed two guides which
constitute the basis for a method proposed for the deployment
of the software testing processes based on the IEEE
Std 829-1998’s usage. In the first one, “Guideline
for the Elaboration of Software Test Documents”,
the information needed to produce the documents proposed
by the standard and its flow is described; in the second,
“Processes for the Elaboration of Software Test
Documents”, the processes for the production of
the IEEE-829’s documents are presented. An outline
of those two guides is given in this paper.
Bruce F. Schoor
The endgame in a software development project is the
period between the completion of the last feature (a.k.a.
Code Complete) and Ship. This period has many interesting
challenges because the exact amount and nature of remaining
work is not known, and team members work with dynamic
task lists. How do we arrive at Ship with the required
quality in the shortest time possible? Which defects
do we still fix? How do we safeguard the targeted quality
at the moment we ship? How do we keep the team morale
up during this demanding period?
This paper presents important lessons learned during
the numerous endgames that I have driven in demanding,
world-class environments such as Microsoft Corporation.
Rather than elaborating on optimized testing strategies
or metrics models, this paper focuses on pragmatic best
practices that have been the key success factors in
past endgames.
Gary E. Mogyorodi
This article provides an overview of the Requirements-Based
Testing (RBT) process. RBT is a rigorous process for
improving the quality of requirements and for deriving
the minimum number of test cases to cover 100% of those
requirements. RBT is comprised of two techniques: Ambiguity
Reviews and Cause-Effect Graphing.
An Ambiguity Review is used in the requirements phase
of software development to identify ambiguities in functional1
requirements. The intent of an Ambiguity Review is to
identify anything that is unclear, ambiguous or incomplete
in the requirements. The elimination of these ambiguities
improves the quality of those requirements.
Cause-Effect Graphing is a test case design technique
that is performed once requirements have been reviewed
for ambiguity, and after they have been reviewed for
content. Requirements are reviewed for content to insure
that they are correct and complete. The Cause-Effect
Graphing technique derives the minimum number of test
cases to cover 100% of the functional requirements to
improve the quality of test coverage.
This article addresses the first RBT technique - the
Ambiguity Review. A follow-up article will discuss the
Cause-Effect Graphing technique.
Marc Rene
Recently, I was asked to investigate and create a Release
Notes Standards document to improve the content, format
and consistency of my company’s Release Notes
documentation. After searching the Web and various Software
Engineering books, I discovered that there is little
information on this topic. As a result, I had to rely
on information obtained during interviews I conducted
within my company. Our experienced Test Engineers and
Software Engineers were asked what they considered ‘good’
and ‘bad’ practices with regard to Release
Notes. The data was compiled and the Release Notes Standards
document that resulted became the basis for this article.
Columns
Magdy S. Hanna, Ph.D.
Most testers shy away from sitting in any kind of review
or inspection. Some feel they do not belong there. Others
do not see the value reviews and inspections may bring
to them. The only type of reviews that most testers
feel somewhat comfortable with is requirement reviews.
Certainly, participating in requirement reviews is an
absolute minimal requirement that is expected of every
test professional.
Of course, testers are supposed to ask questions to
clarify requirements and eliminate ambiguities. But,
this all depends on the form in which requirements are
Jamie L. Mitchell
Simplicity: What a Concept
OK, I’ll admit it – I think everyone should
be able to cook a gourmet dinner, kill a bear, fly an
airplane, and program test automtion[1]. Unfortunately,
this is yet another case of where our school system
has failed us![2] Specialization appears to be the bane
of civilization.
In the last issue, we discussed how to utilize the
architectural concepts (covered previously) to mass
produce automated test cases in those non-trivial numbers
that we need. In this issue, we will discuss a concept
that is absolutely essential if we want our automation
architecture to be successfully utilized by the other
members of our group.
Many people in software development are specialists
at what they do. They are not only programmers;they
are C programmers for Unix systems. They are not just
network specialists; they are experts at 8255x Ethernet
connected networks. One of the few exceptions to specialization
in the IT game is testers. In many cases, testers are
expected to be generalists. Technical enough to perform
white box testing, business savvy enough to understand
the needs of the end users, mathematically inclined
to handle the metrics and chart the trends.
My experience is that testers usually have a very good
set of skills – often, they just do not happen
to include programming skills.
Rebecca Staton-Reinstein
Working At Quality is a new column that will focus
on practical aspects of quality and case studies from
successful implementations of quality techniques. Readers
of this Journal know the importance of robust testing
but that is only one aspect of quality. This column
will be based on two definitions of quality.
The first definition comes from J.M. Juran: Quality
is fitness for use. This customer view of quality must
always be paramount as we define the requirements for
any software solution.
The second definition comes from W. Edwards Deming:
Quality is the continuous improvement of all processes.
This is an operational definition that shows us how
to produce a product for the customer that is fit for
use. The success of the testing process or any other
quality technique often depends on the strength of other
processes that are in place. When development processes
are weak, testing must bear the brunt of trying to find
bugs when there are poor or no requirements. The sophistication
of the testing process is constrained by the sophistication
of the development process. When the development process
is more mature, with robust reviews in place, the testing
function can concentrate on more advanced techniques.
Send us a brief description of your real world experiences
implementing quality techniques. We will contact you
to get the details for an upcoming column.
Magdy S. Hanna, Ph.D.
