Sometimes, when you have a pile of work to do, and you just can't find the time to do it, it means you need to get out of the office. The office comes with distractions: people stopping by with questions, noise from across the hall, email, IM, and phone calls. Getting out of the office might mean working from home, working at the coffee shop down the street, or even just book a conference room and working in there. To make the time most effective, give yourself specific goals for the time you block off. What are you hoping to finish during that time you're away. While you're away, turn off the phone, close IM, and don't check email. Get done what you need to get done.

I remember sitting at a baseball game once with Rob Sabourin. It was a few weeks before he would be giving his talk on "What Baseball Taught Me about Metrics." He of course, was excited to talk about his thoughts on the subject, seeing as we were at a ball game and the material was fresh in his mind. He asked me, if software testers had baseball trading cards, what stats would be on the back of them?

I love that question. I think it's particularly telling of how an individual thinks about what stats make someone valuable as a tester. It's also challenging, because there are a lot of valuable things testers do that you can't easily put stats on.

Take two minutes and think about it. If you're particularly brave, respond to this post in a comment on what stats you might find interesting. If more than five people respond, I'll respond with my answer. If ten people respond, I'll even try to get the other three authors to respond with their answers. If twenty people respond, I'll email Rob Sab and try to get him to post a comment or two as well.

When testing sites (or even applications) that support multiple languages, often the static text is "professionally" translated. What I really mean by "professionally" is that it's not dynamically translated. Someone sat down and wrote it out. That's not neccessarially the case with dynamic error messages. (Or really any dynamic aspect to the applicaiton.) When you're testing different languages, be sure you're exercising the aspects of the application that are dynamic (like error messages) and see how they read. It doesn't always have to read perfect in multiple languages, but it shouldn't be awkward.

When testing a website that's available in multiple languages, often times the language differences are managed using a directory for each language. If that's the case, be on the lookout for links nested in JavaScript. Many times you'll find that they only contain a link to a single language (the defaul for the site). This could happen with other links as well, but I've found it more likely when it's embedded. Must be harder to see or something when making changes.

When testing websites for internationalization (language switches, etc...) look for transactions that transition you from one website to another. It doesn't matter if the transition is between websites internal to your company (like a marketing website) or external (like paypal). Many times you'll find that when you're returned from the other site, you're returned to the default language for the website you're testing. Not the language you were in when you left.