If you take testing seriously, Agile can be a challenge to your craft. There are several reasons for this. I'm going to talk about one here: some Agilists change the meaning of the word "tester" in such a way as to dilute and hobble the whole enterprise of testing. I'll describe that change in a moment.
First, let's get it straight what a tester is. A tester is someone whose role on a project is to perform testing. There should be no controversy about this. It's an ordinary English construction. It hinges on two further concepts: testing, and role. Testing is evaluating a product by means of experiment. Every sensible definition of testing, including all of my previous definitions and those of my colleagues, are consistent with this, but it should be noted that lots of different activities, if performed with the intent of testing become part of the testing umbrella. If I read a specification, I'm doing testing in the broad sense of the word, as long as I'm reading the specification for the purpose of preparing an experiment that will allow me to evaluate the product. Meanwhile, a "role" is a characteristic set of services that a person agrees to provide. If my role is testing, and you ask me to test something, it would be strange for me to wander off and do non-testing work, instead.
The challenge I sometimes hear from Agilists is that a tester should be someone who improves the product. This seems like an innocent and laudable idea. Who wouldn't want to improve the product? Quality is everyone's job, right?
Here's the problem with that: Think of a goalie in soccer. The goalie's role is to protect the goal. A goalie can score a goal, though. Isn't scoring goals a good thing? So, why does everyone yell at the goalie when he runs forward and tries to score a goal? The other players yell at him because he has forsaken his role-- an important role-- in order to do something useful that nevertheless is someone else's job.
Of course if a goalie can score goals without in any way sacrificing the quality of his goal-tending, that's perfectly fine. But, is that possible?
Now back to testing. If you as a tester want to improve the product, don't call that testing (because it is not part of the testing role at all), instead, face the truth and name it for what it is: part-time development. You are the goalie running forward, in that situation, and when you do so you have temporarily abdicated your role on the team.
I am not saying that a person, who is called a tester, cannot help improve the product. I'm simply saying that when and if he does so he is doing something beyond testing. That's why in testing classes and textbooks it would be weird to talk about how to architect an e-commerce site, or for that matter to talk about giving first aid or a nice haircut. A tester can give CPR, or shave your head, but no one would call that testing!
I am not telling you to stay within one role. I'm saying that you better know what your role is, or else you won't do it very well. When testers shift roles casually and chronically, they themselves, and all who work with them, risk losing sight of the skills and difficulties of deeply evaluating the product. And in any team where there is no role called tester, be not surprised when the testing process, done perhaps by "the whole team" is dismissed as unworthy of deep and systematic study.