And then I get to this particular bit of logical Möbius strip:

To clarify: The control is labeled What did you accomplish on Dice.com today? (Select all that apply)

However, not one of the checkboxes is labeled None of these.

So to continue to the next step, if you want to continue, you must lie. And remember, the entrance to this quiz is on page load of Dice.com. That is, before you have accomplished anything at all.

Me, I didn’t lie: I eventually checked Other and Specified I got a blog post out of it.

What’s the lesson here, lads and lasses? Read the labels of the controls you’re checking, and make sure they make sense and make sure any enforcement rules upon them make sense vis-à-vis that label text.

What, not a missing resource? Not a null passed where a value is expected? This is particularly amateur work.

And it’s from a third party, again, fouling up the radio station’s Web site and doing who knows what. Brothers and sisters, I’ve had slightly more mature computers’ virtual memory swallowed up by these third party scripts running if I’ve left the Web site open overnight. Like it or not, this third party crap is a part of your Web site and its failures will reflect upon your company, not your ad server.

That one is classic. And ongoing on oh so many sites that try to use their insecure templates on their secured Web pages.

Mobile broadband caps might not be putting the hurt on most mobile subscribers yet, but data usage is going to keep creeping up. And that’s without people doing any more actual browsing.

The HTTP Archive charted the growth of the average web page and found that average web pages have grown from 726 KB a year ago to 965 KB now. The 33 percent jump is due in large part to more images and third-party scripts like ads and analytics. Javascript content, spurred on by the rise of HTML5, has grown over the last year by 44.7 percent, according to analysis by Royal Pingdom.

I remember when 1Mb hard drives cost $1000, you damn kids. Before you were born.

But it does clarify an interesting point: The time your Web page takes to load isn’t the only metric you should check when you’re performance testing your mobile applications or even your regular Web site if you expect mobile users will access it.

Although your leadership might say, That’s okay, we’re not designing for mobile users, if your bloated Web site is chewing up their allocated bandwidth, they’re going to find someone more streamlined.

(Link via Tweet retweeted by Fred Beringer.)

In about an hour, I’ll be participating in the crowd-sourced load testing of http://Packers.com http://bit.ly/ucICSO Good luck, everyone.

A couple of near-timeouts later and some really, really long load times, and I’m the proud owner of one share of Green Bay Packers stock. It’s fewer shares than I own of the startup where I used to work, but they’re worth about the same.

At any rate, two hours after I tweeted, the first news reports about the slow Web response time appeared:

On Twitter, fans were reporting that the it was difficult to access the website – www.packersowner.com – or the toll-free line: 855-8-GOPACK.

Murphy and other team officials said they anticipated there would be high demand. “Have patience,” Murphy told reporters at a news conference Tuesday morning. “Be patient.”

Who could have expected that this would have occurred? Anyone with dramatic Web launch experience.

UPDATE: More on that great tsunami here:

Sarah Johnson, 34, of Portage said it took her nearly 20 minutes to complete what should have been a 30-second process, but it was worth to wait.

…

The team received 1,600 orders in the first 11 minutes of the sale, said Packers president Mark Murphy, who had to reassure fans the Packers website was still working. Team spokesman Aaron Popkey said he did not have any sales data as of early Tuesday afternoon.

“It’s just a question of volume,” Murphy said. “Fans are excited about this opportunity. We just encourage fans to be patient.”

150 orders a minute. What, were they running it in development?

To keep something like this from going where it will scare the innocent users:

As you can see, all the appearances of li have changed to p. Forensically speaking, we can ascertain that someone changed this from a bulleted list and used search-and-replace to do it.

Never, never, ever, do a blind search-and-replace on your text. And have someone else look at it before it’s scattered across the Internet.

In this case, the partner passing an invalid character did not cause a catastrophic failure; instead, it spit up a JavaScript error and probably screwed up some user tracking metrics somewhere.

But what happens when your trusted partners pass your applications crap? And what’s with this “trusted” business? Your organization’s partners have less QA than you do. You need to test every little thing they pass to your application or Web site and make sure they won’t blow you up. Additionally, you need to test what happens when you pass things over there to make sure your mistakes won’t blow you up. And test to see what happens if your trusted partner isn’t there when you need it.

Any shared application programming interfaces, any interfaces period, require proper and suitable testing because software can fat-finger data, too. Just more efficiently and faster than humans.

Trying to allocate 42 bytes led to this fatal error.

Although configuration of the server and the processes in the ops department are not the purview normally of QA, as the normal harbinger of doom, you can always ask, “What happens if we run out of server memory?” and “What happens if the database logs fill up?” Load testing might find these, but if you’re testing in a staged environment that gets cleaned out after every test run, you’re going not going to find out what happens when the crud accumulates in the pipes through daily usage. But it will be your fault for not finding it in performance testing.

So ask the unthinkable questions just to get someone thinking about them.

You know what the most basic bit of quality assurance is? Having someone else look at it.

I know some smaller companies don’t have great budgets for proofreaders, testers, or professionals of any stripe to handle their client communication needs. Or maybe they have a marketing intern on staff. Whatever. Your organization should never send something out, particularly a formal communication, without someone other than the writer/designer reviewing it.

It wouldn’t be a bad idea to send yourself the email before you blast it to the subscription list, since the missing text and extraneous nonbreaking-space-missing its-semicolon might not display in the WYSAWTS (What You See Ain’t What They See) editor that assembles your text, your logo, your custom text, and your address into the final product.

Come on, have someone else look at it. It’s what the professionals do.

It’s nice of Twitter to hide the spoiler and compel you to highlight the test to read it.

SPOILER ALERT! You can send to multiple email addresses by separating them with commas.