As a tester, I have the disposition to embrace perfection. Call it cliché, but of all testers I know, there’s not one indifferent to the quality of the product they are responsible for. Good is never good enough, compromises are loathed and short cuts looked down upon. It’s pride.
Of all the developers I know, there’s a fair number of guys (and gals) who share the sentiment. In general however, a developer’s objective is a different from a tester’s. Does it looks like it works? Ok, I’ll move on, build more cool stuff …
I blame the waterfall and V-model development processes. Who cares if the comments make sense? If the form matches the style guide? If the error message is cryptic? If I won’t wait for the next build to review? The testers will pick it up. And if it explodes, it’s them who get the blame. They get paid less anyway, so they can do the dirty work.
In Scrum, the whole team is responsible for the results. Testers suddenly become the developer’s best friends, someone you don’t want to tick off. Sure, they are in the same boat as you are – but you sure as hell don’t want to get asked to test. Test! Me!
Having direct access to the developers at all times opens a whole new world to testers. They can set or push the limits, get information quickly to improve their skills, and shine in their role as supporters. Because ultimately, “tester” is a support class in the software production role-playing game.
Sure, you cannot prevent things like
// saves teh data private static void dataSave(object datta)
No tester in a team with a 5:1 or higher developer-to-tester ratio can. But you, the developer, can. Show a little love. Please, you won’t regret it.