This post comes to you on what for me is a holiday. I have the day off. Days like this remind me that it's good to get away from work. I don't do it very often (including on holidays). However, the only reason I'm able to sustain that is because I know when I need to take "mental health" days. Those are those few and far between days where your presense at the office won't be missed, so you just work half a day or you call in at the last minute to see if you can just take the day off.

I might do this a handful of times a year, but it's enough to sustain me. A half-day Wednesday is often more valuable to me than a three-day weekend. For some reason, a break from the routine puts me in a better mood, makes me more resilient to the daily issues that come up around the office, and can really help me focus. I suspect the mid-week days work better then weekend days because my weekends are often just as scheduled as my weekdays. So an ad hoc day off really is a day off.

If you don't do this already, try it some time.

In software development, we are often discouraged away from "soft, fuzzy things" like emotions. That's unfortunate, because they are important and powerful cues to let you know something is going on. You can even use them in your work as a tester. Here are two to start:

• Feeling angry? Take it out on the software and see how many bugs you can find before you stop feeling angry.


• Feeling frustrated or confused? Catalog all the areas of the software that bug you, that make you feel dumb, or upset. Those are usability issues that other users are going to be frustrated with too.

Today's tip comes to us "anonymously." I think they are just nerviuos about the title.

When someone's stuck, you can sometimes help get them unstuck by having them walk you through the problem. But the trick is, you need them to treat you like an idiot. Or, like fellow tester Jason Horn sometimes says, "Talk to me like I'm a five-year old."

By walking someone through a problem one step at a time, without using the jargon or glossing over some technology or process, the person explaining often gets a fresh look at the problem. When we gloss over technology and process (which most of us do all the time when we problem solve), we miss some of the critical bits that can help us solve our problem. Just the simple act of explaining it to someone else can give us the insight we need.

I forget, simply forget how much good stuff is already in existance.  Ask yourself, when is the last time you read an article or blog from someone in the testing community (besides this post).  Another question to ask yourself is when is the last time you read something from someone you don't know or have tried reading a different blog.

Some people need regular distractions (music, conversation, etc...) to work effectively. Others need silence and long periods of uninterrupted time. Recognize that people are different, and they need different things to allow them to be creative.

If you manage someone who has different work patterns than you (for example, you're always heads down and they always appear to be talking to someone), don't assume that means they aren't getting anything done. Instead, look at their work product. Do they produce as much as their peers? Is it of the same quality? That's a better measure of their work.

That said, if they happen to be an unwelcome distraction to their peers (because their the one always talking while everyone else is trying to be heads down), you may need to address that.