In some companies, Engineering/Development uses QA as the bug catchers.
And in some of those places, as hard as it is to believe, QA is rewarded based on the number of bugs they find.
The more bugs, the greater their reward.
Shocking isn’t it – because as a fine craftperson when you release your code you expect QA to find no problems, right?
Writing crappy code is never faster than writing good code. Click To TweetWill QA find bugs?
Probably. If they do, as a developer you should be surprised, chagrined, and react in horror. And you should probably apologize. Publicly.
Every time QA, or worse a user, finds a bug, you should figure out why it managed to escape your notice and be determined to do something to prevent it from ever happening again.
The Laws of TDD
Uncle Bob provides the following simple rules:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Don’t look at these rules as extra work. Look at them as massive time and money savers.
As Doug Wagner wrote awhile back “Writing crappy code is never faster than writing good code.”
Your tests will prevent you from implementing a wrong or flawed system which you then have to go back and fix.
DoD and the Boy Scout Rule
Does your definition of done include test coverage? If not, how will you know when you are Done?
Are you touching legacy code? Follow the Boy Scout Rule – leave things better than you found them.
