To help them stay focused and productive, some writers give themselves daily minimums. In a recent issue of Writer's Digest, author Hank Schwaeble said he uses 500 words a day as his minimum. When most authors do this, they have little to no expectation that those are 500 "publishable" words. That is, they don't think they will be polished or won't need editing. I'd go so far to say, they might not even have an expectation to publish them at all. It's more about just making sure you log time doing the most basic unit of work - writing - so not all your time gets taken up by editing, revising, contacting editors, or other administrative work. Different writers do it for different reasons.

There are some other examples of how people in our industry use quotas like this. Jerry Weinberg’s Rule of Three is one: "If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean." And I have some similar rules for chartering that tell me that if I don't come up with at least X test/charter ideas, then I haven't really explored the problem enough. I would never expect I'd execute all the charters I come up with, but because I'm a believer in overproduction and abandonment, I feel it leads to better work on my part.

Think about different aspects of what you do on a day to day basis and see if there are any areas where you might benefit from overproduction and abandonment. What "minimums" could you put in place to help you get better at developing more test ideas, or help you better execute certain tasks, or just help you break through a wall you might have while learning something new? Sometimes setting aside judgments about the quality of your work, and just getting time logged doing it, can be an important step at becoming more effective at it.

That's right, you're looking at a pressure cooker. Apparently, it's also a sophisticated test tool. (Who knew?)

Anurag Khode outlines using a hoffman box for testing mobile devices in his post on Hoffman Box Testing in BREW. While the post does appear to have some copy and paste fork-lifting from the Hoffman Box Wikipedia entry, it also contains an interesting set of test ideas.

Apparently, the main goal of the Hoffman box (or pressure cooker substitute), is to shield mobile devices from their signal in an effort to test signal-fade or signal-loss. For $24.00, the Wearever 8-Quart Stainless Steel Pressure Cooker officially qualifies as a test tool under $100.

I'm seeing more and more testers using twitter these days, so I thought a tip on designing and testing your tweets might be helpful.

Jakob Nielsen's Alertbox has a great lesson on designing your twitter post. He uses an iterative design process to make sure you express yourself clearly and succinctly.

Essentially, you need to:

• Grab the user's attention. In his example he uses capitals to identify key words in the tweet


• Front-load the tweet with attractive keywords


• Be specific and try and keep your tweet to 130 characters so that others can re-tweet


• Save space by abbreviating over full sentences


• Don't make multiple points in your tweet


• Think about when you post your tweet

It's much better put by the man himself. You can find his post here: http://www.useit.com/alertbox/twitter-iterations.html

I like the way he partially shortens the URL link to help emphasize the point of the tweet.

And you thought twitter was easy!

Whenever I'm testing an application, I'm always looking for built in test oracles. That is, something I can use within the product to help me identify possible issues in other areas of the product.

For an example of this, let's look at the WSJ's Market Data Center. Within the Market Data Center you can look at some performance charts for the S&P 500 Index (to pick one randomly). If you follow that link, you should notice that you're presented with some interactive charts. However, you might also notice a tab for "Standard Charting."



If you click this tab, the same data is rendered in a non-interactive way. You would expect that when the static charts on "Standard Charting" are rendered, the data they display would match the default rendered data on the "Dynamic Charting" tab. It's those three little words - "you would expect" - that mean you've found an oracle. You now have a way to identify problems by using the application itself.

When figuring out what to smoke test for a release/build/environment, I run down the following list in my head:

• What's changed in this build/release?


• What features/functions are most frequently used?


• What features/functions are most important or business critical to the client?


• Is there technical risk related to the deploy, environment, or a third-party service?


• Are there any automated tests I can leverage for any test ideas I came up with in the previous questions?

Based on my answers to those questions, I come up with my set of tests for the release. If it's a big release (aka more features or more visible), I'll do more smoke tests. It's been my experience that different releases often require different levels of smoke testing.