User acceptance test (UAT) criteria (in agile software development)
are usually created by business customers and expressed in a business
domain language
https://en.wikipedia.org/wiki/Acceptance_testing
I don't think Field Length Validation has anything to do with User acceptance testing. Maybe the business should write their own tests.
Never the less here are some testing pointers and ideas:
Map how the data is used. Don't forget to test locations where the data is used, test the new length is used properly. For example in reports. E.g. don't only test that the input and storage works.
For example:
- Does the address still fit the plastic envelope window in traditional letters used for sending invoices?
- Are API based on this data still backward-compatible?
Make a shared list of test heuristics how your team should test input fields.
Personally, I don't like to limit input fields. Challenge why does it now go from 40 to 60? What is the chance next week it needs to be 80? I have seen street names/city names that are way longer than 60.
Company names of 1000 characters? You are making this stuff up, because company names are never so long, at least not that I can find. Maybe also test the requirements up-front, instead of after they are implemented.
Other reads: