I always hear that a user story should be very short and clear, so it can be written on a note etc. Like "As a user, I want to be able to enter, modify and delete people in the directory".
But for testing, we need to know:
How is this solved in Scrum?
This is typically facilitated by a common Definition of Done that every scrum team member must agree upon before commiting.
User story acceptance criteria should clarify all requirements involved in the user story. Such criteria need to be easily verifiable by Product Owner to allow for user story completion (e.g. how many characters you could type in the text field). Everyone in the team needs to understand what has to be done, but during a Scrum event meeting you may simply use user story title only.
Put technical stuff into tasks (e.g. db field size for storing strings, other technical assumptions, etc.) and do not disturb product owner and QA guys with that.
The idea in SCRUM/Agile is to focus on Business Value of the features you are written and not get lost in detailed implementation details before the story even begins. So the advise is to keep the story information as short as possible. But when the story gets developed, the dev team will create/discover some functional/technical limitation and will check with Product Owner if they are OK, and will document them in whatever system you use to track your stories (another post-it note, or a comment in Jira). Then, as a tester you will have more information to check the boundaries/range for example. Now some other informations like "validation message" could be left to common sense. Do you really want specifications on that? If that make sens for dev and, as a tester, you find the message OK, then you are done OK.
They will be part of acceptance criteria. You should probably have PO answer these questions
