Words are funny things. Take for example, the word 'testing.' It seems at first that word is pretty obvious - checking the software to find out if it works or not, right?
Yet in certain parts of the Agile community, you see a very different definition:
- It's not a test unless it is automated
- It's not a test unless it is a unit test, written by a developer
The underlying attitude seems to be We don't need no stinkin' QA people.
And, sadly, I have to admit, I understand where these guys are coming from. There are various schools of software testing, and, as I have pointed out in the past - if you are a strong developer who's only exposure it so the oblivious school of software testing, you might very well feel that you don't need to stinkin' QA people. You might even be justified in it, for your particular shop.
Still, to limit testing to developer-facing is, well, myopic. You leave a lot of interesting failure possibilities out. In other words, like eating only a bowl of sugar-smacks for breakfast - it is unabalanced.
I've been thinking of writing a strong piece on this for a couple of years now that expresses my whole strategy. It looks like Luke Franci beat me to it; check out his essay on the subject here(*).
Don't get me wrong. I think TDD is wonderful, and that having developers write tests is a great way to increase the quality of the code at every instant in time. Also, testers can plow through much more functionality when it basically works in the first place - and TDD is a great way to get this.
No, testing isn't over-rated, but developer-testing alone -- might be.
UPDATE: At the top, I mention the magic word re-definition of test. You can see that in the Luke Franci article. If you read really carefully, what he says is, essentially "Testing isn't enough; we also need to do testing." What he means is: "(Developer Facing, automated, code-driving) Testing isn't enough; we also need to do (non-developer facing, traditional) testing."
I am really not a fan of using the word testing to mean a small sub-set of it.
Friday, August 01, 2008
Subscribe to:
Post Comments (Atom)
3 comments:
Myopic is the perfect word. The developer must always be ready to put his head in different places. Unit tests force the developer into the place of the user of his code, b/c the unit test is the first use. He has to use it to test it. However, when your nose is in the code, you lose sight of larger, more macroscopic issues.
What's needed is the integration of several distinct perspectives. I can get my head into thinking about the code from a different angle, BUT I'm going to be limited in my ability to do so and will be likely to manifest some blind spots.
The QA person starts with a more macroscopic perspective. All the stakeholders in the project may have distinct perspectives. I'm convinced that good software must be inspected and probed from each perspective. And those perspectives need to be integrated via conversation between stakeholders.
The anti-pattern we need to avoid is called group-think. The developer with a comprehensive suite of TDD derived unit tests will contemplate the bulk of the work that went into them and extrapolate a correlation between that work and the software's goodness. But those tests just prove the software does not fail at the points he was concerned about during development. They won't touch upon (unless he's lucky) the things he didn't consider.
The Emperor's new clothes comes to mind. Everyone buys into the con-men's narrative that only wise and enlightened men can see the fabric until someone with a distinct perspective questions the unquestioned.
So I missed this post somehow, and repeated it with my own pointing to Francl's presentation. :-)
Oops- accidentally hit return on the comment above. That was from me, Jonathan. :-)e
Post a Comment