Will a new job position help your team?
Would a person on your team with the skills of a developer and a QA person help you create better products? An post on Artima by Alberto Savoia titled Developer Testing Masters and Brain Surgeons, which I found via InfoQ, describes such a hypothetical position.
What really interested me is that last summer I had a conversation with our QA guy about what our ideal solution would be. I personally think QA (or at least some of them) should be trained programmers so that they can better QA code. I realize that most QA departments merely follow a test script and work at the ‘user’ level, i.e. the user interface of whatever system they are testing.
What I would like to see is someone who can QA the code. In this scenario the tester would go over not only code but QA the unit tests as well. Unit testing is great, but there is a tendency to only write tests that end up working. I don’t believe in the ‘one test per method’ model. Some methods need several tests to truly be effective. Does it test for expected exceptions? Nulls? Out of bounds parameters? These are things that a good code QAer can catch and where Alberto’s suggested job position would really shine.
Alberto says:
In many cases, developers lack the drive or skills to adequately unit test their own code. Testing can be as technically challenging as development – and often more challenging. On top of that, unit testing takes time. It takes 3-4 lines of JUnit for every line of Java to get good code coverage, for example. And when most developers, or their managers, are pressed for time, features and schedules usually trump testing.
How true that is!
My Plan
Sure you can cover some of this from code reviews and such, but a really impartial viewer would be a big plus IMHO. What I had thought about doing for our team is setting aside time each week for each developer where their task was specifically to create unit tests on other developers’ code. In order to encourage ample testing, I would either set a goal for number of tests and assertions for that week. The amount would depend on the current lifecycle of the code in question. The more fresh the code, the more tests should be written.
Going hand-in-hand with this would be finding bugs. Not solely code-review type of bugs but actually writing a test that generates a bug, report it, then depending on the bug, fix it or have the original developer fix it.
Will It Work?
I personally would love to do this. I’m all for code quality and not afraid of code reviews or other ideas and opinions on how I did something. I know not everyone is though. Some people are really, really opposed to code reviews in general and hate writing unit tests.
So, the question here is, would you write tests on your peer’s code to try to break it? What metric or incentive would encourage you?
Don’t miss anything, subscribe!
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
[...] Original post by The Bull and a wordpress plugin by Elliott [...]