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 =======+
+======= May 2003 =======+
+===================================================+
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, Inc.
========================================================================
Contents of This Issue
o My Technique for Use Cases, by Michael Reidy
o eValid HealthCheck Subscriptions
o Software Engineering is Illegal (Part 1 of 2), by Boris
Beizer, Ph. D.
o Selecting Your Baggage for the Journey Through Testland, by
Jos van Rooyen
o Response to "Hard Questions" by Claudia Dencker.
o Software Quality Laboratory in Limerick Ireland.
o Special Issue on Activated and Programmable Internet
o eValid Updates and Details <http://www.e-valid.com>
o Subject: I Need a Reliable Vendor
o QTN Article Submittal, Subscription Information
========================================================================
My Technique for Use Cases
by
Michael Reidy
INTRODUCTION
The tremendous growth of client sever and internet technologies has
had a significant impact on Information Technology. Object Oriented
(OO) programming is supplanting the procedural languages of legacy
platforms.
As the initial, beginning step, OO programming mandates thorough
functional analysis. This is followed by system analysis,
development and coding.
Communication of requirement documentation is accomplished with
visual modeling. Accordingly, a series of graphics and diagrams are
used in building an OO application. The Unified Modeling Language
(UML) was developed as an industry standard to aid in this process.
Numerous software tools are available to accomplish these graphics
and diagrams. They are useful in communicating functional needs and
expediting code development.
This article's concern is with a key ingredient of OO analysis. It
is the most basic of all - the Use Case.
THE USE CASE
The Use Case is a narrative of user interaction with the proposed
system. It is subsequently elaborated and illustrated as a Use Case
diagram. In turn, this diagram is the basis for other, more detailed
diagrams and system flows.
The Use Case is constructed by reviewing functional requirements
with the end users. It is composed of brief statements detailing
'actor' intervention with the proposed application The actor can be
a single individual, groups of people or other even other systems.
An actor can also participate in multiple Use Cases. Importantly,
the Use Case should provide value to the actor (s).
Convention requires short, pointed statements as well as active
verbs. The stress is on clarity and communicability.
The UML does allow quite a bit of flexibility in preparing and
presenting Use Cases. It allows various forms and formats (a
narrative in paragraph form, numbered steps with footnotes for
scenario options, numbered steps with scenario options in brackets,
or any other combination, etc.) The key is expressing functionality.
There is no limit to the number of steps in a Use Case. A single Use
Case can contain multiple actors. However, common sense is the
limiting factor (most often, I find a single application shouldn't
exceed thirty steps).
This article will propose a Use Case technique I have successfully
employed.
MY TECHNIQUE
My technique involves two steps:
(1) Building 'micro' Use Cases
I initially develop the Use Case as clearly and simply as possible.
I do this to elicit end user support and approval. I construct
multiple, very elementary functional statements. I use numbered,
sequential steps with detailed footnotes to express possible
scenarios. I use capitals to identify actors.
The individual Use Case names are brief and functionally
descriptive.
(2) Building the 'macro' Use Case
Upon securing end user approval, I then 'massage' the case(s). Most
often this entails combining the initial cases for review and
analysis (though I often combine several micro cases into a single
numbered step).
Again, the Use Case name is functionally descriptive.
ILLUSTRATION
I will illustrate my technique with a very simple Money Transfer
application.
It features a secured, highly structured and formatted, customer
transmission to a bank. It can initiate a transaction in any
currency for which a customer has an account. The transmission
contains detailed instructions to debit the customer account, and
either credit another customer account or transfer the funds to an
account at another Clearing House bank. The transactions can be
value today, post or future valued. If post valued, the payment is
immediately made with a subsequent interest compensation award being
calculated and paid. If future valued, the entire transaction is
stored in an internal queue, pending release on the actual value
date. Other transaction details to be included are consistency with
test word authentication, payee name, payment details, consistency
with corporate standard.
Consider the following micro Use Cases:
CUSTOMER TRANSMISSION:
(1) Customer Treasurer composes Customer Transaction
(2) Customer Clerk data enters Customer Transaction
(3) Customer Clerical Supervisor verifies Customer Transaction
(4) Customer Clerical Supervisor releases Customer Transmission
INTERNAL ROUTING BY BANK:
(1) Bank Telecom Device receives Customer Transmission
(2) Bank Router relays Customer Transmission to Money Transfer
Processor
INSTRUCTIONS VERIFIED
(1) Bank Money Transfer Processor verifies structure and content of
Customer Transmission
(2) Bank Money Transfer Processor records Bank Transaction as
Automatic Posting
- Notes -
1a1 - valid account (continue process)
1a2 - invalid account (send to Repair Queue)
1b1 - valid currency (continue process)
1b2 - invalid currency (send to Repair Queue)
1c1 - amount consistent with test authentication (continue process)
1c2 - amount inconsistent (send to Repair Queue)
1c3 - invalid amount (garbled or decimals not consistent with
currency, send to Repair Queue)
1d1 - valid date (equal to today, continue process)
1d2 - valid date (post dated, continue process but send item to
Compensation Queue)
1d3 - valid date (future date, send to Future Queue)
1d4 - invalid date (no date or garbled, send to Repair Queue)
1e1 - payee name indicated (continue process)
1e2 - payee name not indicated (send to Repair Queue)
1f1 - message details supplied (continue process)
1f2 - no details supplied (send to Repair Queue)
1g1 - message conforms to corporate standard (continue process)
1g2 - message doesn't conform to corporate standard (send to
Repair Queue)
DEBIT/CREDIT POSTED
1) Bank Money Transfer Processor posts debit to Customer Account
2) Bank Money Transfer Processor applies credit
3) Bank Money Transfer Processor forwards outgoing Bank
Transmission to External Processor
- Notes -
2a1 - credit to other Internal Customer
(credit to Internal Account)
2a2 - credit to Account at Clearing House Bank
(credit Internal Omnibus Account)
ONWARD TRANSMISSION
(1) Bank External Processor records transactional details (will be
used in calculating interest compensation award for past dated
transactions in INSTRUCTIONS VERIFIED 1d2)
(2) Bank External Processor sends Bank Transmission into Clearing
House Network
(3) Clearing House Network routes Bank Transmission
Now, my colleagues in bank Money Transfer Systems would agree this
is a very elementary, unrealistic scenario. Additionally, every
reader could probably have formulated different cases, combining
some or altering others (this flexibility is allowed and encouraged
by the UML).
However, my intent is to illustrate an approach to constructing Use
Cases.
Now, let me build the macro case.
MONEY TRANSFER
(1) Customer Treasurer composes Customer Transaction
(2) Customer Clerk data enters Customer Transaction
(3) Customer Clerical Supervisor verifies Customer Transaction
(4) Customer Clerical Supervisor releases Customer Transmission
(5) Bank Telecom Device receives Customer Transmission
(6) Bank Router relays Customer Transmission to Money Transfer
Processor
(7) Bank Money Transfer Processor verifies structure and content of
Customer Transmission
(8)Bank Money Transfer Processor records Bank Transaction as
Automatic Posting
(9) Bank Money Transfer Processor posts debit to Customer Account
(10) Bank Money Transfer Processor applies credit
(11) Bank Money Transfer Processor forwards outgoing Bank
Transmission to External Processor
(12) Bank External Processor records transactional details (will be
used in calculating interest compensation award for past dated
transactions in INSTRUCTIONS VERIFIED 1d2)
(13) Bank External Processor sends Bank Transmission into Clearing
House Network
14) Clearing House Network routes Bank Transmission
- Notes -
7a1 - valid account (continue process)
7a2 - invalid account (send to Repair Queue)
7b1 - valid currency (continue process)
7b2 - invalid currency (send to Repair Queue)
7c1 - amount consistent with test authentication (continue process)
7c2 - amount inconsistent (send to Repair Queue)
7c3 - invalid amount (garbled or decimals not consistent with
currency, send to Repair Queue)
7d1 - valid date (equal to today, continue process)
7d2 - valid date (post dated, continue process but send item to
Compensation Queue)
7d3 - valid date (future date, send to Future Queue)
7d4 - invalid date (no date or garbled, send to Repair Queue)
7e1 - payee name indicated (continue process)
7e2 - payee name not indicated (send to Repair Queue)
7f1 - message details supplied (continue process)
7f2 - no details supplied (send to Repair Queue)
7g1 - message conforms to corporate standard (continue process)
7g2 - message doesn't conform to corporate standard (send to
Repair Queue)
10a1 - credit to other Internal Customer (credit to Internal Account)
10a2 - credit to Account at Clearing House Bank (credit Internal
Omnibus Account)
JUSTIFICATION
Consider what my technique has accomplished:
- The micro cases have allowed the end users to give clearly stated
functional requirements to the technical staff.
- The micro cases have better enabled the technical staff to secure
end user signoff.
- The micro and macro cases have given a clear view of desired
functionality with all interlocking and interdependent functional
needs. System development and coding is greatly facilitated.
- Test scripts and cases can be constructed using the alternative
scenarios presented in the
Use Cases.
My simplistic illustration has resulted in five micro cases. A more
realistic set of needs might well have generated twenty-five!!!
Building the macro case would seem to be an inefficient extra step.
But I strongly feel it's worthwhile. Let me explain why.
The tools used in OO analysis and development do not easily
accommodate numerous Use Cases. It can be exceedingly difficult to
squeeze the graphics for all cases onto a single screen.
The UML does allow another technique. Related cases (the micro
cases) can be combined into packages.
However, packages also result in a somewhat scattered view of
functional needs. For this reason, I avoid them as much as possible.
I prefer that end users, analysts, developers, coders, testers -
anyone who refers to Use Case contents - see all functional details
in one, single spot. I strongly feel this minimizes the chance of
overlooking an important detail.
The macro case presents an inclusive view of system flows and
interfaces.
CONCLUSION
My technique facilitates end user signoff and counters a limitation
to both the UML and CASE tools. (Interestingly, the IT staff often
references the initial micro Use Cases for an undisputed picture of
desired functionality.)
My technique was adapted from work by others (principally Alistair
Cockburn, "Writing Effective Use Cases" and Martin Fowler with
Kendall Scott, "UML Distilled".
You may well see some practicality in adopting (or modifying) it.
The principal concern should always be developing better systems by
documenting and communicating user requirements. I offer my
technique as one way to accomplish this.
BIOGRAPHY
Michael Reidy is a consultant in New York City. He has an MBA in
Finance with additional postgraduate work in Computer Science and
programming. He has over twenty years experience throughout the
financial services industry (in both end user and system staff
functions) and was an instructor for International Banking at NYU.
He holds several professional and industry certifications, among
them Certified Quality Analyst (CQA), Certified Software Test
Engineer (CSTE) from the QAI as well as Project Management
Professional (PMP) from the PMI. He also has published several
articles on QA, Project Management and Banking. Reidy's email
address is .
========================================================================
eValid FREE WebSite HealthCheck Offer
<http://www.e-valid.com>
Do you know how healthy your WebSite really is?
Does it have any broken links? Any slow-loading pages?
Are your WebSite pages optimized to provide for the fastest download
performance?
The eValid WebSite test engine provides a very wide variety of tests
and analyses that help you keep your WebSite healthy.
FREE eValid WebSite HealthCheck
We are now offering on a limited basis a FREE eValid WebSite
HealthCheck that includes a sample of key eValid reports:
unavailable links analysis, detailed page timing report, slow-
loading pages report, and detailed SiteMap.
The FREE eValid WebSite HealthCheck gives you an analysis of part of
your WebSite in automatically generated eValid reports that address
such critical quality areas as:
> An Unavailable Links Report using the LinkCheck feature of
eValid's Site Analysis engine. It shows you client-side
availability failures that you can't detect from the server
side.
> A Slow-Loading Pages Report that identifies, among all pages
downloaded, every page that takes longer than 2 seconds to
download (using a fast DSL connection).
> A Detailed Page Download Timing Chart, produced for one of your
WebSite pages, so you can see how to improve the download
response times for that page.
> A Unique Link SiteMap for the all the analyzed pages that
details your WebSite structure and page dependencies.
How To Get Your FREE eValid WebSite HealthCheck
Complete details about the FREE eValid WebSite HealthCheck,
including sample reports and results, are available at:
<http://www.soft.com/eValid/Promotion/HealthCheck/offer.html>.
========================================================================
Software Engineering is Illegal (Part 1 of 2)
by
Boris Beizer
Note: This article is taken from a collection of Dr.
Boris Beizer's essays "Software Quality Reflections" and
is reprinted with permission of the author. We plan to
include additional items from this collection in future
months.
Copies of "Software Quality Reflections," "Software
Testing Techniques (2nd Edition)," and "Software System
Testing and Quality Assurance," can be obtained directly
from the author at .
Since the publication of this essay in 1995, Texas has been the
first to recognize Software Engineering as a legal profession. The
University of Texas was quick to follow with being the first to
offer Software Engineering degrees by that name -- although many
universities offer such degrees, de-facto, none in the U.S. had
offered them de-jure. We have 49 states and five territories still
to go -- so this essay is still germane.
1. What's The Fuss?
The 30 May 1994 issue of ComputerWorld carried a provocative story.
One of our colleagues in Tennessee, George Phelps by name, ran afoul
of a 75 year old statute that specifies who has the right to use the
title "Engineer." Because of this law, he had to change his title
from "Director of Engineering" to "Director of Technology." His is a
CENSORED Engineering company and CENSORED Engineering is not legal
in Tennessee. Nor, by the way, is it legal in all 50 states and
five territories. If you call yourself a "Software Engineer" or
promote your company as doing "Software Engineering" you may be
liable for fines of up to $10,000, be forced to change your company
name, your title, your stationery, your advertisements,
publications, etc.
The purpose of the Tennessee (and the 54 other statutes) is
ostensibly to "... provide a measure of assurance that an engineer
... will in no way jeopardize the safety, health, or well-being of
the general public." Just who is an engineer and who determines
that? The legal qualifications for using the title "Engineer" in
the United States are:
1. Graduate from an accredited engineering school, where
accreditation is granted solely by the Accreditation Board for
Engineering and Technology (ABET).
2. Pass the Fundamentals of Engineering Examination, created by the
National Council of Examiners for Engineering and Surveying
(NCEE) but administered by the various states.
3. Four years of work experience in a recognized engineering
subprofession, where recognition, although legislated in each
state, is effectively done only by ABET and NCEE.
4. Pass the Principles and Practices of Engineering examination,
also created by NCEE but administered by the states, in one of
the recognized subprofessions.
There are also unofficial, requirements for joining the ranks of
sanctioned professional engineers.
5. Wear a pocket protector filled with Dietzgen #2 to #4 lead
pencils.
6. Own a K&E Log-Log Duplex Decitrig Slide Rule (if you are old
enough to know what that is!)..
7. Be a white, Anglo-Saxon, male who wears a hard hat.
The first four of these might seem to be reasonable standards for
protecting the public. After all, if anybody could hang out a
shingle and call themselves an engineer, who knows what harm might
come of it. These standards seem reasonable until you look into them
and learn:
1. There are no accredited degrees in Software Engineering and
unlikely to be any in our lifetimes -- at least until the current
generation of superannuated creditors dies off.
2. The examinations have more relevance to a Mesopotamian water
works engineer of three-thousand years ago than to software. The
examinations have few questions on electronics no questions on
computer hardware, and no questions on software whatsoever.
3. According to most state laws, you must have a Professional
Engineering (PE) license to legally teach in an engineering
school, otherwise the school or department won't be accredited.
How's that for self-perpetuation generation after generation?
4. Our profession is not recognized and very unlikely to ever be
recognized by the self-appointed, self-perpetuated, self-
interested, official recognizers (ABET, NSPE, and NCEE).
5. Based on the singular lack of success that other "new"
engineering disciplines have had in getting recognized within the
framework of so-called professional engineering (Electronics
Engineering being the most notorious 7), we don't stand a chance.
2. The Legal Engineering Professions.
I'll have more to say about these examinations below. For now, let's
see what kind of "Engineer" is legal in the United States.
1. You can be in one of the recognized major engineering
professions, including: Aeronautical, Agricultural, Chemical,
Civil, Control Systems, Electrical, Environmental, Fire
Protection. Industrial, Manufacturing, Mechanical,
Metallurgical, Mining, Nuclear, Petroleum or Structural -- but
you can't be a Software Engineer, because that major profession,
the profession with more practitioners than the others combined
-- doesn't exist according to ABET and NCEE.
2. You can practice one of the recognized engineering specialties
such as: Gas Engineering, Tool and Manufacturing, Automotive,
Lighting, Safety, Die-Casting, Plastics, Corrosion,
Refrigeration, Pharmaceutical, Lubrication, Photographic, and
Sanitation -- never ridicule our Sanitation Engineering
colleagues and pay daily homage (as we all must) to its spiritual
founder, George Crapper -- civilization would be down the toilet
without them. But you can't be a Software Engineer!
3. You can practice one of the lesser known subspecialties. The
NCEE told me that designation of a subspecialty depends on the
number of practitioners; after all, one "... cannot expect to
certify every tiny-subprofession that has only a few hundred
practitioners." And, surely, all of the following subspecialties
must have many more practitioners than our forbidden specialty:
Arctic Condition Engineering, Cable-TV, Cryogenic, Earthquake,
Heating, Insulated Cable, Lubrication, Noise Control, Optical,
Plumbing, and Wood. But you can't be a Software Engineer because
obviously there aren't enough of us and you can't be a Software
Engineer!!
4. There are societies for engineering sub-subspecialties, all of
which are legal: Senior Wire Rope (I couldn't find an Ordinary
Wire Rope or a Junior Wire Rope?), Annular Bearings, Ball
Bearings, Ball Manufacturing, Carbide, Cylindrical Hydraulic (as
distinct from just-plain Hydraulics?), Practical Refrigeration
(as distinct from Impractical Refrigeration?), Rehabilitation,
Tractor, and Wind -- the last one intrigues me because as a
sometime competitive sailor, I would love to know how to engineer
wind. That's the way the wind blows on sub-subspecialities; but
no matter how hard you huff and puff, you won't be allowed to be
a Software Engineer, because there aren't enough of us. You
can't be a Software Engineer!!!
5. There are other occupations that have traditionally carried the
name "Engineer" and are therefore legal and exempt from these
laws: Flight Engineer, Flight Electronics-, any serving soldier
from private to general in the U.S. Army Corps of Engineers,
Motion Picture-, Radio-, Sound-, TV-, Railway-, Ship's-,
Locomotive- (also known as Mobile Engineer, which comes in both
steam and non-steam flavors) and last and least the Stationary
and Steam Engineer who fires up the boiler in the basement. The
janitor in your office building can call himself an Engineer (if
you have a steam boiler, that is), but you can't because you
can't be a Software Engineer!!!
6. An Engineer can be: concerned, illuminating, abrasive, military,
rough & tumble, or even explosive -- and we all know engineers
that fit those descriptors; each of the previous have their own
engineering society -- but they better not be concerned or
illuminating about software because YOU CAN'T BE A SOFTWARE
ENGINEER!!.
7. If you satisfy the technical criteria for engineering, you can
add another hyphen and go on to be a: Cuban-American-Engineer,
Danish-American-, Native-American-, Hispanic-, Korean-, Polish-,
Swedish-, Turkish-, or Ukrainian-American engineer. You can be a
minority engineer, a black engineer, and even women can be
engineers today. You can be a gay and lesbian engineer, or a
Christian, Muslim, or Seventh Day Adventist engineer -- all these
groups also have their own special-interest societies, but
heavens forfend that you hyphenate "software" with "engineering."
It's not legal in all 50 states and five territories because YOU
CAN'T BE A SOFTWARE-ENGINEER!!!.
Before you start worrying that the PE Gestapo is going to come down
on you like they did poor Phelps in Tennessee, let's note that as
lawbreakers in all 55 states and territories we are in good company.
The biggest lawbreaker is the Federal Government, especially DoD,
who annually lets thousands of contracts with "Software Engineering"
in the title or in the specifications 9 . The FAA and almost every
other branch of the government that buys technical software
similarly mention -- no, they don't merely mention software
engineering, they insist that we practice it. The annual Software
Engineering Conference, now in it's 17th year, as well as dozens of
other annual conferences and symposia on Software Engineering are
also lawbreakers. The Software Engineering Institute is breaking
these ludicrous laws. Purdue University is a lawbreaker. Every
publisher with Software Engineering titles is a lawbreaker. But the
next biggest lawbreakers after DoD are the IEEE and ACM, both of
whom sponsor conferences, publish journals, and have huge hunks of
memberships who call themselves "Software Engineers." If I were
really worried about the PE thought police, I would insist that the
IEEE mail the SE transactions in a plain brown wrapper.
3. The Examinations.
I looked at these examinations: Id rather have root canal without
anesthesia done by Steve Martins sadistic dentist in The Little Shop
of Horrors than take one of these. The first one, Fundamentals of
Engineering, the one you take before you practice, is bad enough;
but the second exam that you take after youve practiced a while,
makes the first look like a give-away.
The first exam is an 8-hour, open book exam in which you answer 140
compulsory questions in the morning and 70 in the afternoon.10
Most of the morning questions are hard-hat engineering questions
including such juicy favorites as: the rate at which a slab of beef
will give up heat, those horrible physics problems that involve two
monkeys, a pulley and a string; and one of your routine four-body
cis-lunar orbital calculations for a slingshot-effect ride past
Mercury to land you in the vicinity of Pluto by June 2007 11 .
There are two morning categories you'll recognize: finance and
mathematics. The earlier exams had a section on computers and
software, but they since expurgated these subjects. The finance
questions are easy -- they're all built-in my calculator. The math
is okay if you remember your calculus 101. But you couldn't count
on passing the software questions when they did have them. About
half involved number representation conversions (also on my
calculator). The tough ones were the programming questions. You'll
have to dig up very old, very obsolete BASIC and FORTRAN manuals to
learn the syntactic and semantic peculiarities of those languages as
of two decades ago. And even that wouldn't help because according
to the answer book, sometimes AND is equal to "OR" and ">=" can be
used interchangeably with ">". The afternoon is more of the same,
but only worse.
How did I do, you ask? Based on my self-administered attempt at
several exams, I would have failed gloriously. I aced the math and
finance, got two "wrong" on the software, picked up fifteen
questions because as an avid sailor and navigator I've learned about
vectors, aerodynamics, and hydrodynamics. Out of 210, had I gone
the whole route, I might have managed 50 or so; possibly more
because it is an open book exam. That was the old exam from 1986
and earlier. The latest study guides and presumably therefore, the
latest exams, have no questions on computers and software whatsoever
so my score would have dropped proportionately. Not only doesn't
software exist for these so-called engineers, but neither do
computers!
How about the Principles and Practices exam that you take after
you've worked in the field for several years? The closest you could
manage would be to opt for the Electrical Engineering exam and try
to hit problems in digital systems, computer systems, and
communications. Frankly, folks. it's hopeless. You're about as
likely to pass as one of our hard-hat colleagues is likely to pass
an exam on software quality assurance or object-oriented
development.
It's a stacked deck; so deeply and thoroughly stacked that unless
you're willing to re-educate yourself in engineering archeology and
spend several years cramming, you can't possibly make it.
The examinations fascinated me, especially the fact that to the
extent that the samples I saw dealt with software at all, it dealt
only with toy problems in archaic Basic. I called the NCEE and
asked why Software Engineering was not a recognized engineering
discipline and why there were no questions on software. The reason,
according to Roger A. Hadley, of the National Council of Examiners
for Engineering and Surveying was:
"There is no such thing as "Software Engineering". That's just
writing computer programs. Any high school kid or
mathematician can do it. It is not a recognized engineering
discipline because it isn't engineering. And no engineering
school in the United States provides a degree in it --
whatever did you call it? "Software Engineering"?
Yes, my fellow "high-school kids," anybody can do it!
(To Be Continued)
========================================================================
Selecting Your Baggage For The Journey Through Testland
Jos van Rooyen
CMG Oost Nederland B.V.
Meander 901
Postbus 7015
6801 HA Arnhem
email: jos.van.rooyen@cmg.nl
Introduction
Everything we do is limited by time and space. Whether you are
building a house or going on holiday. When building a house you have
specifications and materials. If you want to go on a holiday you
pack some essential items in your backpack and off you go. You take
different types of clothing depending on where you are going. You
take special clothing for a winter trip, just as you do when you are
going to a tropical resort. You have to collect your baggage and
maintain it. The baggage you need depends on the type of journey you
want to make and the role you want to play when you get to your
destination.
The need for baggage is not restricted to holidays; you also need it
to perform your (test) activities. Through schooling and study, you
collect a great deal of intellectual baggage that comes in very
handy in your daily activities. As a tester, you frequently find
yourself on the border between business and ICT. This demands a
different type of knowledge. Test knowledge is one of these types of
course, but there are others. For example, there is business
knowledge and ICT knowledge. In addition, this baggage must be
collected and maintained, as well.
Why do you need knowledge? There are different reasons. If you want
to conduct a test well, you have to know what you are talking about.
So that you are able to test whether the product meets the quality
requirements that have been set. Many projects succeed or fail
because of the qualities of those performing the tests. For
projects, it is essential to select the right people with the right
skills for a job. Costs are another factor. The better the quality
of an information system, the lower the maintenance costs, in
particular for corrective maintenance. To realize such an objective
you need people with the right knowledge.
To determine what knowledge is needed you can use a so-called
knowledge quadrant. This quadrant is described in this article. The
knowledge you need depends on the role you fulfil and the type of
system or organization in which you are working. The quadrant can
serve various applications.
The knowledge quadrant
The quadrant describes the domains about which the tester must have
knowledge. Figure 1 depicts the knowledge quadrant.
--------------------+---------------------
Business Knowledge | ICT Knowledge
--------------------+---------------------
Test Knowledge | Social Skills
--------------------+---------------------
Figure 1: The Knowledge Quadrant
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What do the Four Parts of the Quadrant Contain?
The "business knowledge" section contains the knowledge of the
substance and knowledge regarding the customer organization. An
example is financial knowledge. For example if you want to be able
to test a mortgage system adequately you must know something about
this substance if you want to be able to test whether the
information system satisfies the requirements set. Depending on the
quality of a design, the need for this substance knowledge can
increase. In addition to the substance knowledge, knowledge of the
organization is also important, e.g. process knowledge. If you want
to be able to demonstrate that a new or renovated information system
fits in the organization, you must know how the organization is
comprised. The level of the requisite expertise depends on the role
you play in a project or an organization. As a tester, you need in-
depth knowledge of the material. As a testmanager, you can get by
with less substance knowledge, but you need greater knowledge of the
organization.
The "ICT knowledge" section implies that as a tester you can
determine the influence a development method, programming language
or a platform will have on testing an information system. Several
aspects play a role here. In the first place the applied development
methodology plays a role. For example, if you use COOL:Gen as your
development environment you will encounter COOL:Gen syntactical
errors. As a tester you do not have to pay attention to these.
Moreover, the tool monitors the relationship between design and
building. This makes it easier to check whether the functional
requirements have been met. You must know how a development
environment fits together to be able to determine its impact on the
test. To test infrastructure aspects you must have knowledge
regarding architectures. How is a web configuration put together?
How can I conduct an installation test on one? How is the
installation test influenced by the configuration used? Another
important aspect for you as a tester is to know how a program is put
together. You must develop a feeling for the type of errors that can
occur and in particular where these can occur in the information
system. Knowledge of ICT prevents tests from being performed
unnecessarily.
For testers the third quadrant, "the test knowledge", is of course
the most important. Just as you can distinguish various sub
disciplines within development, you can also distinguish different
sub disciplines within the testing profession. Some of the sub
disciplines within testing are test automation, test management and
test consultancy. The requisite knowledge depends on the sub
discipline(s) in which you are working. The requisite test knowledge
can be split into knowledge regarding the different test methods,
the different test techniques that are available, both functional as
well as non-functional, and the different test types. For example,
think of a conversion test, a load test and a usability test. If you
are working in the sub discipline test automation, it is of eminent
importance that you know what test tools there are and when you can
use them.
The fourth, but certainly not the least important quadrant contains
the "social skills". As a tester, no matter what your role is, you
must regularly present people bad news or serve as a corrective
force in a project. This may comprise as much as half of your
activities. The messenger bringing the bad news frequently gets the
blame. The manner in which bad news is presented is extremely
important. Frequently a programmer has an emotional tie to his
product. If a tester approached such a programmer and says. "ha, ha,
I found an error", it is not hard to predict the outcome of the
conversation. A tester must be able to convey bad news in a
constructive, supporting manner. A tester must have skills such as
conflict management and negotiation skills. Of course, depending on
the role. Frequently you have to take the company culture into
account.
Roles & Type of Information Systems
The knowledge quadrant described is a basic idea. The quadrant must
be tailored to the role you will be playing. Depending on the role
there will be more emphasis on specific skills. As testmanager the
skills within the business quadrant will be less important than the
skills within the social skills quadrant, for example. As test
advisor, you must have a great deal of knowledge regarding all sorts
of sub-disciplines within the test. In that case not only knowledge
of the test quadrant is important; social skills also play an
important role. Interview techniques and skills in making
recommendations are extremely important as a test advisor. The
requisite knowledge must be tailored to the role you play as a
tester within the specific project.
The requisite skills are not only influenced by the role, but also
by the type of information system. Technically oriented projects
require different expertise than those required by functionally
oriented projects. For example, if the project involves a new form
of insurance, substance knowledge within the business quadrant is
important to you as a tester.
Applicability
Developing a knowledge quadrant and applying it is great, but how
can you use it? There are a number of different applications for
this:
* Setting up a test team. By closely examining the requisite skills
and matching these to the skills of the testers you can put the
right team together at the right moment in a project.
* As an organization but also as a tester you can gain insight into
the requisite training for a department or a project. Of course,
this depends on the role you play and the environment in which the
company is operating. Depending on the role you can prioritize
your trainings.
* Applying the knowledge quadrant as part of an assessment of your
test organization. By mapping out the individual skills of
everyone within a test organization in general terms using the
knowledge quadrant, you can gain insight into the strengths and
weaknesses of the employees within your test organization. The
information obtained can be used to formulate proposals for
improvement.
* That automatically brings us to the fourth point - offering a
career perspective. Insight into the knowledge and the various
possible roles within a test organization can help develop a
career perspective.
* Setting up curricula for trainings in the testing profession. The
profiles of the various roles in combination with the knowledge
quadrant can serve as a basis for setting up trainings.
Amassing knowledge
Independent of the role that you play, you must have a basic
knowledge of all the quadrants. This knowledge can be obtained
through regular trainings in courses related to your profession or
by taking special courses. The test knowledge quadrant in particular
must be kept up to date using follow-up courses.
Depending on your role you need specialized knowledge in one or more
quadrants. This knowledge can be obtained in different ways. Through
schooling, research, conducting projects, coaching and the like.
Knowledge profiles can be drawn up depending on the role you play. A
training profile can be associated with a specific profile.
Conclusions
The Article starts with the remark "baggage is a theme in our
activities". In order to select the right baggage you need a frame
of reference. This frame of reference can be described using the
knowledge quadrant. A winter sports holiday requires a different
sort of baggage than you would take if you were going deep sea
diving. Properly applying the quadrant ensures that testers have
the right baggage for testing information systems properly. This
improves the quality of the information system. An additional
benefit is that the costs for corrective maintenance in production
will be reduced.
Knowledge must be maintained. That is why it is important to review
the quadrant periodically or when changing roles in order to define
any additional baggage that may be required.
A well-considered mix of skills selected from the knowledge quadrant
is the key to success for every project or organization.
========================================================================
Response to "Hard Questions"
by Claudia Dencker
Here are my thoughts on your first tough question.
> ECONOMIC ISSUES. Everyone in the QA/Test community is suffering
> -- is this news to any of our readers? What are the factors
> holding back QA & Test business. How do consultants, and small
> business operations survive the slowdown?
A key factor holding back the QA and Test business in the US can be
answered quite simply: off-shore work. We have seen far too many of
our projects be handed over to off-shore enginers and off-shore
companies who are doing a superb job of it. US engineers need to
wake up and smell the roses; their jobs are going somewhere else and
"it sure ain't here."
Another factor is over-supply of QA/test tool and service vendors in
the US. The software industry has matured enough where there are
LOTS of QA-focused companies and QA professionals. This is quite
different from just 10 years ago. The space is crowded.
How do we survive? Be creative, think outside the box, reinvent
yourself, and don't be limited by pride.
My thoughts for the day!
Regards, Claudia
========================================================================
Software Quality Research Laboratory in Limerick Ireland.
Some of the positions advertised from the Careers link at
<http://www.idc.ul.ie/~mark/sqrl/> are still available. There are
also positions open for Ph.D. students.
The advertised positions are not the usual PostDoc positions.
Although a Ph.D. or equivalent research accomplishment is required,
the positions are remunerated at a higher level than is usual for
people who have just completed their Ph.D. They are positions for
more senior researchers who have acquired experience in software
development or related experience well beyond the Ph.D.
These positions offer the opportunity to work as part of a highly
qualified research team under the leadership of a researcher who has
been contributing to the software Engineering field for more than 30
years. The team will work closely with industry to be sure that the
results it obtains are applicable in practice.
========================================================================
Special Issue on Activated and Programmable Internet:
The Converging Technologies for the Internet Based Active,
Programmable & Computing Systems.
Journal of Computer Communications
Guest Editor: Prof. Javed I. Khan, Kent State University
Latest Information for the call for paper can be found from:
<http://trident.mcs.kent.edu/~editor/>
SCOPE: Over the last few years a number of paradigms have emerged
on the converging theme of the activated Internet. Paradigms trace
back to vastly different origins, but converge on the unifying
themewhere the Internet is not only a large network but also a
confederated computing and communication platform. The spectrum
ranges from grid networking, content services networking, active and
programmable networks, sensor computing to the very recent automatic
computing.
" Application services on peer-to-peer networks have recently
toppled the Web as the leading consumer of backbone bandwidth.
Active proxies are opening a new horizon for such services. "
Active networking aims at new network services by adding
programmability to network devices. " Programmable networking is
exploring how the existing protocols on internetworking devices can
be made versatile by making their features programmable via open
interfaces. " Grid computing targets scientific computing over
massive number of networked computers, supercomputers, and massive
storage. " The latest-- automatic programming envisions the
internet as the ultimate computing platform where resources can be
adaptively congregated, used, and dismantled- all based on services
need.
The objective of this special issue of the Journal of Computer &
Communication is to showcase some of the brilliant and recent
research in these convergent paradigms which merit potential cross
fertilization. Authors are encouraged to submit high-quality papers
dealing with original and innovative results along the themes. Both
theoretical and practical results are highly welcome. Topics of
particular interest include but are not limited to the following:
" Theory, Model & Framework o Languages and models of network
programmability o OS and environments for network programming o
Models & framework for netcentric applications & services "
Architectures & Protocols: o Programmable network architecture &
hardware o Server architecture for web based computing & service o
QoS, resource management & synchronization of active systems o
Security and privacy models for safe internet computing o Ubiquity,
global portability and mobility architectures o Peer-to-peer systems
with programmable transport protocols. o Extensible network
signaling protocols o Service dissemination and discovery protocols
" Applications & Services: o Services on active and programmable
networks. o Integrated content and application services involving
proxy. o Sensor computing. o Grid applications. o Automatic
services & applications.
IMPORTANT DATES Submission: August 30, 2003 Acceptance decision:
November 1, 2003 Final paper due: March 1, 2004 Publication date:
Spring 2004
SUBMISSION GUIDELINES Authors are invited to submit full papers less
than 25 pages, following the templates available from the publisher
at http://authors.elsevier.com/ in electronic form (PDF preferred)
to the Guest Editor at the following address:
Prof. Javed I. Khan
Department of Computer Science
Kent State University
233 MSB, Kent, OH-44242
Email: javed@kent.edu
========================================================================
eValid Updates and Details
<http://www.e-valid.com>
New Download and One-Click Install
You can qualify for a free evaluation for Ver. 4.0 including a "one
click install" process. Please go to:
<http://www.soft.com/eValid/Products/Download.40/down.evalid.40.phtml?status=FORM>
If for some reason the eValid license key robot doesn't give you the
EVAL key you need, please write to us at and
we will get an eValid evaluation key sent to you ASAP!
eValid Bundle Pricing
The most-commonly ordered eValid feature key collections are now
available as discounted eValid bundles; see:
<http://www.soft.com/eValid/Products/bundle.pricelist.4.html>
You can compose your own feature "bundle" by checking the pricing
at:
<http://www.soft.com/eValid/Products/feature.pricelist.4.html>
Check out the complete product feature descriptions at:
<http://www.soft.com/eValid/Products/Documentation.40/release.4.0.html>
Tell us the combination of features you want and we'll work out an
attractive discounted quote for you! Send email to and be assured of a prompt reply.
Purchase Online, Get Free Maintenance
That's right, we provide you a full 12-month eValid Maintenance
Subscription if you order eValid products direct from the online
store:
<http://store.yahoo.com/srwebstore/evalid.html>
========================================================================
Subject: I Need a Reliable Vendor
From: "Mitzi Newell"
Greetings,
We need a vendor who can offer immediate supply.
I'm offering $5,000. US dollars just for referring a vendor which is
(Actually RELIABLE in providing the below equipment).
Contact details of vendor required, including name and phone #. If
they turn out to be reliable in supplying the below equipment I'll
immediately pay you $5,000. We prefer to work with vendor in the
Boston/New York area.
1. The mind warper generation 4 Dimensional Warp Generator # 52
4350a series wrist watch with z60 or better memory adapter. If in
stock the AMD Dimensional Warp Generator module containing the GRC79
induction motor, two I80200 warp stabilizers, 256GB of SRAM, and two
Analog Devices isolinear modules, This unit also has a menu driven
GUI accessible on the front panel XID display. All in 1 units would
be great if reliable models are available
2. The special 23200 or Acme 5X24 series time transducing capacitor
with built in temporal displacement. Needed with complete
jumper/auxiliary system.
3. A reliable crystal Ionizor with unlimited memory backup.
If your vendor turns out to be reliable, I owe you $5,000.
Email his details to me at: powercrystals@unicum.de
========================================================================
------------>>> QTN ARTICLE SUBMITTAL POLICY <<<------------
========================================================================
QTN is E-mailed around the middle of each month to over 10,000
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 March
issue of QTN On-Line should be for April 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.
TRADEMARKS: eValid, SiteWalker, TestWorks, STW, STW/Regression,
STW/Coverage, STW/Advisor, TCAT, and the SR, eValid, and TestWorks
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:
<http://www.soft.com/News/QTN-Online/subscribe.html>.
As a backup you may send Email direct to as follows:
TO SUBSCRIBE: Include this phrase in the body of your message:
subscribe
TO UNSUBSCRIBE: Include this phrase in the body of your message:
unsubscribe
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.
QUALITY TECHNIQUES NEWSLETTER
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
Email: qtn@sr-corp.com
Web: <http://www.soft.com/News/QTN-Online>