[^^mac] [TECH main] [TOC]The purpose of this "short course" is to try to distill down the essentials of testing. Mainly testing is a philosophical approach to increasing the quality of a product. Since my expertise is mostly in the realm of testing software (and software-based products), I will keep to that area; as Bertrand Russell put it: Of that which you know: Speak. Of the rest remain silent. Testing is the art of breaking a system and very carefully recording how you did it. Any system can eventually be broken, but of course not all of these scenarios are necessarily "reasonable". Thus, we look to create a series of "test cases" that outline a path of destruction (some-times refered to as "using the system") by which we can tell how well a product performs. We have all used various systems which have frustrated us in one way or another; eg, The system is too slow. It's now clear whether the info we entered was accepted or not. We can't correct the info that we entered. We forgot our password and so we are forced to create a new account. The system just plain screwed up. The job of the tester (and believe me, it is a THOROUGHLY thank-less one!) is to try to identify problems with a system before the customer gets their grubbly little protruberances on it! We often refer to "problems" as "bugs". This is in deference to one of the grand old ladies of programming, Grace Hopper, who was working on one of the first computer systems on the planet earth in the 20th century. They found that some-times moths could get stuck in the so-called "relay" anc cause faults. When asked what the problem was, she replied to her superiors, "We are having to debug the system". (Or so the story goes). There is a classic "waterfall" model of the cost to fix a bug: If the designer (programmer) finds the bug, it costs $1 to fix. If the unit-test team (programming department) finds the bug, it costs $10 to fix. If a tester (testing department) finds the bug, it costs $100 to fix it. If a customer finds the bug, it costs $1000 to fix it. If all of the customers find the bug, everyone will be on the street looking for a new job. Our job as testers is not JUST to find bugs, but to find them in a SYSTEMATIC & REPEATABLE way. It does no good to discover the magic elixr of life, if you lose the receipe. Thus, the key is to document exactly how the tests are to be performed, and then to be able to follow the out-line, and repeatably demonstrate the working or non-working of the system. Before we dive right in, we need to mention a few things. (Or a brief (and semi-humorous) look at the "definitions").... "System". This is one of the most over-worked words in use through-out the universe! For us, it means the "thing" that we are testing; that we are focusing in on. We might be treating a hand-held calculator as THE system. Or the system might be the entire data-processing "system" of a credit-card processing service. We will oftne speak of the "SUT" (System Under Test) or even some sub-component of it; eg, the "DUT" (Device Under Test). Basically, it's the "thing" that we are looking at. "Quality". It is a good buzz-word. For our part, it means that the product satisfies the customer's requirements. Now the customer many times may not even really know what they really want. They may have some vague idea of how the system (product) is supposed to work. But, more often than not they are painfully un-aware of all of the larger portions of the system and its contact with the outside world. Note that the design group, the customer themselves and the odd body around judges quality by the degree to which the product conforms to the contract and/or meets the customer's expectations. Note that these are in NO WAY the same as "satisfying the customer's requirments". There is much vast ignorance of this fundamental axiom. We as testers are even more pain-fully aware of this ignorance. But, no one listens to us -- we're "just" testers. None the less even with such imperfect understandings, mis-communications, and the in-evitable finger-pointing, yelling, and legal actions (it's the yelling I hate the most), we are well prepared. For we have a secret weapon. "You can not test quality into a product". It is a famous phrase and what it means is that if the implementation is not right (or sufficiently right), then the "quality" will not be there. It's basically saying that at the "testing stage" of the "game", when we find bugs, this isn't really creating quality in the product. We could have told them that in the first place. As testers, we simply try to find every bug in the system. But, as testers we know that this is impossible. That's definitely something that "they" don't want to hear. "The They" and "The We". Everyone (the customer, the product mangagers, customer service, the designers) -- the "they", tell us that "we" (the testers) are an integral part of the team, that we're just as important as anyone else on the team. But, of course, that's all hog-wash. First time something goes wrong they (the "they") start looking for some-one to blame. The main question used to locate the blame-ee's is this: "Who had their hands on the product last?" Inevitably comes the response: Those @#%$(~!!! Testers! Then the next line in the Script is: Why didn't they find this @##$&&!!! bug??? Next comes the fire-ing of the testers. (as the curtain goes down, the poor happless tester is being escorted from the building). -- Such is the life we lead. But. We are all that stand between order and chaos. We are all that keep planes from falling out of the air, from power failures occurring over and over, from telpehones being out of order continually, from credit card systems from continually re-charging you for something that was supposedly cleared up 2 years ago. For lo, the designers, customers, and product mangagers, yeah verily, even the lawyers themselves believe in THE SYSTEM. But, we all know that's hog-wash. In all of their reckless and cockamamie "beliefs" and "thoughts" about the THE SYSTEM we know they are self deluded. For we only believe in one thing: The Dark Lord: MURPHY. It is this one bit of knowledge that preserves us. It is this one bit of knowledge in the absoluteness of MURPHY that gives us that little bit of power that we have. The power to destroy. To break. To obliterate. In short: To Test. Mr. Murphy (or Mz. Murphy, or Ml. Murphy -- for even I will not hazard a guess as to the gender or lack-there-of or multi-plicity there-of of such a powerfull deity/principle). "Murphy may doze, but s/he never sleeps". "If anything can go wrong, it wiil". "If two things can go wrong, then the worser of the two will go wrong". "If there are several things that can go wrong, then the one which seems the most obvious and easiest to fix will go wrong, there-by masking a much more devious and much more harmfull thing to go wrong". "If there are two components that can break down; then the more scarce/more-expensive of the two will break". Well, I know I could go on, and if you decide (for what-ever dark, and bizarely masochistic reasons of your own) to become a tester, let me just give you one bit of worldly wisdom: "Don't blame me, I'm just the tester. And another thing...." (it is at this point that the tester is booted out the door, and isn't even allowed the luxury of saying: I told you so. We next look at the classic water-fall method of developing products. Strangely enough, this model is considered obsolete and to have been replaced by much newer and more lustriously polished new versions of the development cycle. But, we as testers know that it's just the same old thing, with a new name, new nomenclature, and (just to throw everyone off): A new hat. Fare thee well, oh tester! Next: The Software Development Life Cycle (SWDLC) Back to the Table Of Contents Back to the main TECH page Back to the MAC home page00-00 Introduction and Opening Perisflage
