Yes, "agile" can dis-empower anybody when it's used as a buzzword rather than actually being done. It sounds as if you're in that situation now.
Here's what agile, when done right, can look like. I can't tell you how to bring your situation in line with what's below, but at least knowing where to aim can help you at least move parts of your organization in that direction.
The Agile Teams
In agile, or at least in XP, there are just two teams: the customer team (also known as the product owner, the business folks, or similar) and the development team. Each has distinct responsibilities and control over a particular area of the development, and they don't step on each other's areas. It's possible for someone to play a role in both teams, but she would have to be careful to keep those roles separate, wearing only one "hat" at a time.
Testing is done by both teams, for the obvious reason that the customer must do at least minimal testing just to see if he got something resembling the story he requested. It's not unreasonable for the customer team to have professional full-time testers on it, if the customer feels the need, but that would indicate a certain level of distrust in the development team that should probably be worked on. Testing is a lot cheaper when done by the developers than when done separately because code can be designed to be tested more easily, if the developers know what's needed.
The development team will be doing extensive testing, whether formal or not. In the worst case, it's done by an individual developer just running things "by hand" as he programs until he decides he's done working with the story. But usually there will be automated tests of various kinds (unit, functional, UI, system), discussion of testing strategies, perhaps continuous integration, and so on, all of which is designed to give both the developers and the customer confidence that what they think they've done actually works.
In this world, full-time professional testers are developers, and full members of the development team. It doesn't matter if they're not writing the code under test: they're still working with the rest of the team on getting stories completed, contributing to the design of the system (particularly in the area of making it easier and cheaper to test), often working on and even writing test frameworks, and so on. This is where you want to be, as far as I can tell.
Agile Project Management
Your phrase, "a Developer promoted to a PM," rings alarm bells. "Project managers" on the technical side are generally bad news in agile since their traditional work is done by the actual workers in the development and customer teams in agile.¹ The customer and developers work out the stories, the developers estimate them, and the customers choose the order in which to build them, and the developers keep track of story progress and team velocity. In particular, the only people who should be contributing to producing estimates for a story are the ones that are actually doing work (or willing to do) work on the story (be it writing the software, testing it, or deploying it).
PMs often realize, consciously or not, that there's not a lot of need for them in this scenario. This often leads to a situation where they are (again, consciously or not) subverting the process by trying to set estimates for work they don't do. It's a difficult and often very political process to prevent this from happening. But if you can't prevent this, you're moving away from agile, not towards it.
To move away from such situations, the general approach is usually to:
- Have non-developing PMs move into the customer team, helping to handle the details of their work (negotiating stories with developers, figuring out what order in which to do them, and estimating and tracking overall, long-term progress on the product).
- Have developing PMs spread the work they do amongst all members of the development team, such that there is no longer a "PM" in the develoment team but the PM work is spread amongst all the developers.
What you want, and what will work well (if well executed), is probably to become a full-fledged member of the development team, contributing to the development in the particular areas in which you are skilled. I can't give you specific advice on how to make this happen because that's completely dependent on the particular situation in your company, and the willingness of others to accept that "testers" are developers too. But I hope that these ideas can at least give you a framework in which to try to move towards this.
¹It's more complex than this in larger projects, but that's a whole separate topic.