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 Senthilnathan over at Testing-Virtuoso. Senthilnathan provides a very succinct set of tips for network performance testing. From that post, some tips for performance counters in Perfmon:

Network Interface\Bytes Received/Sec
Network Interface\Bytes Sent/sec
Network Interface\Bytes Total/sec
Network Interface\Current Bandwidth
Network Interface\Output Queue Length

If the Network Interface\Bytes Total/sec is more than 50 percent of the total network utilization, then your server is having some problems under peak load conditions.

Correlate the network counter values with Physical Disk\% Disk Time and Processor\% Processor Time utilization. If the Disk\% disk time and %processor time values are low and the network queues are high then there might be a problem with your network card/ bandwidth.

I love seeing what counters performance testers look at. If you have some different counters you use when testing, feel free to share.

A lesson I learned from James Bach a number of years ago is to list out attributes of something before you test it. You can practice this with anything: the book on your desk, your keyboard, or this WordPress blog. List out as many attributes as you possibly can. Share your list with other people. Have them tell you what's missing.

This is a great way to come up with test ideas for a product. Practicing it can be fun and easy, but it's also very applicable to what we do as testers. It trains your mind to be able to quickly identify the relevant attributes of a product. You'll find that your test idea generation abilities improve as you get better at clearly identifying attributes.

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.”