Welcome to SQA, FJFG. As Bruce McLeod once wrote, "There are no 'best practices', there are only good practices in context." A good practice for you will depend upon your context. I will suggest some contextual considerations. You may be aware of others.
Your primary job, or at least your initial job, is to own and convey business requirements. Those requirements have an audience, and you try to tailor how you write the requirements to maximize the chances that your audience will share your vision.
Only you and your testers can determine how much detail you need to convey in order for them to do their jobs. If you trust each other, and if each of you listens and communicates carefully, and if all of you are skilled at your jobs, a lot can be left unsaid. In other words, it may be possible for you to focus on business requirements and for your testers to interpret those requirements from the perspective of testing. On the other hand, if there is a lack of trust, skill, or listening, you and your testers may need to spend more time in explicit communication. In other words, your testers may need to ask you for clarification around requirements and/or you may need to be more explicit about test cases.
A potential disadvantage of your providing explicit test cases is that your testers may not perceive the need to think about test cases for themselves. If you are comfortable with asking your testers to be button pushers and mouse clickers who follow a pre-determined script, that may be a appropriate. There is a time and a place for that kind of role. On the other hand, if you want your testers to think for themselves, diagnose problems, and question assumptions, then providing a lot of explicit test cases could put you at cross-purposes.
One alternative to writing explicit test cases is to review and provide feedback on the tester's written test cases. This will give the testers an opportunity to be better testers, and will give you an opportunity to be a better business analyst.
Regarding what an agile process requires in terms of test materials, that is really up to you. An agile process emphasizes communication over fixed processes. No one outside your organization can tell you what you must or must not do in order to be agile. I suggest trying something, paying attention to what happens, and then adjusting accordingly.