I know that usually BA's and Testers are different people and have a different role. I sometimes also deal with BA's who don't like testing. However in most projects, I have always tried to make the BA the tester or one of the testers of the system. It only makes sense. The BA is the one who writes the requirements based upon his interpretation of the what is required. If lucky, the BA is doing much of the design as well.
Having the BA doing the testing, you remove one level of the indirection and at least get something close to what the BA had envisaged. Because the BA was the person who dealt with the source of the requirements, it is the best you can get.
Of course, intensive testing involvement by the key business users will give even a better result. However you should never only rely on them because there the risk is too high they only do it superficially and won't go through all the scenarios you will encounter during normal business use. Specialist testers in combination with the original BA(s) and end users will give in my opinion the best results. And yes, testers should be involved in early stages of the requirements and design.
I found that I achieved my best results with my super coordinators (I called them Service Delivery Managers) who play a mixed analyst, design, project coordinator and testing role during the project where they work closely with dedicated BA's for requirements, design and testing. Those people are then also fantastic to help out with the business roll out and assist business users with their normal day use. (see also "Why Business Requirements don't work")
Besides this, you'll be doing the BA a favour to make them participate in testing. This way the BA gets direct feedback of how well he has done his requirements and design work. If a BA would only be involved in the early stages of a project and never is actively involved in the outcome, the will not know if he has done a good job or not. Testing makes a BA a better BA!
