You can find the html version of this issue as well as all past
issues at
the Tejas Software Consulting web page - http://tejasconsulting.com/.
My Introduction to Software Testing & Quality Assurance course, offered through the Edison Institute, is next week and the week after, November 6-7, 2001 in Dallas and November 13-14, 2001 in Houston. I hear that there are a few slots still open, so let me know if you or a colleague may be interested.
I was interviewed for the "Faces of the Layoffs" cover story for the October 1 issue of the "Tarrant Business" section in the Fort Worth Star-Telegram. A slightly mangled excerpt is available on the web, and the full text is available from NewsBank for a fee. They also included a color picture of my daughters and me (my wife is still miffed that she wasn't included :-). Let me know if you'd like to see the picture.
I've put together the September issue of the PMI Risk Management Newsletter, and it's now available on the web.
Errata - in the email version of my September newsletter, the URL
for
the test-patterns mailing list was wrong. The correct URL is http://groups.yahoo.com/group/test-patterns/.
Nice issue. Very useful.Jerry indicated that he thinks that he published the triangle problem in PL/I Programming - A Manual of Style (1970) or PL/I Programming Primer (1966). He went on to say,BTW, you may or may not know that I was the originator of the triangle problem that Myers used.
I used it for many years before this at the IBM Systems Research Institute, where Glen taught after me. Perhaps he picked it up there, or from the book, or perhaps reinvented it.Thank you, Jerry - fascinating history. I happened across a reference to the triangle problem in Fred Gruenberger's paper "Program Testing: The Historical Perspective," in the 1973 book Program Test Methods. So now let's find some PL/I books to trace it back further.
Robin Goldsmith responds to Myers' assertion that "Testing is the process of executing a program with the intent of finding errors," and my endorsement of it -
Let me offer an alternate interpretation to this classic notion that the purpose of testing is to find all the errors. When one sets that as one's objective, it is essentially making testing unmanageable because it is impossible to determine whether all the errors have been found. The only way we could be sure is by knowing what all the errors are, which of course we don't and can't.Robin makes a good point, that you need negative tests to gain confidence that a program is working. But negative testing is not the same as running positive tests that fail. Several authors have pointed out that the practice of testing to prove that a program works has problems. In Testing Computer Software by Kaner et al., the authors refer to psychological research that shows that you tend to find what you're looking for (page 24-25). If you want to show that the program works, you're less likely to find bugs (and thus show that it doesn't work) then if your goal is to show that the program doesn't work.Indeed, the purpose of testing is to demonstrate that a program _is_ working. For some unknown reason, though, our industry (which really ought to know better) persists in interpreting "working" to include only half of what it really means:
* "Positive tests" to demonstrate that it does what it's supposed to do.but "working" or "correctness" also should include
* "Negative tests" to demonstrate that it does not do what it's not supposed to do.Only with such a positive definition of our objective can we meaningfully manage what we're doing. The challenge is defining correctness adequately, not hunting interminably for errors with no way to know when we're done.
In Software Testing Techniques, Boris Beizer gives "phases
in
a tester's mental life" (phase 0-4) on page 4. Phase 1 is showing that
the program works, phase 2 is showing that it doesn't work. Phase 3
represents
the consensus of many recent articles, that the purpose of testing is
to
reduce the perceived risk of the software not working. Regardless of
which
direction we approach the task from, it's all about mitigating risk.
Feature Article
What do you do when you find a bug? Do you lament the fact that the
bug
represents a setback for the project? Or do you celebrate the fact that
you found a bug that may otherwise have shown up in the field? There is
a big philosophical difference between these two. Here's my philosophy.
Boom! Celebrating a Successful Test
When I find a bug, I want to celebrate! Yes, you're delivering bad news. A developer will have to spend time fixing the bug rather than writing new ones (new features, I mean ;-). The release schedule could be impacted. There's no doubt that the existence of the bug is a bad thing. But as a tester, the existence of the bug is beyond your control. If someone doesn't find the bugs now, the customer may find them later, and the situation will be much worse. When you do find bugs, your efforts are a success. Your efforts are saving the company money.
When I see an program crash in a spectacular way, I feel an urge to add appropriate sound effects. Boom! Most programs are far too quiet when they fail. Sometimes I may even do the equivalent of an "end-zone dance." Different people celebrate their successes in different ways. One lady just smiled as the total number of bugs she had reported, which numbered in the hundreds, squeaked past my total - I think she'll recognize herself from this description (the counts were just for fun, not a serious metric).
I have no qualms about being proud when I find a serious bug. However, I do have to show some restraint when outwardly celebrating my successes, because after all, they also represent someone else's misery. How I should react to finding a bug depends on the local culture and on my relationship with the rest of the organization (and who's in earshot :-). I also look for opportunities to build up the morale of the test group by recognizing their bug finding successes in ways that don't come across to the developers as gloating.
I've often said that testers must have multiple personalities. So express the appropriate level of concern when you're the bearer of bad news, but also look for opportunities to pat yourself on the back when you prevent another bug from escaping. P.S. If you have the privilege of sometimes working from a home office as I do, you have a unique opportunity to express yourself when you feel the need....
Copyright 2001, Danny R. Faught
#####
| Back to the newsletter index | Back to the home page |