Between a blog response or two
here and two podcasts
on the subject, with Jon Bach's keynote from STPCon still to come, we've provided plenty of coverage of test is dead right here.
If you'll permit me, I would like to add one more little wrinkle to the mix.
Now any attempt to reduce a one-hour talk to a sentance or two is going to be lossy, especially one articulated by multiple people, in different ways, at different points in time. Yet if I had to reduce the test is dead movement to a few sentences, I would say something like this, and have some confidence in my statement:
"Hey man. All testers do is report conformance to spec (or lack thereof). So why keep a whole army around? We can have a few test automators writing automated GUI tests, hire a company to do crowdsourced exploratory testing (or rely on our users), and cut the fat."
What's wrong with that?
As I've said before, if you give away your software, if that software is funded by advertisers, if you can monitor production and rollback/fix/redeploy quickly, and you don't touch money - sure, its possible to be successful with a strategy like that.
Only every time I engage on this, something strikes me wrong.
The idea above is reductionist: It reduces
testing to conformance to spec.
But what about?
The tester that notices something going on in the user interface is not quite right, and makes suggestions to improve the specification?
The tester with domain expertise, who notices that a change in Product X is inconsistent with the behavior of Product Y?
The tester who knows the product so well that she is pulled into tech support meetings, who find the problem, isolates it, and gives a test (sometimes executable) over to the product owners to prioritize or the developers to fix?
The tester than can explain to the programmers why the software does what it does now, due to a complex business process?
The tester that knows what is really going on, and can inform management about it in time to change plans to meet reality?
... and those are just five questions I thought of offhand, over my lunch hour.
There are a lot of ways that a traditional tester can add value in the process that "test is dead
" seems to ignore.
Arguably, these these are not "traditional testing." and yet, I still call it testing
I still call it testing
During the STPCon panel discussion, I made the statement that one way to improve delivery speed is increasing code quality before it gets to test.
A few people took exception to this, saying that testers can be all over the process, helping to improve the product design, the usability, the user interface, and exploring, exploring, exploring. This is very much in line with my statement above, yet I like the term testing. I'm not ready to give up on it yet.
I'm still thinking on it.
For the time being, though, I am convinced that there are opportunities to add value testers have that GUI-Automation/Crowdsourced testing is missing. What am I missing?
I would like to hear from you.