17 January 2001
Take Five
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 make you most nervous.

Please send your comments and anecdotes to me and I'll publish some of them in this space in future STQe-Letters. Of course, anonymous stories with only general references to products are expected.

7 June 2001
Some people like basketball, some people like unit testing
some like the NFL, some like the CMM
some like acupuncture, some like function points
some like the Mets, some like metrics
some think out of the box, some in a glass box
some use testers, some test users
some like French, some like C++
some like coffee, some like Java
some like Star Trek, some like Data
some like chaos, some like a UML
some like dogs, some like dos
some like romanticism, some like oo
some like extra crispy, some like GUI

What do you like...?

18 July 2001
I was at a family reunion recently, and of course there was at least one blowup. The usual. One parent criticized another parent's child. Oops. You have to be careful pointing out defects in other people's kids.

Do you ever get the feeling that some developers view their apps as their children? The exercise of creating something, even when it's a collaborative effort, seems to evoke a parental instinct in some. This is a good thing to know when you are a tester. Think of going to a parent and enumerating the defects of his or her child. Of course it's not quite that emotional, but some developers' responses indicate a measure of similarity.

My point? Well, don't hesitate to enumerate defects in the software--but perhaps present the problem as your own, e.g., "I ran into this problem, and maybe you can help me with a couple questions..." You both have the same goal: the well-being of the "child." You get the idea. (BTW, have you seen "A.I."?...talk about a developer treating his app like his kid!)

17 October 2001
You are required to enter your social security and pin
numbers at your bank's Web site.
You are required to pass a test before you receive a
driver's license.
You are required to have your pet tested for rabies.
You are required to stop at a red light.

These are some of the requirements of everyday life. It's easy to see the consequences of not having them. That's why they're called "requirements" instead of "suggestions." If you're not the end user of a software application, you may not always understand the consequences of ignoring the requirements. In fact, you may not even understand the requirements to begin with! Step one in succeeding as a software developer, tester, manager, or QA person is to fully understand requirements and to hold the project to them. That's my opinion. What's yours?

5 December 2001
Why are user requirements so important? Here's a "metaphoric" reason. I just bought a car. My old once-reliable "legacy" car lasted many years with no defects. Then a few signs of wear, then...collapse. My upgrade vehicle is more sleek, reliable, clean, and efficient. What more could one ask in an upgrade? But wait, where are the louvers (you know, the little triangular windows that swing open and let more air in)?! I didn't notice their absence till it came time to use them. I liked using louvers on a medium-warm day. Who decided to eliminate them from the upgrade? No one asked ME about such a decision.

Many software development businesses do have the luxury of personal contact with their customers. My suggestion is, take advantage of it. When it's upgrade time, be sure to have compiled as much information as possible about what users LIKE, as well as their suggested improvements. And yes, before eliminating a feature, be sure it won't result in disgruntled customers. Let's all commit to complete user requirements. And next time, don't take my louvers!

2 January 2002
My project assignment: Make a New Year's resolution. I am the project manager. I have to be sure the requirements are thorough and clear so I know how to plan for following through on my resolution. I have to acquire the resources to ensure project success (e.g., access to health food and a gym). I'll need to implement all the "people skills" I've learned in my vast experience to give pep talks (to myself) and motivate, so that I make a positive contribution to my project's success. Since this project requires overtime offsite (at the gym), I'll keep the project's purpose in mind in order to help maintain discipline during the project's, uh, "lifecycle" (gradually increasing difficulty). I also have to accumulate all the information to be sure the requirements are correct (e.g., nutrition information on packages for menu inspections). As I progress in my agile development project, I'll keep up the exploratory procedures by varying recipes. This can prevent project burnout. I will celebrate the success of my project with fudge brownies and big cigar.

20 February 2002
The Project and the Expedition
Lately I've been reading Stephen Ambrose's book about the Lewis and Clark expedition. The project began with an enormous amount of training and planning. The sponsor (Thomas Jefferson) and the project manager (Lewis) worked together preparing the requirements. They knew they would have to rely on a lot of exploratory testing. Lewis pieced together the right people to make up the team. They were experts in eXtreme Programming. After each iteration, the manager and comanager (Clark) constantly revised the development plans. Many of the initial requirements proved naive and unworkable.

They struggled through the lifecycle like a keel boat pushing upstream through uncharted territory. Ultimately, good project management proved flexible enough to adapt to every development, while keeping the interests of the sponsor as the central priority. The final product didn't have precisely the same set of features initially envisioned, the deadline was pushed back about a year, but all concerned were well pleased with the outcome. The retrospective conducted by the sponsor (they didn't have facilitators in this role yet) revealed that, given all the unexpected developments (scope creep), it would be hard to improve on any aspect of the project.

Speaking of expeditions...Here at StickyMinds we are embarking upon another expedition of our own: version 3.0 of StickyMinds.com. We often receive feedback from our StickyMinds members. Those comments and a lot of other usability goals are driving this project. We'll keep you posted.

