Comments on the overemphasis on functional testing (Erik Petersen) writes:

"I disagree entirely on this one, by my meaning of functional, which is as specified in a functional specification which the test cases are written to. Programmers stick to unit and general testing of modules only. The test team does do some programmer level testing, but only as part of their function testing."

Brian Marick replies:

"Here's an example of what I mean: suppose that a text field reads the amount of money to be added to an account. There is no reason why a modestly trained and motivated programmer couldn't do a perfectly adequate job of checking boundary conditions. Aided by the sort of checklists you find in Kaner et. al. or my book, a programmer could do a fine job of testing for other input errors. (Better yet, the programmer would have used a canned parsing routine and would only need to check that it was called correctly and that the calling code handles error notification correctly.) Having the programmer find such trivia herself is much more efficient than adding another human to the check-find-fix loop, and it diverts the tester from that testing the programmers cannot do as well. Now, depending on the criticality of the application, you might want a safety net, but one is not universally required."

Got something to add?