This is a management tip I've used that's worked well.

Have someone on your team own each testing tool.  Have someone be the tool guru, the go to person to learn from, the person who knows when the license needs to be renewed.

If you host brownbag learning sessions an occasional tool review is a good topic too.

Because it's such a good post, I'm stealing Anne-Marie Charrett's post from yesterday on "Do your bugs only glow when its dark?" In the post she outlines some guidelines she uses to report bugs when doing offsite exploratory testing:

• Provide the time it takes you to write up the defects in your estimate


• Get agreement on the level of detail for defect reports


• Write up the bugs as you find them, don't let them queue up


• Encourage customers to use a defect tracking tool

Read her full post for the details!

I recently had a couple people who work for me provide me with difficult feedback. Difficult for me to hear, and I'm sure it was difficult for them to say. If someone you work with needs feedback, even if it's difficult, be willing to provide it.

If you're not sure how to do that, I recommend starting with Crucial Conversations. It's the first step in becoming an Influencer, but it's also an important step in building the team you want to work in. You need to be willing and able to talk with your boss and peers about difficult topics.

Note, those two books are written by the same authors. I'm a fan of their work, and I've read "Crucial Conversations" around five times now. They've also written a book called Crucial Confrontations. I'm less of a fan of that book, but I only think that's because it seems like it's only a specific application of the general principles laid out in "Crucial Conversations."

Today's tip comes from High Performance Web Sites by Steve Souders. Before the author jumps into web tuning tips, he provides a very brief introduction to some of the features of the HTTP GET headers, including:

• compression for requests which the Accept-Encoding and Content-Encoding headers to reduce the size of the response using common compression techniques


• conditional requests which uses the If-Modified-Since, ETag, or If-None-Match headers to send the last modified date back to the server - if the server returns a 304 status it skips sending the body of the response


• expiring requests which use the Expires header to save the expiration date with the component in it's cache


• persistent connections which use the Keep-Alive header to keep the same TCP connection open to the same server (reducing the overhead of opening and closing multiple socket connections)

If you're a regular performance tester, there's no news there... but I though it was a nice summary for those who might be just breaking in.

I'm a couple chapters into the book and like it quite a bit. The format reminds me of the "How to Break Software" series of books, only instead of attacks the book provides rules. I'm not willing to sumarize any of the rules without contacting the author, but I recommend the book. It's well written and covers some great fundamentals of front-end performance optimization.

I was talking a look at Google product search and wanted to think of the simplest test I could that might reveal a lot of information. After the page loads, if you simply hit the refresh button in your browser repeatedly, you'll be able to notice the following behaviors:

• query response times change each time


• some sponsors change each time, while others don't


• column width (between product description and price) changes based on sponsor size

This gives me several ideas for testing and learning about the product. First, I feel like I could quickly program a script to track sponsor results and performance over time time. If I varied the search criteria for similar products, this could quickly be used to start to verify the accuracy of  adds and the rules for displaying them. This could also become a good no-load baseline for the performance of whatever environment you're testing in.

Understanding the relationship between sponsor text (number of characters) and column widths would be worth looking into. Might be an issue, might not (likely not and issue). But it's also something that can be verified quickly and repeatedly with the script that's pulled together.