Tejas Software Consulting Newsletter
v3 #6, December 2003/January 2004
It will leave you
confused and unable to operate heavy machinery.
This month's quote is by Tim Lister, from the preface to Lessons Learned in Software Testing.
He was explaining what would happen if you read the book without having
prior experience on a software project. Read on for much more about the
books on my shelf.
If you're holding this in your hands or reading it in your web browser,
you're at great risk of being a one-time visitor!
Visit http://tejasconsulting.com/newsletter/
to sign up for the email edition, to make sure you receive new issues
as they are published.
-Danny R. Faught, Software Alchemist
faught@tejasconsulting.com
-- http://tejasconsulting.com/
-- +1-817-294-3998
ISSN 1545-8865
Contents
Tejas Newswire
I recently gave a private training course in San Diego, using Linda
Westfall's "Software Testing" course materials for the first time. I'm
now discussing training possibilities with some other clients, in an
attempt to revive my training business. Let me know if you'd like to
beef up the skills of the testers on your team. Here's another volley
in the certification debate
- this client told me that my CSQE certification had a tangible effect
when they chose me over a handful of other providers.
If you have the email address drf@metronet.com or something similar in
your address
book, please remove it and use faught@tejasconsulting.com
instead. The drf account was offline for a while, and though it's back
now, it will be permanently deleted soon.
I finally did a release of stress_driver,
a generic stress test tool, on SourceForge. Now that it's easier to
install, it's getting more attention. The tool is working well on
Linux now, but there are still some minor difficulties on Windows.
My article "Let's Hear It for the Underdogs" is the Last Word column in
the STQE 2004 Tools Directory.
I'll have it posted on my web site in a
month or so.
New on Open
Testware Reviews - a survey of screen capture tools,
covering 39 tools that can help catch a software bug in action. Also, I
published a review of The Grinder, a Java-based load testing tool. I
need subscribers to support the many hours I invest in researching
freeware tools, so please consider signing up.
You might have seen the ISSN (International Standard Serial Number)
above. The electronic version of the Tejas Software Consulting
Newsletter is now registered with the U.S. Library of Congress.
Feature Article
Books in the Pipe
I recently realized how many books I had in various stages of my
reading pipeline. When I stacked them up on my desk, I had a hard time
seeing my monitor. I thought it might be fun to step back from the
traditional book review and give a quick hit on everything in the
pipeline.
I'm going to take a risk by revealing that I haven't yet finished
some books that I really ought to have read by now. And since several
of you reading this are the authors of the books I list, you're going
to find out that I haven't read your books yet. For the books I do
mention, a few of you will find out that I don't like your books very
much. For all of you authors that I don't mention, you'll just have to
wonder whether I already read your book, still have it sitting on my
shelf unread, or perhaps haven't gotten around to buying it yet.
I actually finished reading a couple of books recently -
Agile Software
Development with Scrum, by Ken Schwaber and Mike Beedle (2001).
A client of mine is using Scrum, so I read up on what that entails. I'm
completely sold on the merits of Scrum. The process focuses more on
management than low-level development details, and can be integrated
with Extreme Programming. I most like the idea of managing requirements
via a project backlog, basically a prioritized to-do list. There is
some process control theory behind Scrum that I should follow up on - I
think it would be some good justification for Agile skeptics who
believe that the waterfall approach has any chance of working.
The Automated
Testing Handbook, by Linda G. Hayes (1996).
A cute little book, but now outdated and expensive for what you get.
But I believe it's the first book that mentions keyword-driven testing,
which is a subject I've been researching. Linda called the technique
"variable capture/variable playback" back then, and now an updated
version of it is the focus of her company.
I'm still reading all of these books -
Lessons
Learned in Software Testing: A Context-Driven Approach,
by Cem Kaner, James Bach, and Bret Pettichord (2002). I take it in my
carry-on luggage, and also in a survival kit that accompanied my
daughter and I to the emergency room a few days ago (no, it wasn't
broken). I'm on page 96 of 286. This one gave us our quote for this
newsletter issue. Lessons Learned
is like a rich dessert. Once you realize what it is, you want to wolf
it all down, but it's so rich with ideas that you can't take it all in
at once. There's a tremendous amount of wisdom packed into this book,
and it's more up to date than most general testing books.
Just Enough
Software Test Automation, by Daniel J. Mosley and Bruce A. Posey
(2002). In my computer bag. Page 154 of 260. This is the most recent
book that I know of that discusses keyword-driven testing, and that's a
major focus of the book. Overall, I don't think the book is very
well-written, and it's not tied in well with all the other work in this
area. However, I want to get to the case studies on keyword-driven
tools, some of which are freeware.
Pragmatic
Version Control Using CVS, by David Thomas and Andrew Hunt
(2003). Tends to float around randomly.
Page 89 of 159. This is a very well-written tutorial on the CVS version
control program. It doesn't make any pretense about covering the arcane
world of Configuration Management, just the core everyday practice of
version control. It's part of the three-volume Pragmatic Starter Kit.
Bagombo
Snuff Box: Uncollected Short Fiction, by Kurt Vonnegut
(1999). In my gym bag. Page
189 of 295. You were starting to worry that I'm a workaholic, weren't
you? It's very interesting reading stories set in the mid-20th century,
and I can finish a few of them while riding the stairclimber.
Free Software,
Free Society: Selected Essays of Richard M. Stallman, edited by
Joshua Gay (2002). On my bedside table, though often preempted when
magazines come in. Page 106 of 220. Mostly dry and philosophical. It
gives me motivation to read through some of Stallman's papers on free
software that I haven't bothered to read online before. As with his
software, you're free to copy and distribute his writing. His biography
(Free as in Freedom) was a
much more interesting read, though certainly more frivolous.
Getting Started in
Consulting, by Alan Weiss (2000). On my desk. I've been
re-reading parts of this, because sending out newsletters isn't
sufficient for maintaining a sales pipeline for a consulting business.
I have many unread books on my shelf. My habit of collecting books is
only loosely tied to my reading. These are the books in the stacks that
I'd most like to find the time to start -
Are Your Lights
On? How to figure out what the problem really is, by Donald C.
Gause and Gerald M. Weinberg (1982). I grabbed this when Jerry was
cleaning out his personal library.
Making Contact, by
Virginia Satir (1976). Also from Jerry. Looks like it'll be an easier
read than Satir's The New
Peoplemaking, which I've been putting off for quite a while.
The Medusa
Conspiracy, by Ethan I. Shedley (1980). One of two little-known
novels written by a friend of mine. He used a pen name, and he won't
let me reveal his real name.
Just for Fun: The
Story of an Accidental Revolutionary, by Linus Torvalds and
David Diamond (2001). Can't get enough about open source.
Death March,
Edward Yourdon (1999). Lots of people talk about this one. I never want
to be on another death march project, especially after reading Affluenza: The All-Consuming Epidemic.
Making Process
Improvement Work, by Neil S. Potter and Mary E. Sakry (2002).
These guys have a fabulously successful consulting business just down
the road from me. I bought the book because I need to brush up on my
process skills.
The Pragmatic
Programmer, by Andrew Hunt and David Thomas (2000). Dave was
nice enough to give me the book months ago, so I should get around to
reading it, especially since I like Pragmatic
Version Control so much. Also, their book Pragmatic Unit Testing in Java with JUnit
is on my short list.
Quality Software
Management, volumes 1-4, by Gerald M. Weinberg (1992-1997). I've
seen several references to interesting bits of wisdom recently that I
didn't realize were documented in this series.
These books are currently on order -
Integrated Test
Design and Automation, by Hans Buwalda, Dennis Janssen, and Iris
Pinkster (2001). The final entry on my reading list on keyword-driven
testing.
Professional Java
2 Enterprise Edition With Bea Weblogic Server, by Paco Gomez and
Peter A. Zadrozny (2000), and J2EE Performance Testing,
by Peter Zadrozny, Ted Osborne, and Philip Aston (2002). These are both
relevant to the review of the load test tool "The Grinder" that I just
published in Open Testware Reviews. Perhaps
I should have planned ahead and looked at them before I wrote the
review, but then again, most users don't read the instructions, right?
Various Dr. Suess
books to round out my collection. The request has been sent in
to Santa. My collection is almost complete.
Feedback on the October/November 2003 issue
Robert Rose-Coutré wrote:
Your
article "What Is This 'Testing'
Thing?" was a very nice, clear,
and straightforward "in-a-nutshell"
explanation. I can't imagine it raising anyone's ire, as you warned. If
it does, though, I would love to know what the protests might
be.
Thanks, Robert. While no one has disagreed with me yet, two
correspondents
inadvertently disagreed with each other. Prasad Tammana sent this in:
As always I had fun
reading your letter. Here I how I would define my erstwhile
testing job: "My job is to ensure that the software does what it's
meant to do."
That means:
- It meets the functionality requirements.
- It meets the performance requirements.
- It meets the compatibility requirements.
- It has no undesirable side effects.
- It'd accomplish all of the above on all supported
system configurations.
- It has all the right specifications.
- Provide the tools to automate all of the
above... may be except the right specifications part!
Now you can tell me why I'm wrong :-)
Actually, I'm concerned about one point. First, here's Mark Wiley's
definition:
My
short and sweet definition is "Software testing is the attempt (which
is usually successful :-) to prove that the software doesn't work".
How's that for short and pithy :-?.
I couldn't have asked for better newsletter fodder than two opposite
definitions of the same thing landing in my mailbox on the same day.
Mark, I like your definition better, because it motivates testers in
the right way. If a tester sets out to prove that the software works,
they want to be successful. In that sense, it means not finding bugs.
Some time ago I remember a discussion on a mailing list about the
psychological effects of the goals that we work toward. I wish I could
remember the reference. Personally, I'd rather set out to find bugs and
fail than to subconsciously want to not find any bugs, and possibly
miss a bug as a result. See my article "Boom!
Celebrating a Successful Test" for more in this vein.
Now with that said, I'll also point out that senior managers are most
likely to use Prasad's definition. They want the software to work, and
they want the tester to prove that it does. But it's impossible to
prove that software works in all possible situations. The best you can
do is to fail to prove that it doesn't work.
Alex Faught wrote:
I
don't understand why computers are so hard to work with.
Alex, in my last newsletter I drew a comparison between software and
more tangible things like tall buildings and ships. You can imagine
that it takes a lot of work to figure out where every part should go in
a new skyscraper or a new kind of ship, and to decide what materials
those parts should be made of. People have been making buildings and
ships for a very long time - hundreds of years. Our buildings generally
stay together the way they're supposed to, and our ships usually float,
because we've learned a lot by trial and error. But people have only
been writing software for only about 60 years. An average software
application is just as hard to create as a skyscraper or a big ship,
but we haven't had nearly as much practice learning how to do it well.
I promise we'll be better at it after a few hundred years.
Mike Durrigan replied to my statement that testers often have a better
big-picture view of the software than developers, and that testers
sometimes also serve in a quality assurance role:
Amen,
I say to you, a thousand times... Amen, Amen, Amen, Amen. May I
also add, we often may appear more eccentric and sometimes outright
weird and
looking at things in an entirely too anal way, but in my experience
testers are far less likely to make excuses for
major and even medium glitches in the software, nor likely to call
users
stupid or illogical because the user happened to expose a hole in the
software
product in a way which the developer doesn't approve of. We are
the last line of defense and paid be "User Advocates."
In my experience, developers are
generally under so much pressure to produce and often have such a
disdain or outdated view of SQA (software quality assurance) and
SQC (testing) function that they rarely take time for quality
assurance, and undervalue the testing function.
Great article and wonderful
newsletter!
Thanks, Mike - I seem to have really struck a nerve there.
A contact of mine who does software development commented that he was
not really aware of testing as a separate discipline from development.
Testing emerged as a distinct discipline in the 1970s. It seems that
even on large development projects, my contact tests his own code, and
there are no independent testers who do any additional testing. I'd say
this is much more likely in an IT context than on a project to develop
software for the mass market. This is the first case I've
heard of a large project with several development teams and more than
one layer of management, and no specialized testers anywhere in the
picture.
It is possible, though rare, for developers to gain the skills to be
able to tackle all of the testing on a project as well as the
development. The hard part in that case is learning how to test for
emergent system properties like performance, reliability, and security.
Most large projects have testers who are specialized in system-level
testing; their challenge is convincing the development managers that
the developers still need to do good unit-level testing of the
individual components that they build. What happens in most cases is
that testers spend far too much time testing individual
features, to mitigate against the developers not doing good unit
testing, and they spend too little time testing the emergent system
properties.
Wayne Middleton wraps us the feedback this time around:
The
conversational style and the content make for a great read!
Thanks, Wayne. I'm thumbing my nose at all of my writing teachers who
wouldn't let me use an informal style. :-)
Copyright 2003 by Tejas Software
Consulting
#####