"Our Take" is a regular column from the editors at Software Quality Engineering. It appears in the twice-monthly StickyLetter since its inception in September 2000 (originally "STQe-Letter"). From jazz music, to car troubles, to the Lewis and Clark expedition, Robert Rose-Coutré, former StickyMinds.com Editor, will use anything to make a point about building better software. The editors at Software Quality Engineering have compiled a collection of some of these pieces. Musings from StickyLetter's "Our Take" are presented here.
17 January 2001
I've been watching a Jazz Documentary on PBS and it got me thinking...Is jazz music a software testing topic? Of course it is!
Unit testing comprises an analysis of the technical notation (code) of the piece: checking the key, making sure the notes fit numerically in each measure, depending on the requirements established by the Time (e.g., 4/4 Time). If some notes don't match the key, one must investigate further. The composer (programmer) will no doubt insist the disharmonic tones are intended features for more sophisticated users. Such incidents reflect the importance of CM (composition management).
In integration testing we start adding required instruments to play the notes together and get a feel for the whole composition. Does the horn-line jive with the bass? Does it all come together to fulfill the audio requirements? When it comes to fulfilling audio requirements, acceptance testing and end-user review is "key." The most important release criterion is "Do they tap their feet?" Failure of that function is occasionally user error--but most often indicates a defect in the notation or a glitch during integration.
21 February 2001
Ever put a bug on a hook and go fishing? Sometimes, you never know, you might catch a big fish. When you're testing software and you find a little bug, sometimes when you investigate further you uncover the big defect--the one that will take the system down.
What do we call that--when investigating and fixing one bug uncovers another bug? I had an exchange with Ed Weller (the Quality Engineering technical editor) on the StickyMinds message boards about just that. The conversation led to various distinctions. Ed and I ended up with THREE possible categories of bugs that occur in connection with a previous fix:
1. Recidivist Bug: A bug that pops up again (repeat offender) which was not corrected by the first fix.
2. Side-effect Bug: A bug that didn't exist before but is CAUSED by fixing another bug.
3. Exposed Bug: A bug that was there all along, but undiscovered, until the fix of some other bug exposes this bug.
Then of course, there is the original bug, the one you first put on your fishhook. Sometimes you don't get any farther than that.
What do you think about these categories? You can join in the exchange between usernames "EdWeller" and "coutre" on the StickyMinds message boards, under the topic "Quality Engineering" >> "Measurement."
Give us your stories about the one that got away!
18 April 2001
My car just started making an ominous squeaking sound. I am ignoring it for the time being because of the formidable cost I'll incur if I face it. It still gets me around. I wonder if you have a similar issue with your software project. It's running smoothly, then suddenly there's a squeak, or a little something wrong. The program works, it basically does what it's supposed to do, but there is a little squeak.
"It's probably no big deal." Pressure to release is always a factor, as most projects are behind schedule as a rule. Programmers don't want to be blamed for holding up the release just because of a little "squeak." That's what patches are for. If you are responsible for testing this product, you are probably the only one who will "face it" and investigate to find the cause. That puts you on the spot.
If you think I'm leading up to a solution, sorry. I haven't heard a perfect one yet. But, I AM interested in hearing about the type of squeaks that are likely to be overlooked, but