I completely disagree.
A good test engineer can perform the same work any business analyst can do AND understand code, write code, and test code.
Drawing from what you wrote, the basis for having a business analyst is to provide insight/knowledge about business needs so developers and testers can deliver value.
Great testers have to understand the business needs, where they come from, what the business is asking for (i.e. what they need vs what they want) and how the business will use the product/feature(s). Why would you need a seperate person to do this same work that a tester can do? Testers should be capable of speaking with the customers, using the software from different customer perspectives, understand how the implementation of the code affects the software and achieves the desired result. Testers communication is critical in helping others understand behavior, reproducability, risk, quality, etc.
When asked to put a team together, I have a limited budget (/head count) so I want to make sure I have as much ROI from each member as possible.
BA = provides user stories and understanding of business needs. Can perform manual testing.
Tester = can provide user stories and understanding of business needs. can perform manual testing, can write automation and should be capable of doing some bug fixes (or pair programming to provide additional value).

When comparing the two it is a no brainer that I would rather use the head count for a tester over a business analyst. In my world of software development, the BA is going the way of the dinosaur...

A very interesting contribution that presents well the perspective of senior test analysts - usefully, I also know business analysis practitioners who are competent with test automation and coding.

I agree with what you're saying - when the tester in question has the skills and experience to cover those tasks - and would counter that any discipline that doesn't adapt will go the way of the dinosaur ... including project managers, testers, developers, business analysts, etc. Anyone who clings desperately to the waterfall big-design-up-front approach, because it has kind of worked for them for years and they're maybe a bit scared of newer ways of working.

It is important to recognise that projects following agile practices still need business analysis, and to a degree it's not important who does the business analysis, provided it's done well.

After all, the vision of the cross-functional team was not to have 'jack of all trades' clones; rather it was -- within the team -- to ensure that all capabilities were covered, and that team members can turn their hands to more than one type of task.

So, of course, depending on the level of expertise required and experience of the people involved, you could have developers who can each competently do the analysis, wire-framing, database design, architecture, coding, graphics manipulation, content authoring, testing (from unit-testing up to full integration/regression/performance testing), documentation, operational readiness assessment, marketing copy-writing, sales and support training, process design, workshop facilitation, budget negotiation, governance, and project management ...

... and often we cannot find enough of these 'masters of all' and/or there is so much work to do that one person cannot possibly be across it all, so it can be more effective to bring together a team of people who are recognised experts in their respective disciplines, who can also contribute in other areas.

Sometimes, especially when the product owner is not 100% present/committed or there are many product managers with competing needs, it really does need a dedicated resource who can work outside the project space, groom the backlog, carry delegated authority to make scope decisions, facilitate and negotiate across all operational and delivery teams ~ and sometimes the best person to do that is an experienced business analyst. But, hey, then I would say that.

Ann I understand where you are coming from (I think) but disagree with some of your comments.

You are assuming that a BA cant code or test. Many of ours in fact do.

I also think there is a good role for a business analyst on an Agile project, depending of course on the project and its needs. Some projects are by nature more complex and require sufficient business understanding and a good BA gat simplify a lot of business complexity for the Team. Example - we worked on a highly complex insurance application. A minor change in the business rules resulted in a radically disproportional amount of business complexity. Did the entire Team need to understand all of this? No. Did a few members of the Team need to understand this particular area, thus allowing others to focus more deeply on some other areas? Absolutely.

I think the idea of cross functional teams is one of the biggest areas of confusion on Agile projects. My interpretation and practice is that it doesn't mean the entire Team all have sufficient skills to do everything. I work on the T-shaped people philosophy (specialising generalists). If a good BA can abstract out a lot of complexity then to me this is a good thing. Alistair Cockburn talks about "distributed cognition" and by this means the knowledge of the project is shared across the Team. I think of it as a giant Venn Diagram. There is some knowledge everyone knows about and is shared. There is knowledge on the edge of this shared pool that only some know. The art is in managing this so that everyone has enough for the Team to perform best and to manage risk of a single point of failure.

I dont tend to take an "absolute" position. If a project requires a level of business understanding and the Team decide it makes sense to have a BA then we have one. If not then we don’t.

I too can see your point Ann. However, as David has also said you are making some assumptions that all testers have the skills to communicate with the business and elicit requirements as well as code. We have BA's who can write test scripts as well as execute them, together with doing some coding.

You have only mentioned the case of requirement gathering, which is not the only skills required by BA's from my experience. They also need to be competent, at the very least, in documenting process and to an extent understand how they can be potentially re-engineered.

And then there is the putting together of business cases, benefits realisation documents and further analytical work within some organisations such as financial model.

Whilst I agree that some testers can provide some of the role of the BA, I wouldnt say that all can.