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.

While it's inspired by something Ross Collard once said to me, this tip came home for me this week while talking with a fellow test manager who was struggling to find enough time to test. Don't forget that while developers are fixing bugs for the next build, you can likely keep testing. Major blocking bugs aside, if you've still got the code there's likely something you can keep moving forward on. Just because you're turned around enough issues for them to work a new build, doesn't mean you have to stop.

Even if your process states you shouldn't be submitting bugs against a known bad build, you can continue to:

• learn about the product;


• develop test ideas;


• execute tests for areas you believe to be stable;


• develop test assets (like automation, or performance tests);


• etc...

All of those require some version of the product, even if it's not the final version of the product.

Only list the technologies you're fluent in on your resume, or make it clear what your skill level is if you're listing things you've had exposure to in the past. I use to add qualifiers to my resume; like beginner, intermediate, and advanced when I listed a tool, language, or technology. Now I don't list very many technologies at all, since most managers I've interviewed with have been less concerned with technology and more concerned with skill. I think that's natural as you get more experience under your belt. But I could be wrong.

When you're pulling together your resume, only list tools and technologies that you actually know. Don't list the stuff you've had "exposure" to. If I can't ask you an interview question on it (like, write code in language X, or tell me how you would configure Y, etc...) then you either don't want to list it, or make it very clear that you've only had exposure to it. When looking at resumes nothing turns me off faster than seeing a laundry list of tools and technologies without context for how they have been applied by the candidate.

For me, it comes down to trust. In an interview, I'm trying to figure out what you can really do. If you get my hopes up by listing Java, Ruby, or some other techno-widgit I'm really looking for, and you can't actually do it, I don't know what else you can't really do that you're telling me you can. Even if you're really good at all the other stuff, once I feel like you've falsely represented your skills, it's hard to dig out. On the other hand, if someone has all the right skills but is missing the techno-widgit, I'm likely to hire them. I can teach someone Ruby.

For me, loosing the interviewer's trust isn't worth the eye-candy of listing all the technologies.

Sometimes, when you have a pile of work to do, and you just can't find the time to do it, it means you need to get out of the office. The office comes with distractions: people stopping by with questions, noise from across the hall, email, IM, and phone calls. Getting out of the office might mean working from home, working at the coffee shop down the street, or even just book a conference room and working in there. To make the time most effective, give yourself specific goals for the time you block off. What are you hoping to finish during that time you're away. While you're away, turn off the phone, close IM, and don't check email. Get done what you need to get done.

Defect databases get big quick. Even on a well coded, well run project, if the development team is firing on all pistons a backlog of possible issues, bugs, and feature requests will build up. Over time, tickets can get stale. They become less relavent, are fixed indirectly, or change in priority/severity. From time to time, get in there and clean em up!

This activity can be rewarding on multiple levels. First, if you just go in and clean our your personal backlog (the tickets in your queue), you get a better idea of the work that's really on your plate. This both reduces the burden you might feel (like when you have an empty inbox), and also helps you prioritize the work better. Second, if you clean up, update, or refresh all the tickets you've entered (possibly hitting other people's backlogs), you give that same small charge to the entire project team. If everyone does it regularly, the database of tickets remains clean and relavent.