Sometimes when performance testing you need to do some research into other websites so you can make predictions on how people will use yours. This can be a time consuming. You need to think of sites that will have similar users with similar usage patterns. They need to be roughly the same size and scope for the data to be transferable. It's not easy.

Once you've thought of some sites, you then need to get stats. There are a lot of ways and places to get those stats. Some of them reputable, some of them not. One place I turn to for some basic stats is Alexa. They seem to have good data, it's a very easy site to use, and I always find out a bit more than I was looking for.

Stealing from a post I did on SearchSoftwareQuality.com, here are some questions I use to clarify testing status when doing debriefs:

• What was your mission for this session?


• What did you test and what did you find?


• What did you not test (and why)?


• How does your testing affect the remaining testing for the project? Do we need to add new charters or re-prioritize the remaining work?


• Is there anything you could have had that would have made your testing go faster or might have made your job easier?


• How do you feel about your testing?

Found a cool W3C website for checking if your website is mobile friendly. Just enter the website and go.

As you can see from the image, QuickTestingTips didn't do so well. Apparently our page is too big (over 20k) and the theme we use has some tags that are apparently read as popups by the scanner. (I couldn't figure out why, and my iPhone loads the site just fine... so whatever.)

Well, it's probably not perfect. But what tool is right? It seems like a handy (free) place to start. Give it a try and see what you find.

Today's tip comes from a post I read by Scott Berkun:

The simplest, sanest step in the world, a step few people do, is when a project ends go back and review your estimates and compare against the reality. Put it up on a big whiteboard, sit down with a handful of your team leaders, and discuss two things: what factors explain the difference, and what smarter things you might have done to have a better schedule.

That's an excerpt of his recent post on Magic Numbers of Project Management. Read the post for full details on the tip, but follow the advice. I suspect you're asked to estimate your work on a regular basis, and understanding where the magic comes from is an important part of that task.

Today's tip was submitted by Zach Fisher.

Even business owners are subject to inattentional blindness. Their vast experience allows them to perceive certain scenarios as impossible, improbable, etc. Sometimes their rationale is enough to convince me of the impossibility; other times, it is not. It is in these times that I'm compelled to use my '0908' card. What is the '0908' card?

It happened in September 2008, hence the '0908' moniker. Many of us lived blissfully ignorant of the complex financial forces at work around us. Our inattentional blindness was fed by the fruits of happy path living: nothing is going wrong NOW. It is not that we're stupid. We just had no compelling reason to suspect otherwise. It wasn't until activities in disparate areas, leading to a confluence of improbable circumstances, resulting in a global financial meltdown - that it became reasonable to suspect the 'out-of-left-field' scenarios.

You certainly don't want to overplay the '0908' card ( "What if a meteor hits our server farm on Feb. 29, 2012?" ). Nor do you want the conversation to degrade into a puddle of techno-babble. It may be more practical to assert things like, "I know we don't support Linux distros now, but what do you think about Ubuntu's growing market share?" or "Are your friends getting netbooks like mine are?". Enlightening business owners of those disparate dependencies - invisibly churning within their systems - may head off certain disaster downstream.