Joshua Bixby has an article about how third party scripts on your Web site can seriously hinder the Web site’s performance (Has your site’s third-party content gone rogue? Here’s how to regain control.)

In addition to the performance issues, you need to consider the following dangers and drawbacks of introducing third party code into your application or Web site:

• You have no control over what they do.
  Sure, they tell you they do something, but that might not be all that they do. For example, a number of years back, I recall a Web site visit tracker that provided a “free” version and a paid version. A lot of people went with the “free” version, which not only provided rudimentary statistics on your Web site, but also served pop-under ads. By that time, most browsers allowed pop-up blocking, this was not always the case, and the host was making money on its users’ content. The provider of this free utility did mention it was going to do it in the terms of use, somewhere around the term that said you could not use the Web counter on Web sites discussing John Norman’s Gor books (no kidding). So not many people read it.
   
• They can be an attack vector for malware.
  This is a corollary of the above point, but it’s worth noting in its own: Not even the third party vendors, especially ad delivery services, have control over what the code does. In many cases, that’s left to the person who buys the ad, and sometimes that’s a bad, bad man who wants to do bad, bad things to user computers and inserts attack code into ads that the third party code serves up. As a matter of fact, the last attack I know of on my client machine came not from a Web site discussing John Norman’s Gor books, but from the live stream page of KMOX radio, a CBS affiliate in St. Louis, where one of its ads tried a JavaScript exploit on me.
   
• You have no control over quality of the third party code.
  No matter how much or how little you test your Web site or application, you can rest assured the third parties test their stuff less (even if that is, in fact, a negative number). Many of the JavaScript errors I see when careering around the corners of the Internet stem from missing objects associated with third party code. This might not adversely impact your Web site, but we don’t like to deal with might not as a plan of action in QA, do we?

I realize this is a repeat of what I have said early and often throughout the almost five (!) years of the blog, but the above article gave me an excuse to repeat it again.

(Link via Scott Barber tweet.)

XKCD uncovers a bug that QA should always find:

(Thanks to the most beautiful developer I know.)

You know, reading horror books doesn’t keep me from sleeping like a baby (a colicky baby) at night. What do I read to give me chills and to keep me awake in the darkness, staring at the ceiling and contemplating dark things that might snatch my life away? Books like this book.

The subtitle of the book is And Over 100 Other Stories of Embarrassing and Funny Stories of Technology Gone Mad. It collects a number of humorous incidents where software or software-related processes have gone awry and made the papers, causing great embarrassment for the companies responsible. I wouldn’t call them epic fails, because in the 21st century, epic fails are fleeting. These are legendary failures still half-remembered and fully documented for posterity.

Reading through the book, one identifies some areas of risk to pay particular attention to if you’re trying to prevent your company’s failures from becoming the stuff of legend and Snopes articles. These include:

• Preventing the leak of test data.
  In many of the stories, great fun happens when test data or placeholder material goes into production. Such as the titular “Dear customer, You are a loser.” email or the “Rich Bastard” test name in a mail merge. When you’re creating test data, don’t be clever or wry, since that might leak out. Play it straight. And for Pete’s sake, figure out how to purge it before it gets out there.
   
• Review your CMS procedures.
  A lot of the news-stories-that-aren’t-real tales in this book come from instances where content authors somehow put their incomplete works into draft and they end up live on the Web site. This might be because the content management system has issues, or it might be because the content author has the ability to publish his or her own work and inadvertantly does so before the proper time. Sometimes, this happens without a CMS where code roll-ups get promoted with draft content. Regardless, you need to scrutinize those procedures to minimize the chances of this happening. As a bonus, one of the stories is about a journalist whose story gets promoted to the live site with disrespectful placeholders within it. Have I mentioned that’s a bad thing?
   
• Not understanding practices of the users and building in problems through ignorance.
  Then there’s the story about the guy who got a license plate that said NO PLATE and ended up getting the tickets for every car in the state without a license plate. Or at least those where the police officers had written No plate for a license plate number. If you don’t know what your users’ habits are, you can walk right into a problem where their habits conflict with your software’s interface and abilities.
   
• The impossible calculated numbers.
  The book is rife with the stories of impossible calculation results, such as the trillions of dollars in library fines, the bajillions of dollars in water meter charges, and so on. Does your software have a sanity check to flag outlying calculation results? If not, why not?

This book has a lot for the software quality professional to learn. It exposes patterns of failure we need to recognize and to account for in our testing and rolls up a whole lot of lessons learned meetings into a very browseable 300 or so pages.

Definitely recommended.

Books mentioned in this review:

Apparently, they’re on the Blizzard servers:

The Diablo 3 servers are at full capacity, preventing many from playing the game.

Players across the globe are reporting “Error 37″ when trying to log in following Diablo 3′s midnight launch in the UK at 11pm last night and, just hours ago, on the West Coast.

“Due to high concurrency the login servers are currently at full capacity,” Blizzard wrote on the Battle.net forum. “This may cause delays in the login process, account pages and web services.

