Do you notice the MORE? It means that they studied something! I always
explain that the test is about the system, not about the user, but it
doesn't solve the problem.
"Usability Testing" is, in itself, actually terrible UX when presented as such.
Do you have this same problem? How can I ease the minds of my testers?
Should I explain more, use another name for the test, or something
Go back to basic UX principles. The very first step: stop thinking about these people as "testers." Your context to their activity is they are helping you [usability] test your software. That is not a familiar context to them, not a context or role they would perceive themselves in or desire to be in normally, nor possibly one that even makes sense to many of them ("usability" is essentially a technical term, even to the point of being jargon, despite being based in a standard english word). A paid software tester is a "tester." Someone else is just trying to do their job/complete their task while being asked to additionally do something for you too, now. From your perspective these may be one and the same and redundant, but that can appear very differently from other viewpoints.
Communication is key here: you need to make sure you are appropriately conveying what will be involved in the activity and what is expected of them, as well as what they can expect and can expect to be doing. I think @dennislees has a completely valid point in referring to Hawthorne, but I think this actually goes even further.
You need to re-home this into an appropriate context for them when you present it to them even if internally you continue to refer to it as it pertains to your own context (usability testing).
What are they here to do? Not in terms of what you want them to do, but in terms of how the activity will play out to them?
Evaluate is a good term.
Feedback is also fairly good.
They are here to
help you, but it's important to not bog down on what that means to you (which is more where you're currently at). Focus on the things they will be doing and can do that will be helpful. People who are actually eager to help (this essentially goes back to the Hawthorne effect) often try to anticipate needs, which can be problematic both in terms of being a stressor on them as well as not always fitting well with your actual goals.
Also focus on the state of mind you want them to be in when doing this.
Play with may even be an appropriate phrasing (perhaps backed with other language to still indicate the need for feedback and what the feedback should pertain to) in order to alleviate any sense of stress.
Are you going to have them do a standard activity with your (new/update) software, as opposed to their normal software (or your current version)? In that case, focus on the activity.
We'd like to present you with a special opportunity to run a print job
on our latest software—before it's widely released! All we're asking
for from you is if you could please take the time to give us some
feedback on how you feel about our new file uploader. This is simply answering three quick questions and should add
on no more than two minutes to your normal print job processing
time. If you have some time to answer some other quick questions—or if
you have any other thoughts on what you'd like to see improved, or
anything you found frustrating—that would be great too!
(note: this is just a quick jot to serve as a showcase)
This sets some clear expectations: they're just going to be doing something they've already done and are familiar with, it's just going to be in a new version of the software. It also sets a single specific feedback goal as an "exchange" task (evaluating the "file uploader" specifically, not the software overall: this could be set differently on different sample populations). This helps initially limit scope so there is a basic focus to work from, and so that the expectation of the task size is clear. It also implicitly cues that the changes are mostly related to the "file uploader", in this case (even if there are other changes), which helps reduce fear that the overall changes to the software will be too overwhelming and make it too unfamiliar to comfortably perform the usual task in the usually expected manner/time frame.
It even includes some time information so that no one is concerned that they're being asked to devote an indefinite amount of time. Indefinites are one of the worst things to build into a task expectation, in terms of lowering desire to commit to it. The more you can solidify expectations of the task activity and surrounding parameters/needs, the more comfortable it is to commit to performing it.
Note that I don't say "test" anywhere in that example. They are not "testing:" they are running a real print job. If this is not the case, you will need to clearly call that out, such as referring to it as a "mock" print job, but I generally would recommend trying to fold this into a working process model.
You can also toss in verbiage on how all of this is to help them (set another reason for why they might want to take the extra time this involves over their normal procedure), but you don't want to make it too long in the process.
Steve Krug's usability script as linked by @dennislees is a great example, but I think it's important to understand why it is presented in the way it is. This all comes back to perspective and context, as well as appropriate language/communication choices. It can be fine to use industry standard terminology, so long as it is industry standard terminology to the people you are communicating with.
You may want to consider usability testing your usability testing communications. While I say this somewhat teasingly for the way it may sound seemingly redundant, it's not a bad thing to at least run such verbiage through someone who does professional copy editing on material that's published to the general public or, more specifically, your intended audience.