QA Hates You

This article might get developers’ hopes up: When Anger Is An Illness:

Scream at the boss? Snap at a colleague? Throw your cell phone into your @#$%%&* computer monitor? If so, you may find yourself headed to anger-management classes, which have become an all-purpose antidote for fit-throwing celebrities, chair-throwing coaches, vandals, road ragers, delinquent teens, disruptive airline passengers, and obstreperous employees.

Demand for such programs is coming from courts seeking alternatives to jail sentences and companies hoping to avoid lawsuits and office blowups. Aware that high-pressure jobs can make for hot tempers, some professions offer pre-emptive anger management. A few state bar associations now require “civility” training for lawyers renewing their licenses. And as of last year, hospitals must have programs for “disruptive” physicians as a condition of accreditation.

Programs run the gamut from $300-an-hour private therapists to one-day intensive seminars, weekly group sessions or online courses with no human interaction. Many advertise that they satisfy court requirements—even if all they offer is six CDs and a certificate of completion.

It’s not clear if the programs work, as few studies have analyzed their effectiveness. There are no licensing requirements for anger-management trainers—anyone can open a business. And since participants don’t usually sign up voluntarily, trainers say it’s possible to complete a program without actually changing one’s behavior.

Part of the problem is that professionals can’t agree whether a pattern of angry outbursts signals a mental illness or simply a behavior issue. As a result, people who need psychiatric help may instead get shunted into a short-term anger-management course. Employers and courts may not adequately evaluate people before sending them for anger interventions, nor provide sufficient follow-up.

No, you cannot call the mindset of QA an illness and hope it can be cured.

As a skeptic of the line of thought that thinks putting something on the Internet for convenience (and because the developers know how to do it easily and cheaply), I can heartily say that I would not want something implanted in my body that’s accessible to anyone via an IP address.

Unlike previous medical devices, the latest generation can be controlled automatically or remotely over the Internet. The benefits are obvious–they allow patients much greater mobility and the need for daily trips to a doctor’s office are obviated. In addition, these devices can dramatically lower health care costs, guaranteeing their wider user and acceptance moving forward.

…

While nobody worried about the 6 Million Dollar Man being hacked, the time has come to seriously consider the security protocols, or lack thereof, of today’s modern medical devices. As the story below indicates, the integration of technology into the human body has created opportunities for newer and more serious forms computer crime and hacking. In the past, a hacker might have been able to illegally enter a desktop computer system, read a targets personal data or even gain control of another person’s financial accounts. In comparison to the potential threat from Internet-based medical devices, the threats from “old-school” hacking seem mild by comparison.

This goes pretty much for any critical infrastructure. You, there, testing embedded devices, manufacturing controls, transformers, and so on. Seriously, isn’t it worth a little effort (okay, a lot of extra effort) to put that on a secure, dedicated network to make sure that some punk in Montreal doesn’t kill someone with your product?

Here’s a little something to get you through the afternoon: Van Halen’s “Runnin’ with the Devil”.

Although, personally speaking, I think I’m more short track speed skating with the devil and getting disqualified for tripping him in the final turn.

The following e-mail provocatively asked me in the subject line What’s in your forcast?

Click for full size

I have to say: it was an effective subject line since it caused me to open the mail and to load the images to make sure they spelled it right in the e-mail, which they did.

You can test the e-mails’ HTML all you want, but you really need someone with an eye for quality to look at the friendlies, too. (The friendlies, for those of you not in the e-mail campaign world, are test e-mails sent through the bulk e-mail sender to a small list of internal people for final approval.)

Not mine, but Thinkgeek has a Venn diagram that follows closely on this post from Monday:

(Link seen on The Zeray Gazette.)

The author of this piece doesn’t get it:

By focusing solely on social media’s features, Owyang continues to perpetuate the pervasive illusion that, if we choose the right tools, our customers will converse with us, talk about us, and share our content.

You know. The “hyperbole, artifical branding, and pro-corporate content” most of our websites still feature.

The relevancy of our corporate websites is not dependent whatsoever on which social media widgets have been deployed throughout the site. Its relevancy is driven by our site content, no matter who is creating it. And that content requires as much, if not more, strategic planning and consistent oversight as do our social media initiatives.

The goal of any site development is not to provide quality, usable, and relevant content for users on behalf of the client. The goal of any contract work is to separate the client from its budget, as much as possible and as easily as possible. And grafting in a Twitter feed dependent upon a site that fails daily? Easy and expensive.