The best part, or worst part, depending upon whether you’re a mere observer or a customer who plunked down $60 for the game: Blizzard actually warned they weren’t going to have enough server capacity to handle their user needs in a blog post last week. And didn’t accommodate the usage spike until it happened.

(Seen via Fred Beringer tweet. I’m not a fan of the video game series. It reminds me too much of my day-to-day work.)

Here’s a book excerpt in the Wall Street Journal on improving your judgment of risk:

Most of us have to estimate probabilities every day. Whether as a trader betting on the price of a stock, a lawyer gauging a witness’s reliability or a doctor pondering the accuracy of a diagnosis, we spend much of our time—consciously or not—guessing about the future based on incomplete information. Unfortunately, decades of research indicate that humans are not very good at this. Most of us, for example, tend to vastly overestimate our chances of winning the lottery, while similarly underestimating the chances that we will get divorced.

Psychologists have tended to assume that such biases are universal and virtually impossible to avoid. But certain groups of people—such as meteorologists and professional gamblers—have managed to overcome these biases and are thus able to estimate probabilities much more accurately than the rest of us. Are they doing something the rest of us can learn? Can we improve our risk intelligence?

Sarah Lichtenstein, an expert in the field of decision science, points to several characteristics of groups that exhibit high intelligence with respect to risk. First, they tend to be comfortable assigning numerical probabilities to possible outcomes. Starting in 1965, for instance, U.S. National Weather Service forecasters have been required to say not just whether or not it will rain the next day, but how likely they think it is in percentage terms. Sure enough, when researchers measured the risk intelligence of American forecasters a decade later, they found that it ranked among the highest ever recorded, according to a study in the Journal of the Royal Statistical Society.

The excerpt says that you can improve your risk analysis abilities by getting immediate feedback. However, if you’re trying to answer the risk of deploying undertested software with the potential for hidden defects or if you’re estimating the chances of a discovered error occurring in the wild, that feedback might not be immediately available if the circumstances don’t occur until six months after the software is in use.

At any rate, it’s an article worth reviewing and maybe it’s worth getting the whole book Risk Intelligence: How to Live with Uncertainty.

George Takei shared this photograph on Facebook:

Class, who can tell me what’s wrong with this picture?

A Non Sequitor cartoon from April 9, 2012:

Strangely enough, QA does just that.

And, yeah, I am a month behind on the local newspaper. I’m even further behind on the Wall Street Journal, which means when I try to catch up on them, it’s almost like living as Time in Piers Anthony’s Incarnations of Immortality series.

“Indestructible” by Disturbed.

It sounds better really, really loud.

Appearing in the new ST & QA Magazine, it’s “When Users Collide“. (Registration required.)

Computerworld reports IE ‘silent’ upgrade helps put newest browser on Windows: Stats show some Windows 7 and Vista users upgraded to IE9, but the new practice affected few XP users:

Microsoft’s decision late last year to switch on “silent” upgrades for Internet Explorer (IE) has moved some Windows users to newer versions, but has had little, if any, impact on the oldest editions, IE6 and IE7, according to usage statistics.

Being in QA means you get to say “I Told You So” an awful lot. But it never gets old.

Hidden in this Forbes article about Amazon.com is a disturbing metric, particularly disturbing if you consider it in any detail. The metric:

Even the tiniest delay in loading a Web page isn’t trivial. Amazon has metrics showing that a 0.1 second delay in page rendering can translate into a 1% drop in customer activity.

Why is this particularly disturbing? Customers go to Amazon to buy. What is that slow page low time doing to your site’s visitors whose attachment and commitment to your site might be much lower?

By the way, you are doing your performance testing from outside the corporate network to get a feel for the load times on the actual Internet, aren’t you? I’d feel a little silly asking it, except I am a seasoned QA consultant. You might not be.

I realize I’m a little late to the annual celebration of a maritime disaster, but back when it was timely last week, Popular Mechanics did a piece called Why We’re Still Learning the Lessons of Titanic about how even the most up-to-date engineering can fail catastrophically. A taste:

In one respect, little has changed. As the recent loss of the Italian cruise ship Costa Concordia demonstrates, bad decision making can overcome even robust engineering. Virtually all man-made disasters—including the Three Mile Island nuclear accident, the space shuttle Challenger explosion, and the BP oil spill—can be traced to the same human failings that doomed Titanic. After 100 years, we must still remember—and, too often, relearn—the grim lessons of that night.

No disaster is a single event. Complex systems rarely fail without warning. Instead, accidents are the product of decisions made over hours, days, and sometimes years. Those choices are shaped both by the culture of the organization—whether it’s NASA or the White Star Line, which owned Titanic—and by outside pressures.

When you’re mapping out, building, and testing applications, remember the human failure element. Remember the peril of the badmins.

And when you’re doing your risk analysis about whether critical-but-unlikely bugs need to be fixed or what extreme conditions you should test for, you and everyone else needs to remember that unlikely is not impossible, but catastrophic is always catastrophic.

Take a look at this:

