For the last year or so I've been using a simple status dashboard to coordinate testing for releases. I find an easy way to share the dashboard is to use a spreadsheet Google doc. Using a Google doc makes it easy for everyone to make updates and see updates as they happen.

Here are the columns I'm currently tracking:

• Client


• Release Number


• Code Complete Date


• First Pass Test Complete Date


• CM Review Date


• Regression Test Complete Date


• UAT Date


• Production Date


• Development Status


• Test Status


• Testing Lead


• Deployment Ticket Number


• Scope Summary

It looks like a lot, but it all fits on one screen (no scrolling needed) and each row in the spreadsheet represents a separate release. If a date is in the past, the cell is colored red. If it's today, it's colored yellow. And if it's done, it's colored green. With one quick glance, you get a high-level view of all the releases and their current statuses.

Today's tip comes from a talk Dave Christianen gave last night at a local Ruby group meetup. When testing a Ruby on Rails application (or really almost any time), make sure you have Exception Notifier turned on. If you test Rails apps, and haven't seen Exception Notifier, check it out.

Following up on yesterday's post on finding and protecting your most productive time, pay attention to who you're working with and how you're working with them. Take for example the following poll I found in Writers Digest magazine:

How do you do your best writing?
a. By working alone
b. By meeting regularly with a writing group
c. By participating in an online community
d. Through all of the social options above—and more

In the poll above, 85.7% of respondents said they do their best work alone. The other 14.3% said all the social options above. That resonates with my experiences as well (as a writer and as a tester).

I often think writing is a great metaphor for software development. In this particular case, it's spot on. We do a lot of work alone. We do a lot of work in meetings or with team members. And we use a lot of social media (IM, email, wiki's, project blogs, RSS, etc...).

I do my most productive work alone. While I appreciate the feedback that comes with working with others, I know I'm more productive when working alone.

I know when I'm my most productive. It's somewhere between 6:00 AM and 9:00 AM. I'm lucky actually. Few people schedule meetings during that time. (Where I work right now, few people are even awake during those times.) It would be much worse if my most productive time was right after lunch.

I call that time period my most productive because it's where I turn out the most X. For me, X could be code, words (for an article or blog post), or test ideas. I do my highest quality and most prolific work during that period of the day. It has something to do with my head being clear and the coffee just kicking in. I'm not thinking about life's pressures yet because my day just started, my email queue is empty. I just get stuff done.

If you know when you're most productive, do everything you can to protect that time. Block your calendar so people don't schedule meetings. Turn off your phone and close your email and instant messaging clients. Do what you have to keep the world at bay. Try to create at least two or three hours for yourself where you know it's your time to get stuff done. And if possible, get that window to overlap with when you're most productive.

Today's tip comes from Chris Wallace. In his post on The last browser testing advice you'll ever need he talks about his coding and testing process, lays out the a-grade list of browsers (from the Yahoo! UI Library), and if you take the time to read the comments you'll see several tips from readers of the site (including this link to the multiple IE installer).

Worth the time, read it if you can.