6 March 2002
Having trouble communicating with someone? In all the theories of "effective communication" I've been exposed to, there is one universal rule: understand the person with whom you are talking. Find out what makes the other person tick, what their values are, what their style of expression is and why, etc. Rather than cite one of the many books on the subject, we find a good example from a long-enduring source: Star Trek.

The case in point is Captain Kirk's debate with the M-5 multitronic robot. To make a long story short, M-5 was supposed to be a handy tool, but instead, it takes over the Enterprise and attacks Federation ships (surprise). Kirk knows the personality of the robot's creator and understands M-5's hard-coded values and how to communicate with it. Knowing what makes M-5 tick, Kirk uses a series of syllogisms to force M-5 into concluding it must destroy itself, which it does.

While you may not want to use your understanding of a coworker's personality to get them to destroy themselves, you may want to at least achieve buy-in on a project or strategy. Knowing what makes people tick, and adjusting your communication accordingly, works wonders in evoking better responses. You might also gain insight into your own personality and how it colors your message.

Don't be a Dr. McCoy, who spent years trying to push Mr. Spock into responding with more "feeling." Instead, use Kirk's approach, which was to communicate using logic with Spock, and to communicate using emotion with McCoy. The things we learn on TV!

17 April 2002
Why We Call Them Bugs
A waterbug skims silently across the top of a lake, tiny and hard to see. Before you know it, ripples seemingly emanating from nowhere traverse the lake very visibly for dozens of yards. Yes, the lake is your software development project. The tiny unseen bug creates a chain reaction of bumps throughout the program. It's late in the day, you only see the ripples. Now you have to trace them back to the surreptitious little waterbug.

"The early bird catches the bug." Incorporate quality early in the design, as well as test and review early in the building cycle. You'll catch most of the bugs as soon as they land on the lake.

6 November 2002
Sometimes the hardest thing in the world to do is move towards a goal. In a forum on software testing, or in a meeting about a process, for example, a goal might be to share knowledge so that ultimately software gets produced with better quality. One obstacle can be human feelings. A peculiar phenomenon of human feeling is "vehemence," which arises from having an emotional investment in an idea (for whatever reason). If I vehemently disagree with someone, do I move towards "the goal" by expressing that emotion? Probably just the opposite, since vehemence stimulates more vehemence, which fogs perception and intellectual activity until really nothing but fog is exchanged. If I'm really passionate about "the goal," then I will omit passionate feelings from my expression. I will try to get at the content of someone's expression and ignore the emotional wrapping. Debates rely on the principle of synthesis to do any good. So my return expression will be free of wrapping, and will address the ideas on the table as objectively as possible. Freedom from emotional context helps free people to effectively evaluate the ideas. It frees the best ideas to synthesize and turn into into practices, or action items, or a note-to-self to get more information.

Having adamant feelings, of course, is natural, to some more than others. There is some tendency to "cling to a point of view." An effective professional, however, will evaluate comments in a business and technical context, rather than in a context of vehement feelings. The result of this nonpersonal approach is, ironically, greater personal development, productivity, and learning skills. Who can argue with that?!

18 December 2002
Have you ever had a sudden brilliant idea that dramatically changed a project for the better? For example, when Einstein thought of the conversion of energy into mass. Or when Wittgenstein thought of language games. Or when Turing thought of building a machine.

Whether they change the world, your company, one project, or a process, sudden flashes of brilliance have one thing in common: they happen only after billions of neuro-transmissions have occurred in your work leading up to the flash. When you devote concentrated thought and work to a subject, you initiate the potential for a flash down the road. The more concentrated and consistent your work, the greater your chances to generate the Holy Grail of ideas: the flash of brilliance. In spheres where ideas happen all the time, it's what might be called an "excellent idea." If an idea is a lightbulb, an excellent idea is the northern lights, with an infinite variety of patterns and brightness.

Next time you witness someone on your team come up with an excellent idea, you can be sure he or she spent a lot of time concentrating and working on the subject. In these columns, I have often talked about the importance of improving software quality, contributing to projects, and being a positive force with your team. But there's also your own personal fulfillment to consider. Next time you get weary doing all the hard work that your job requires, remember you may be fast approaching your own flash of brilliance. It's one of the best ways to bring meaning to life (AND help your project).

16 April 2003
Are you a Karass or a Granfalloon? A recent Discover magazine ran an article linking a new social-network-mapping software with Kurt Vonnegut's distinction between Karasses, people who get things done, and Granfalloons, people who are all about structure instead of results (from "Cat's Cradle"). Granfalloons, the article notes, keep polished org charts, while Karasses cross departmental and hierarchical boundaries at will in order to efficiently complete tasks. Karasses have established good working relationships--not from "networking" to build them--but rather from simply getting things done. The new social-mapping software integrates with your email to track and then map people you work with: who, how many, how often. A Karass map will be thick with lines all over the place. A Granfalloon map will be sparse and confined to lines that reflect the org chart. I'm not promoting that social-mapping software--but it's not a bad idea to think about where you might fit on the scale from the super-effective Karass to the super-rigid Granfalloon.