As I mentioned yesterday, this is a 24-volt double pole contactor for an air conditioning unit.

But it’s also akin to a computer program. It’s a simple mechanical switch, but it functions like any method or function in an application. It takes input from the main circuit board, a 24 volt current that triggers the switch. When the switch is triggered, the condenser and compressor come on and make the magic happen. When the current stops, the switch opens and the external unit shuts down.

So. What can happen to impede this process? How would you test it?

Of course, one would send a 23 volt current along to see if it triggered. And then 25. And then, if one was really sadistic, one would pipe the electric version of Hamlet at it (which would explain why the lights in the building just dimmed).

What happens if the switch sticks in the partially on position? What happens if current travels between the contacts incorrectly (a shower of sparks and a bad switch, which explains why this one is on my desk and not in my air conditioning unit). In many cases, the problems you would find would be the result of installation issues, that is, deployment of this object. That’s when the wires can get hooked to the wrong screws and whatnot. What happens then? Hopefully, just a failure of the device and not a cascading catastrophe.

When you’re looking at an application, try visualizing it as a physical object with access points and egresses. What happens if you cross the streams? Is it only partial protonic reversal? If so, log a defect.

Take a look at this:

This is a 24 volt double-pole contactor for an air conditioning unit. Part number CONT1P030024V.

What does that mean?

A former client of a former client manufactured this sort of thing, so it wasn’t uncommon to see part numbers rolling up the screens during testing and documentation. Each of those lines of data referred to actual objects. Not programming language objects, but physical devices that the software’s users and customers depended on. Those customers probably bought them and installed them in residential and industrial settings to keep people cool during the summer months.

When you’re stuck in a cubicle, office, or testing lab ten hours a day (or thirty-six if you’re g33klady), those little lines on the computer screen are just that.

But out in the real world, they’re real things. Remember that.

A Computerworld article asks, “Time to de-Flash your site?” A mobile user laments:

“When I am accessing a website that has Flash, I usually get a blank part of the screen, or a red box where the Flash element is,” Cunha says. “Or I may just get a static image.” If the organization behind that website hasn’t developed a scaled-down mobile-friendly alternative, Cunha says he usually avoids the site totally.

Back when I was at the interactive agency, we always tested to see the site without Flash and provided a different static image if the browser didn’t have Flash installed.

I’m sure that’s all done away with now, and most Web shops thought (if they thought at all) that Flash penetration was high enough to make that unnecessary.

And then, a couple years later, popular tablets and smartphones did not support Flash, and the lamentations begin.

Here’s a bit of advice, gratis: If you’re building or testing Web sites, always check to see what happens if dependent technologies aren’t there, and handle their absence gracefully. Sure, the technologies might have a lot of market penetration now, but what’s going to happen in a couple years?

Unless you’re a fan of clients clamoring for free fixes to their suddenly broken sites, just do it. You’ll make me quieter about it, anyway.

A floating survey doesn’t like the elderly:

That’s a pretty strange business requirement. If you get something that looks arbitrary, you do know to challenge it, right?

Make sure there’s some reason that your organization doesn’t want to collect information on someone using an iPad from his or her assisted living facility.

IGN has a couple pages about what it’s like to be a QA tester in the video game industry. The lede:

What gamer hasn’t dreamed about playing games for a living? While this may seem like a great career, and a cool way to get a first job in the games business, the truth is less appealing.

Although the testers cited in the article grouse a lot about the things that make any employer a bad employer from a testing employee’s (or contractor’s) perspective, one element is even worse: The pay is crap.

Because, face it, it’s the kind of job that naive cannon fodder will throw itself at for the very reason listed in the lede: Testing games all day sounds like a lot of fun until you realize that it’s the same tedium as running the same test cases against a piece of database connector software except with better graphics. As long as that fantasy lives, kids will come along and accept that ten dollar an hour wage to do it.

It’s kind of like writing Internet humor. You think it sounds like fun or it might be a springboard to something else, but mostly it’s what it is and leads to more of the same if you’re lucky.

So although I’m not against working on games, it’s for my rate of pay, not a sweatshop’s.

One of the local daily deals sites is offering a discount at the local gun range. How much? Bring your own algebra.

Actually, it’s not a good algebra problem at all, since it gives no information as to how to solve for x.

So it’s a lot like pretty much what QA does every day.

While I was renewing my subscription to Information Week, the survey presented me this question:

The question is:

Which of the following software products, services and/or technologies do you currently or plan to approve, specify, recommend, purchase, or influence the purchase of?

And one of the options is:

Spyware / Malware

By checking this, you do realize that logically you’re saying that your organization uses spyware or malware, right?

So I got a junk text the other day, offering me some Nigerian prince’s Starbucks free sample or something. However, at the end of the text, I spied a bit of the wizard behind the curtain:

If you’ve got a program that spits out text messages, much like a program that spits out email communications, you do check that text message or email, don’t you? Or printed pages from your application?

Because your user might see all forms of output, you need to make sure they’re not embarrassing.