(Link seen on the Twitterverse.)

It’s afternoon. Surely, you still have a fresh pot of coffee in the company’s kitchen.

Just remember: Coffee improves your throttling grip.

Hey, is that another Facebook bug?

Last night, in an embarrassing glitch for Facebook that raises questions about privacy on the site, some users of the social-networking service began getting hundreds of personal messages that weren’t intended for them.

A WSJ.com editor, Zach Seward, tipped Digits off to the apparent glitch after his Facebook inbox was flooded with messages ranging from the mundane to the truly private.

“I am sorry for letting my jealousy and worry get the best of me,” reads one of the emails.

Oh, boy, Facebook is really in the race to obsolescence here. Misdirected personal messages? That’s going to undermine user trust and confidence.

And once one of the other up-and-coming social networking solutions hits a tipping point, Facebook is going to lose users in droves. You can’t keep burning people with poor quality and expect to be an ongoing concern no matter how many Farmville players you have.

Don’t you hate it when your ad delivery service throws your ads into places too small to accommodate them?

Click for full size

If you don’t, you’re all right with the company serving ads up for the StLToday.com, where this happens all the time.

A quick reminder courtesy of Conan the Barbarian about job satisfaction in QA:

This article in the Wall Street Journal is spot on: Where Process-Improvement Projects Go Wrong:

What do weight-loss plans and process-improvement programs such as Six Sigma and “lean manufacturing” have in common?

They typically start off well, generating excitement and great progress, but all too often fail to have a lasting impact as participants gradually lose motivation and fall back into old habits.

I’ve sat through enough process meetings to know it’s true. We’d sit in a conference room, chart out a nice flowchart eventually of an ideal situation, and then when the meeting broke up and actual projects started, everyone would do what they always did in the first place. Which is ignore the process.

When you’re trying to improve the process in an organization, you have to take into account the specific organization and the major players within the organization. An outside consultant beaming down solutions from planet Six Sigma is not going to know enough about the industry and about the people within the company. They will offer procrustean solutions that the teams will easily ignore or forget.

The best process improvement can come from within if you have a long enough relationship with other people in the organization to know their strengths and their weaknesses. To improve the process, you need to account for the people who will try to make it work and to accommodate them. You’ll want to capture the best of the things they do and you’ll want to make sure the process handles all of their weaknesses and shortcuts, too, so when the fit hits the shan, the process handles that, too.

A process under glass, framed on the wall, isn’t the goal. Doing things the right way is.

A proposal would hold vendors liable for bugs:

SANS’ newly released Top 25 list of common programming flaws came with a little legal muscle, too, with representatives from SANs, Mitre, the U.S. Department of Homeland Security, the National Security Agency, and other organizations pushing for custom software developers to be held liable for insecure code they write.

Experts from more than 30 U.S. and international organizations, including OWASP, Microsoft, Apple, EMC, Oracle, McAfee, and Symantec, contributed to the CWE/SANS Top 25 list. And procurement experts from some of the organizations are recommending standard contract language for procurements that would ensure buyers aren’t held liable for software that contains security flaws. “Wherever a commercial entity or government agency asks someone to write software for them, there is now a way they can begin to make the suppliers of that software accountable for [security] problems,” says Alan Paller, director of research for the SANS Institute.

Paller says the contract language would be based in part on a draft in the works by the State of New York (PDF) that refers to the SANS Top 25 and would make the state’s custom-software vendors contractually bound to provide apps that are free of those bugs. Paller says although there is “no formal agreement on the language” among the group at this point, it’s focused on the section of New York’s proposed contract language that reads: “the Vendor shall, at a minimum, conduct a threat assessment and analysis of vulnerability information, including the current list of SANS 25 Most Dangerous Programming Errors; provide the Purchaser with a written report as soon as possible after a vulnerability, threat, or risk has been identified.”

Well, within the context of the job, QA management is always on the hook. Any bugs that get through reflect poorly on QA (as they do on the whole organization, but I always internalize it because I’m that way).

However, when I read something like this, I get a little skittish and recollect sitting in a sexual harassment seminar given to all department heads and learning that I, personally, was on the hook as a potential plaintiff if one of my minions made a hostile-in-the-sexual-way environment (hostile-in-the-QA-way environments are standard). I am sure I paled a bit learning someone could get my house. I mean, I had a Canadian on staff, and you know what that means (the man was born in Canada).

