Elisabeth Hendrickson

These days, the word "Quality" is thrown around so much it's starting to lose its meaning. In this column, Elisabeth Hendrickson explains why she thinks organizations need to focus more on building good software and less on buzzwords.

We create lists to help us prioritize tasks and stay on schedule. Sometimes those lists help us accomplish those tasks faster. Sometimes those lists simply chain us to an archaic way of doing things. Having a "To Do" list is a good thing if you don't let it prevent you from thinking outside the box. In this column, Elisabeth explains why the agenda items that don't make the list can often be some of the most important.

Miscommunication is at the heart of most software defects. Being knowledgeable about a company as a whole, and not just about the specs of a particular project, is just one more way to safeguard against failures. Read on as Elisabeth Hendrickson explains the importance of technical people staying informed about business strategies.

Last week Johanna Rothman proposed that tracking the priority and severity on bugs can lead to confusion about what's really important. She suggested adopting a simplified classification scheme. I think that severity and priority are two different kinds of information and that it's important to track both. Where there's confusion, the problem is usually a lack of agreement about definitions and confusion about who is calling the shots on the project. A simplified classification scheme may limit the confusion, but it won't solve the underlying problem. It may actually increase tensions as project team members feel others aren't listening to their concerns.

Admit it: When you're faced with a lengthy checklist for testing, you're tempted to skip steps. Some of the items aren't really necessary, are they? They might be so obvious that there's no need to include them in the list. In this column, Elisabeth Hendrickson offers some advice on constructing useful checklists that are brief but complete.

Before you start criticizing that programmer for all the bugs you're finding in your latest project, read this column by Elisabeth Hendrickson. She advises us all to try to understand the other person's situation before we resort to blaming.

When you're testing software, you've got your priorities, right? Find as many of the worst bugs you can in the shortest possible time, of course. But what if the project manager has different priorities, such as reliability of a particular feature, or overall stability of the software under load? In this column, Elisabeth Hendrickson explains why it's best to ask a few questions before embarking on your bad-bug-hunting trek, or you might find yourself on a wild goose chase.

When does a groove become a rut? Elisabeth Hendrickson has experienced both grooves and ruts while testing a seemingly endless software project or series of projects. Here she explores the subtle slippery slope from groove to rut. She also discusses common causes. Once you fall in, Elisabeth has some pointers to help you climb out.

When things go awry, sometimes the first problem you see is not The Problem but just a product of its symptoms. But if problems can hide behind other problems, how can you learn to spot the true culprit at the source of your dilemma? Elisabeth Hendrickson shares some lessons she's learned about "The Problem."

Bugs that make a system crash are the most dramatic, but they may not be the most interesting. Subtle bugs hide where you don't expect them, causing systems to mislead users with incorrect results. Using scientific inquiry, you can expose these deceptive ne'er-do-wells lurking inconspicuously under the covers. Elisabeth Hendrickson offers good examples and pointers to using this investigative method.

In this paper, software testing authority Elisabeth Hendrickson shares stories about writing simple tools to make the process of testing easier.

Quality Assurance Manager. Senior Developer. Test Manager. Think you know what those titles mean? Are they mutually exclusive? If not, where do they overlap? Which one "owns" Quality? An important step in perfecting the software development process is negotiating and understanding the responsibilities of every team member. In this column, Elisabeth Hendrickson talks about unwrapping the responsibilities beneath the job titles.

If you are lucky, you've never been on the receiving end of a Vice President discovering that a large investment in testing hasn't paid off in improved quality. This article gives an example of how a beefed up test team caused a decline in developer-test practices--with disastrous results. The article describes in detail how the whole team can work better–technically and psychologically–and ultimately ship software with fewer defects.

Ms. Dekkers and Ms. Hendrickson talk about Elisabeth's five-step process for choosing a tool for your organization: Defining Initial Requirements; Investigating Options; Refining Requirements; Narrowing the List Down by Priorities; and Evaluating the Final List, Bringing in the Tool Vendors.

The mood in the meeting was grim. All eyes were trained on Doris, the head of customer support. Doris surveyed the room as she spoke..."We have a problem in the field with the new release. Sixty-three users reported unrecoverable errors this week—a record high. An additional 152 people reported crashes, but the software recovered after reboot. This morning, I talked to an irate user who said he'd uninstalled our software after it crashed on him five times in a row. He wanted us to give him a full refund plus expenses. In short, the users are really angry. What do I tell them? When will we have a fix?"

This column asks the all-important question, "What isn't there that should be?" The same idea for spotting black holes also applies to spotting "holes in designs and requirements." For example, there are often connections between the quantity of bugs filed against an area and whether the area is thoroughly tested. There can also be holes in what KIND of bugs have been reported. Hendrickson lays out the territory for the search and goes on to suggest how to "look for where there's a lot of nothing."