QA Hates You

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.

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.

Here’s an e-mail that might give hope to Web designers and developers in the world, probably written by a Web designer to boot:

Click for full size

I suspect a Web designer wrote that subject line because he or she left in an extraneous “this” and misspelled, “Yay!”

I can understand the glee.  Hopefully with Gmail dropping IE6 support, they can, too!  If they even think about anything but Safari or Chrome.

However, as a reminder, IE 6 has a 20% share of the browser market in this January of the year of Our Lord 2010 according to Net Market Share.  More than Firefox.  5 times that of Chrome.

If your site or application doesn’t handle it, you’re going to strand a lot of users.

Two weeks ago, an event occurred that altered the fundamental way we describe our locus within the space-time continuum.  That event, the New Year, means that any Web site to which you added content since then needs to have an updated copyright date:

Click for full size

 If you’re working in PHP, such as a blog, here’s a PHP script to make it dynamic.

Another thing to check is for any recurring contests on your sites, such as stories that you ask users to share, to make certain that your terms, conditions, and rules extend to the new calendar year.

You remember that Google problem that flagged the whole Internet as malicious?

Shall we count the myriad failures inherent in it?

1. They trusted administrators to be infallible. The process or tool they use to perform the updates didn’t question whether the user really meant to flag the whole Internet. It did not validate on obvious problems. If it’s like anyplace I’ve ever worked, the administrative tool is a pasted together bit of interface and workarounds, rife with problems and untested or undertested because only administrators would use it.
2. They didn’t test it immediately. The “on-call site reliability team” took care of it. That sounds like me that either an automated process dialed some pagers or a help desk person got a phone call. They probably ought to have someone check that right away, hey? Nah, they’re Google. Everything they touch turns to good.
3. A variety of sources show that Google blames its data provider initially. That is a sign of hubris of the commonest order. Maybe they shouldn’t have been so hasty to lay blame before understanding and fixing the problem. On the other hand, Google did fix it quickly. Some organizations spend more time on the casting aspersions part of the program, sometimes foregoing fixing the problem entirely.

If Google can make these mistakes, so can your company. The key is not to use that as an excuse when your organization blows it (“Hey, it’s okay, even Google does it!”). You have to learn from these mistakes and make sure your company doesn’t trust its administrators and tests things the minute changes are made.

Story in the New York Times: Some Protect the Ego by Working on Their Excuses Early:

Every ugly exam score, blown deadline and failed project provides the opportunity to try out new excuses. It was a blowup at home. A sick cat. An emergency at work.

Not to mention the roadways: if only they hadn’t been so icy.

This kind of talk is so familiar that most people quickly dismiss it, even when it comes out of their own mouth.

This is one reason that genuine excuse artisans — and there are millions of them — don’t wait until after choking to practice their craft. They hobble themselves, in earnest, before pursuing a goal or delivering a performance. Their excuses come preattached: I never went to class. I was hung over at the interview. I had no idea what the college application required.

You know, dev teams and companies I’ve worked with often have this sort of self-limitation built into them.  You get hours and hours ignoring good quality practices like tight specs, proper communication, reasonable timelines, and tolerable levels of testing, and then they make up that time with lessons learned meetings at the back end compiling useless rationalizations for one-time events and confluences of circumstances that caused this failure, this time.

Then they’ll do the same thing the next project.  Or the next company will only do as much as the last company, because the other companies seem to tread water with known issues in their products.

On the plus side, they all get paid for the self-defeating, and will get paid in their next, higher, positions of self-defeat.

(Link seen on Instapundit.)

When your Web site cannot find a page, it often displays a special custom 404 message configured on your server.

What happens if the site cannot find it?

Everything goes meta:

Click for full size

Dude, that’s like a 404 message for a 404 message.

In this case, it looks like it’s gotten left behind since the Web site URL without the non-existent page name redirects, and the redirected Web site with the non-existent page name is handled.  However, it looks as though with all of the redirection going on, some misdirection has occurred.

You do keep track, QA professional, of all of the URLs and all of the landing directories and all of the page names to make sure that they’re handled when the site changes in such a fashion to render them incorrect, right?  Right?

A company uses an open source control and finds that its default options inflame political sensitivities of users:

 My wife is in charge of online donations for a large international relief agency, and she recently received a strongly worded e-mail from the leader of a pro-Israeli group accusing her organization of anti-Semitism and anti-Zionism, and threatening to spread the word among potential Jewish contributors–not a good thing.

I’ll spare you the rant, but the upshot was that we learned that the “country” drop-down menu on one of her organization’s donations pages omits Israel as a country and includes “Palestine.” Among other things, this means that Israelis can’t donate to the organization from these pages.

This isn’t the case on the agency’s own site, but it was the case on the pages for Causes, which puts widgets on social networks like Facebook and MySpace that let members donate to their favorite charities (including my wife’s).

When I got a hold of Sean Parker and Joe Green (the co-founders of Project Agape, which created Causes), they tried to fob me off with a “Thanks, we’ll look into this” response. Not what I was looking for.

I pointed out that this isn’t just any omission and addition. When you omit Israel and add Palestine (which is not even recognized as a country by the United Nations) to a country drop-down menu, you seem to be making a very loaded political statement.

This reiterates two points I’ve made previously:

• Never trust software (or libraries, or sample code, or snippets, or whatever) that you get from somewhere else.  Always vet it as you would your own code.
• Be aware of political situations, particularly country names that can change through government change, declarations of independence, or whatnot, and know what message your software sends when you omit some or include some.

(Link seen on Instapundit.)

Back in 2005, Electronic Arts sent out an update for its popular video game Madden 2006. The update included updated roster positions as well as a special “feature”: a lineman who was 7 inches tall.

(more…)