Eric Sink is very well known in the software development community. I would say he’s a legend, but he says he’s not one.

He writes books, software, and gives interviews about the craft and business of software. Not only that, but (not surprisingly) he’s also got a blog.

Two months ago he wrote that reading your colleagues code check-ins is a good practice, and I think this is good advice. And good advice for software testers too: I read the bugs submitted by my team on a regular base, and it’s been very enlightening (often to me, at times to them too).

I don’t like copy-paste, but as an experience on the parallels between development/testing, I’ll copy his entire post, just changing the parts that are development-related to testing-related words.
“Great artists steal“, right? Let’s see if it is intelligible 🙂 (my changes are in blue).

 

Do you work as part of a software testing team?  Here’s a piece of advice for you:

Read the bugs.

Every morning before you start your own testing tasks, use your favorite bug tracking tool to look at all the bugs that everybody else submitted the day before.

There is a reasonable chance that this advice is worth exactly how much you paid me for it.  🙂

Still, testers at many of the best teams I have known do make this their habit.

Reading the bugs is very likely to produce two benefits:

  1. The bug might get better. You might find something in the bug description that needs to be fixed. Or you may find a different direction to investigate and find the inherent fault that causes the failure. Or you may suggest another implication of the defect that increases the customer impact perception… So on.
  2. You might learn something. Maybe one of your coworkers is using a technique you don’t know about. Maybe someone else has a tool you can use. Or maybe reading the bugs simply gives you a deeper understanding of the project you are working on.

Of course, use some common sense about whether this habit is practical in your situation. For example, if you work on a team of a thousand testers, this probably won’t work well for you. Then again, I assume if you work on a team of a thousand testers, almost nothing works well for you, so this habit might fit right in.  🙂

 

(Posted with Eric’s permission)