2 July 2003
I was watching a show on PBS called Ask This Old House. (I know, "Get a life.") A couple had purchased a house that was everything they wanted except for an ugly cement step at the back door. Even the height of it was odd, so that they often misstepped going outside. The house, the whole package, was just right except this one feature that must have been ignored by the contractor's QA team. It was like someone's last-minute idea for an extra feature thrown in the day before release. Luckily the folks at Ask This Old House have a very responsive Help Desk. Their QA manager flew in for an onsite consultation and inspection. He saw the problem firsthand, tested it, and recorded specifications. He listened carefully to the couple's concerns to ensure an accurate documentation of the couple's requirements for the replacement feature.

They couldn't FTP a new build, so the whole development team joined the QA manager onsite, and began the reconfiguration. The main issue for the couple was aesthetics. But in adding the new aesthetic User Interface, they also solved the height problem. During design, the team asked the couple if they would also prefer something very low-maintenance for a little extra cost. They did. The agile team modified on the fly. It was a perfect story of initial user dissatisfaction, a responsive project team, careful attention to user requirements, a useful suggestion by the project team, and a happy ending for everyone. It's good to know the professionals are on the job at PBS. It's a great goal for every project team.

16 July 2003
As I'm writing this I'm about to get on a plane. I hope there are no serious software failures! We've talked before about how software drives everything from planes and spacecraft, to coffeemakers and jukeboxes. People say software could never take over the world because it does only what people program it to do (that's not necessarily reassuring). But while software drives everything, it is an important point that people drive software. People drive software in the sense that customers demand the services and products that software provides.

People also drive software in the sense that people create it and distribute it. Is this all too obvious? Then why is the phenomenon of software the single most flawed type of product in the history of products? Partly because it's the most complex "thing" we've created. That just means we have the greatest challenge in history--software testers, managers, QA people, etc.--to de-flaw the beast. The fact that you are receiving this e-letter means you are already part of the solution. So as I get ready to board my plane, I thank you.

20 August 03
Wear Their Shoes
How about the phrase, "I'm not married to that idea"? The connotation is that one might expect you to be married to the idea, and you had to clarify. In this ''Our Take,'' I'd like to say that one of the best group-characteristics a project team can have is openness to others' ideas. I say ''one of the best'' because it has to be balanced with a decisive leader who knows when to put the hammer down, and team members who know how to keep ideas from endlessly reproducing, but that's a different ''Our Take'' altogether.

Many people in our industry have used a particular process a certain way many years. This trickles down to specific instances in meetings where one person floats an idea, and another person "shuts down" the idea reflexively. (This can also be a personality issue, but that too is a different "Our Take.") In a more micro sense, one person may simply "need" to focus on one way of doing things, for the security of order amid chaotic development environments. But new projects often require some mental and psychological flexibility.

If you are a person who marries to ideas, processes, or "ways"-and you object to someone's new idea-it might be helpful to note your objection on paper, look at it again after the meeting, and try to put yourself in that person's shoes. Then, if necessary, go back and object with your reasons in hand. Or, maybe this habit will help you object less often, or object in a different way, offering alternatives. You can always communicate better, and contribute in a more productive way, if you have the skill to put yourself in someone else's shoes. I'm still practicing this skill, to make it a habit. It may seem like a difficult "point-of-view shift" to spend energy on, but it makes life a lot easier!

17 September 03
Thin staffing got you down? Here are some points to keep in mind when people and positions around you start disappearing. If you're going to pitch in and devote 50, 60, or 70 hours a week to keep things going for your company, be sure you communicate what you're doing from the start. Otherwise, management will see that "everything is running smoothly" and assume operations can continue adequately without hiring more staff. In some scenarios, your efforts will be rewarded. In others, there will be no reward and no "payback" to you. Be aware that this is a possible outcome. As your parents told you, it builds character. And it will certainly be a learning experience.

As in almost every experience, the main lesson learned is to communicate. You might also learn about "self-rewards." If you really feel gratified by the work itself, and your productivity is reward enough in itself, that will compensate for potential disappointment or disillusionment.

But it will not compensate for exhaustion. So keep some kind of internal barometer to detect pressure changes in your mental and physical health. When the reading on the dial warns of bad weather, seek shelter to rest and recover. If you push too hard, you will make yourself worthless to yourself AND to your company. You aren't doing your company any favors by ruining your own mental and physical health. They cannot be expected to know the full extent of the energy you have put in. So don't expect them to. No matter how dedicated you are, the bottom line is this: take care of yourself.