The problem of some (if not all) modern Agile approaches is that officially all members of the development team are considered and labeled as "developers." Developers are developers. Testers are developers. Also, it is presumed that every member of a team will be able to replace every other team member if needed. I really do not think that a tester is able to replace a developer and vice versa, but there are Agile teams that practice this approach. For me, as the "old-fashioned" tester, this kind of thinking is little strange and very dangerous. I can't imagine the situation where a tester is writing the code for a developer, and I can even hardly imagine the situation where a developer is performing testing (of his own work).
Too Much Friendship
Testers and developers were always like dogs and cats. Dogs versus cats. There were always neverending conflicts, always neverending battles, always neverending criticism from both sides. And that was great. That's how things go. I think that too much friendship between testers and developers introduced by Agile methodologies ("Let's make one big, happy development family! One team! One approach! One goal!"), may be very counterproductive. The reason why I am afraid of such an approach is that this approach creates a lack of criticism from the testers' view! What do I mean by that? Imagine the tester who is a part of the Agile team. The tester's mindset is permanently modified and influenced by a developer's point of view. Imagine the tester who is very close to the developers, and they are like brothers in arms, like brand new friends. Developers show the tester their methods, their tools, the way they think about problems, how they write code, etc. Someone may think: "well, this is great, more communication means more understanding and better code, better human cooperation, better product, better working software." Not so true, I think. More communication may also mean more tunnel vision, not just for developers but also, and primarily, for testers. And where there is tunnel vision, it is very hard to test and evaluate any product as objectively as possible.
In Agile, testers became members of the development process from its very beginning to its very end. Testers are part of a design, testers are part of development, and the implementation, testers are part of the final product evaluation. Every aspect of the membership all across the project´s lifecycle is very valuable, indeed, yet also represents a big danger that testers will see only what they want to see because there will be a lack of objectivity and lack of distance introduced. And what's even worse, there is a great danger that testers will see only what developers want to see! For example: when the tester helps with the design improvement of a product, and this improvement is implemented, it is tested by the very same tester. That is not good. Or, when a developer is working on some problem and communicates his proposed solution with the tester who will test the solution after the implementation, there is a kind of psychological effect and lack of distance almost immediately mixed into the process. Even if the tester's understanding of the problem is deep. Imagine the only tester in a meeting with eight developers who are discussing the solution of some problem, or the vision of some new feature. The pressure is really huge.
"Hey Testers, Keep Your Distance!"
Now, we understand the psychological perspective of the problem and the danger it produces. I believe that testers in Agile development now face a provocative question: "How can I be a member of the team, and at the same time, keep my distance from the lack of objectivity that this close partnership brings?" I believe that we need either a tester with a lot of experience and the ability to keep professional distance in every situation, or we do need both testers as members of the development team, plus the special testing team, that is independent and standalone from the development team. This outstanding testing team will test the product after its "first" let's say "implementation phase testing" performed by the testers within the development team. Otherwise, we are facing a great risk that the product tested only within the Agile development team will be irresponsible and just not enough. And that will mean that a product that is not as valuable as we think, will be delivered.