Test, Test and Test Again 41
snikkersnak writes "Richard Collins has written a piece about developers and testers; the article is arguing that in closed development these two roles have to be chained together one-on-one in order to reproduce the 'release early and often' effect of open source development."
Re:Wrong. (Score:3, Insightful)
Uh, from my experience... (Score:4, Insightful)
Of course, I also don't think "release early and often" is a good philosophy. If you release early, by definition you're releasing something that isn't yet ready for the public, and when the public uses it they're going to be disappointed and a lot less likely to try your next version.
Re:I stopped reading... (Score:1, Insightful)
First of all, I don't believe that is what he said! Quite the opposite, he seems to imply that physics grads are smarter (in at least one area) than compsci majors! And I think that is right on! Physics grads are trained in mathematics, physics and, more generally, how to solve a host of complicated problems. Compsci grads are taught programming languages and algorithm construction and not a helluva lot of problem solving.
I personally prefer programmers who are engineers with a master's in compsci or even self-taught. They problem-solvers first and algorithm-artists (to coin a phrase) second.
Re:Automated unit tests (Score:2, Insightful)
When a tester spots a bug, a unit test might be written to document the behaviour, that the developer didn't think of, thereby reducing regressions.
In additional to 'bugs', testing is useful in checking whether an application performs a task as dictated by a specification, i.e. missed functionality. Unit testing won't catch bugs in code that hasn't been written in the first place!
As for the 'design work' matter, the development ought to be a collaborative effort between the Business Analyst, UI Designer/Usability specialist, Tester and Coder. The tester is often the first person to see the application. If a user interface isn't usable in the eyes of a tester it probably won't be to the end user either. But rather than delegate enhancements to the coder, the tester ought to refer these thoughts back to the usability person. As in the example, if the UI specialist agrees that yes, "it'd be great if this screen had a 'quick user lookup' field" then that could be written as a requirement in the specification in consultation with the BA. - e.g. 'the system shall provide quick user lookup'.
Agreed, it's not the role of testers, and hence developers, to go adding features just for coolness sake. That's how projects never get finished. But in testing that the software meets requirements in a specification they're also, to some degree, testing that the specification is complete and workable. And if the spec is set in stone then at least suggested enhancements can be documented for a future revision.