In my honest opinion, it is best to test the app on a set of actual to-be users. This must be backed by administration. On the other hand, if the corporate mechanics are in they way, I'd personally find a to-be user and befriend him/her to do it on I-scratch-your-back-you-scratch-mine basis.
In any case, the tester must be familiar with the business logic and other specifics of the company/group-definition, thus you can't just put any random person to test the app. That would work only for user friendliness when the users are general public, but on a specific group of people you really need a real to-be user.
You'd be missing a number of factors if you don't use the representative group:
- Business logic specific important parts of the software won't be noticeable to normal users. Some parts will be used extensively by the real users and will need simplification and additional UI elements to ease the use, regular users won't notice the needed change because they don't know how much they would use the particular interface.
- For the same reason, will get better feedback from real users to change some specific parts, which in turn will let you know what you will need to focus on more.
- That feedback in return will also allow you to familiarize yourself more with business logic and day to day activity from the user, which will lead to a better software in the end.
I highly doubt that any usability issues uncovered by the "off the street" user will hold much value to the real users. At most it will change some few minor issues, but they won't uncover the real headaches that will come in production. "off the street" users will uncover some facts and you'd be happy fixing them, and you'd feel accomplishment which goes to waste when it comes to production.
But you know, I'm just basing this on my own experience.
Background: inner corporate application development.