Kyle Smith

I’ve been taking a small break from reading Isaac Asimov’s Foundation series to read some other books I picked up from the newly-discovered IBM Poughkeepsie site library. One of them I finished was Cem Kaner’s book Lessons Learned in Software Testing, which had one lesson in particular on evaluating tester performance that caught my eye.

How should a tester (or other employees) be evaluated? Rather than look at arbitrary metrics like bug counts, familiarize yourself with their work (the actual bug reports, documentation they’ve written), collect comments from coworkers or project stakeholders that have interacted with them, and consider the following items:

• What fights does he get into and why?
• How well does he meet deadlines?
• How well does he keep his own promises?
• What kinds of problems does he miss?
• What types of assistance has he provided to other testers and
  programmers to make them more effective or more productive?
• Is he gaining new skills? How well is he transferring his skills to
  other testers?
• What issues has he taken stands on in your company? How do these reflect on his business judgment and personal ethics?
  (Source: Lessons Learned in Software Testing, Kaner et al)

For those of us that have worked at IBM, being evaluated on the above items would be a pleasure compared to Personal Business Commitments (PBC) ratings and results, which never seem all that concrete to me.