I’m probably a little worried for something that probably won’t come to pass. A little liability and being required to fix problems is good. That fear can help make some better software. How the torts shake out, though, that remains to be seen.

Steven Den Beste finds a common error with programs that write their icons to the Windows system tray:

Every time I start playing a new file, it spawns another icon in the tray. There’s only one copy of it running, and if I run my mouse pointer over them then all the phantom icons will disappear.

Let me put on my developer hat here: That’s not a bug, it’s a feature! Yeah, it tells you how many files you’ve played since you’ve moused over the system tray! I’m marking the defect RESOLVED: NOT A BUG!

As one of his commenters mentions and my experience indicates, this happens sometimes when low rent applications ab-end. And I include Yahoo! Messenger in the low end category.

Which brings me to a good testing point: So, what happens when you kill your desktop application from the task manager? Does it leave connections on the database open? Does it leave stray icons? Try it and find out. You might like it better if you know the UNIX term for it: kill.

Finally, someone has a QA job whose title I approve of:

However, they left the e out of Maneater.

(Sent in by reader Dave H., who presumably sent it in because the careless job poster misspelled the title, not because omitting the hyphen in the year spans makes it look like they want someone with almost six decades of QA career behind them.)

Sorry, guys, despite our best efforts, they’re going to launch the product with a handful (King Kong’s hand, natch) of critical issues that only QA (and those who deviate from the happy path) would find.

Here’s a button to press for final launch.

And may God or your preferred deity have mercy upon your souls.

Speaking about the Toyota software problems, Jerry Pournelle diagnoses the root of many quality problems in software:

When the computer revolution was beginning, there was a concerted effort to develop theories of computer languages. Two major champions of language reform were Niklaus Wirth** of ETH (Zurich, the Swiss Federal Institute of Technology) and the late Edsger Dijkstra (eventually held a chair at the University of Texas in Austin). Dijkstra spent much of his life developing theories on how to “prove” programs. They and some others were largely responsible for the movement that induced the Department of Defense to develop Ada, a strongly typed and highly structured language with some similarities to Wirth’s Modula languages. (The last time I discussed it with him Wirth did not care for Ada, in part because it became too complex with too many “features” and in part because he did not approve of exception handling — and that is one argument I’m not going to get into.)

More on all this another time, but my point is that in those times there seemed to be a lot more concern with languages, and with building languages that required good programming practices. In the various Wirth languages starting with Pascal the goal was to have the compiler catch incipient bugs: it took longer to develop a program that would compile, but once it did, it was likely to do what you expected it to do. Unfortunately the computer hardware of the time wasn’t up to huge programs in strongly typed and highly structured languages; it took a long time to compile a new addition to a program. The programming world turned to C and its derivatives, and in the early days a C compiler would compile almost anything, including very tricky uses of pointers and type changes.

I don’t know what language Toyota has used to develop its drive by wire programs, but I would bet reasonable sums that it wasn’t Ada or one of the Wirth languages.

To make it easier for people to become developers, they made it easier to write software. To deleterious effect.

By the way, be sure to use the word deleterious in a sentence this week. Vocabulary is a weapon.

It’s Sunday morning. Let’s start it with some “Hair of the Dog”:

That will put you straight for a week of handling the unthinkable.

Jack in the Box’s latest e-mail offers the normal View as Web Page version:

Click for full size

Note that The in the salutation is my first name, since I am The Director.

On the Web it checks out:

Click for full size

The Web version changes omits it, since it’s not passing the first name to the Web version, although it could.

The Mobile version?

Click for full size

Suddenly, it reads like a comment thread on Fark or something. Hey, FIRST!

You know, it’d laudable to make a separate version for different platforms. As long as you test it.

It’s the start of another week, but how about we make it an epic week?

Whenever I hear this song, I feel like tearing off my shirt, picking up the family claymore, painting my face, and charging the English lines or sacking the software architect’s office again.

Unfortunately, I don’t have a family claymore; all we have is a family halberd. And the software architect doesn’t have anything worth taking left in his desk.

But keep in mind, QA, you’re the only hero who stands between the predations of the project managers and developers and the poor innocent users. They need you. They’re holding out for you to do your job.

“It’s better to be wanted for murder than not to be wanted at all.” –Marty Winch

Surely you can meditate on that for a while and see how it applies to QA.