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!

People can be messy can't they? They can be unpredictable and can disagree with you and your opinions. Because of this, it's  easy to shy away from communicating directly with others and resort to email and documents to present information, especially if the news is bad. A scenario we testers are often faced with!

But communicating directly with someone either face to face or by phone is a great time saver. I will give you an example.

My current client has a very 'organic' way of developing software. Having no experience in IT development, a lot of the typical methods of communication just don't work. Status reports are left unread on desks, emails and bug reports are ignored. I was finding it hard to get him to understand that the quality of the software was just not there. Until I resorted to 'the face-to-face'.

I called him down to the showroom and showed him all the bugs I had found that morning. He was stunned and amazed to see what issues I was finding.  It helped him understand how far there was to go on the project.

This simple face to face event saved me a lot of time and him a lot of money.

You may not work in such a 'flexible' environment, but its still possible to incorporate verbal communication into your testing tasks.

Here are some suggestions:

• Talk to your developer before writing up important bugs


• Show your stakeholder bugs to clarify what type of testing is required (Is this bug important to you?)


• Show your stakeholder the application status instead of writing up a status report


• Hold a workshop and discuss the application with developers and shareholders before testing

I'm sure there are lots of other ways. If you can't communicate face to face, phone and even IM are good alternatives.

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 come from dailytestingtip - a recent Twitter creation similar to this blog. It's been started by our newest QuickTestingTips author, Anne-Marie Charrett.

"If bug reports are getting developers riled up, try adopting a passive voice approach to writing."

The post then links to Ivan Walsh's post on when you should use passive voice. From that post:

When to use the Passive Voice:
1. To emphasize the action being performed; the active voice highlights the person doing the action.
2. To show that results are more important than the person/system performing the action, for example, ‘the errors were generated by the system.”
3. To avoid assigning blame to a person, for example, “An error occurred when the system overloaded.”