Many people have mentioned the need to include testers in Scrum or agile, and planning your processes with a testing step somewhere (normally close to the end).
All of these ideas are OK. There's nothing wrong with testing, the problem is that testing is done too late. Would you buy a car which engine was "fixed" after it came out of the line and didn't start? -- I certainly wouldn't not!
In software, like in cars, problems should be found early, very early. In fact problems should be found so early that they never reach the (needed) testing phase at the end (of the day preferably). This is why we need to stop thinking about testing as something separate from development or even coding. Testing must be part of every step of the process.
I don't agree with the proposal in this article. The tester should not be the one developing the test cases in isolation, and certainly not after the team has planned! The reason is that the tester will find faulty assumptions and possible design problems while thinking about the test cases. That information is crucial for the team to avoid building problems into the software.
Testers should be involved from the start. In fact, for each story that the team is planning in the sprint planning meeting, they should at the same time plan the test cases, review the initial assumptions and only after that should they actually plan the tasks to accomplish that story.
The best way to develop quality software is not to test the bugs out, it is to develop quality in -- this is why testers should be involved in every step of the process (Scrum in this example).
As Deming said:
Build quality in, don't inspect quality in.
Oh and by the way, if the test cases are (really) written why would the coder wait for the tester to verify that his code change works? -- Just run the tests immediately! It seems to be that the coder not running the tests herself is just a way to avoid feedback, which is key to Agile!