A lot of people struggle with figuring out ways to get better at software testing. An additional challenge is to figure out some way to measure progress. There are a lot of bad metrics out there for measuring tester effectiveness. However, in a recent post on the software-testing list, Cem Kaner had the following insight that I thought was too good not to share:

Figure out what types of tasks you are responsible for. Figure out the attributes of those tasks. For example, what makes a good bug report? What makes a good risk analysis? What makes a good test plan? Develop your lists with colleagues who you respect.

Have a colleague you trust and respect review samples of your work against your criteria. (Do the same for her.) That review is your report card.

This doesn’t provide a tidy number. But if you’re trying for continuous quality improvement, this probably gives you more and better information.

It's difficult to look backwards and reflect on all the work you've done. If you've been working at the same place for 3+ years, I suspect you can't remember half the interesting things you've done. While you don't have to actually drag our your resume and make regular updates, you should create a log file of some of the interesting things you've done. Keep regular notes on tools, technologies, new techniques, recognition and awards, conferences/workshops/training, and other accomplishments. When the time comes to actually update your resume, you'll have a wealth of information to look through to help you build different resumes targeted at the opportunities you're interested in.

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.