The days where the software tester only found out about a product after it had been planned out by a business analyst or, even worse, after it had been developed, are almost a thing of the past; I say almost, as there is always at least one company out there living in the dark ages!
Historically, software testers had never been involved in a products lifecycle until it was in development and they were handed a document to write their test cases from. With agile not just being a buzz word anymore, but a way of life, a testers input into any part of a product is insightful and necessary and should occur right from the inception. What a tester has that developers of larger teams don’t have, is an overall picture of how everything fits & works together and a knack for looking at the bigger picture from a users perspective. They know the pitfalls, the code that doesn’t like other code (products that don’t get along).
Including a software tester at the product ideas stage means that you will already be thinking about all of the pitfalls & potential blockers before they even happen. Testers have an ability to think outside the box. They constantly think about boundaries. They have methods for breaking products that others in the team may not be aware of.
I have worked with very clever developers who are also good at testing, but they never truly nail the latter. Generally, testers have more ideas than most on how to thoroughly test a project.
Writing the acceptance criteria without a tester present is like writing half a shopping list. You will have to return to the store for the other items you didn’t write down and in the case of acceptance criteria, there may be a need to return and write more code; It is not good to find this out when the release date is imminent. Better to find out before you have even started writing code.
And after all, the whole concept of being Agile is full inclusion which allows for better efficiency and more predictability of when something will actually be ready to release.