Congratulations on your first database. I hope you had fun creating it. I'm sure it's the first of many great creations.
However I'd like to suggest that outside testers might not be your best next step. While a professional reviewer might give you some good tips about architecture or general interface design, the best testers in the world are your users. For example, as an outsider I could look at your database and decide that some process or arrangement of data didn't make sense to me. But your users, who are familiar with the subject matter and perhaps the creators (or at least modifiers) of your company's business practices, might immediately recognize the same arrangement as natural and helpful.
You're about to take the leap that all professional developers have to take at some point: shrug off the burden of thinking that the database must be perfect before users see it. You need them to see it early and often so you can incorporate their feedback into the design as structure and not as veneer. That doesn't mean you release it to everyone. Ideally you can pick a group of testers who can give you feedback and let you know how well your database works. Then you can cycle through the development/testing/feedback process until it's refined enough to be of use.
It won't be perfect at that stage (it may never be) even with lots of user feedback. When you invite your users into the development process they ultimately have more confidence in the database because they've been a part of it. You may also feel more free if you start thinking about your database as a living breathing entity that will grow and change as your business grows and changes. I still work on the first database I ever created. Work has slowed over the years, but it's changed for many reasons: change in government rules, change in users need, improvement in my skills.
Ask me how I know about what happens when you don't get user feedback: that very first database was managed by a person who believed in telling users what they needed. There was near rebellion when we held the first training classes because the team never bothered to find out what the users needed. We managed to salvage the project, but it took some bruising meetings to get there.
None of this is to suggest that you wouldn't get good feedback from outsiders about technique. But it won't be the same feedback you'd get from your users.
Hope this helps,
Co-author of O'Reilly's FileMaker Pro 12: The Missing Manual
Rule 1 of testing:
Developers make lousy testers.
There are a variety of reasons for this. First, we know what the expected inputs and expected outputs should be. So we're very good at teasing out wrong behavior when the outputs are correct. But we stink at predicting what unexpected inputs users might come up with. (At least until we've had many years under our belts, and even then, it can be tough.) "Why the heck would someone do THAT?" is a common question many developers have asked themselves. You will too.
Second, unless we're intimately familiar with the workflow and the day-to-day of how the users do their business, just like Susan said, we tend to build systems the way we think the work ought to be done, not necessarily the way the users will want to do it. I can't count the number of times I built something, watched a user try to use it, and thought, "Wow. That doesn't work the way I thought it would." So humility is an important character trait.
Third, there will be other issues. There's adaptive maintenance - changing conditions, as Susan alluded to, that will cause the database to change. New users who aren't familiar with it, and who might bring different expectations. New feature sets will often confuse users initially. And your skills will improve as you learn new techniques. So yes, no data system is ever truly "finished". It's a case of continuous improvement. Relax and enjoy the ride.