Most of the blog posts both here and in my other blog fall into the category “too obvious to even write about”. In fact, most of my blog posts end up not getting written at all, because I think what I have to say is so obvious nobody will ever bother reading it. It’s my personal form of writer’s block, one that I am aiming to overcome. Everything I think about is of course obvious to me once I’ve thought about it. That doesn’t mean it’s obvious to everyone else – particularly to those outside of or new to the field of testing.

So, then, the tester’s job description. What is it?

Doh, that’s obvious! It’s testing the product!

Of course it is. And I have worked with many people – both within and outside the test teams – who have argued that this is the only thing the tester should concern themselves with. Everything else is better left to others in the organization.

I’ve never been content with this view. As a tester, I have always seen it as my job to do what I can to make the product better, and to put in my effort where it can make the biggest difference. I believe it is not just my right, but my obligation to stick my nose in other people’s business, if I see room for improvement that affects the product quality.

For example, if you as a tester know (as all testers should know) that code reviews are significantly more effective at finding bugs than system tests are, are you going to encourage the development teams who don’t do systematic code reviews to start doing them, or will you shut up and just run your tests?

Or, if you see signs of an architectural choice that you know is bad practice and believe is likely to cause problems further down the road, even if it may be years in the future, do you file a bug report, or are you satisfied that the feature passed all your functional tests, and send the build on its merry way?

How well I have been received varies greatly. Some developers and managers are defensive. I was once told in very clear language that this was none of my business, after politely asking whether or not the project implemented unit tests. But most are welcoming and eager to take part in the joint tester/developer effort to make the product the best it can be. Sometimes it takes time to build up the trust to get there – but that is a topic for another blog post.