As someone who has built relationships with labs to the point where I had "special privileges" the most important thing you can do is:

Make your test setup as easy as possible.

To expand on that:

1) Realise that you're mostly working with testing technicians NOT engineers. They see all sorts of weird and wild stuff. They often have to parse poorly written and complicated manuals written by engineers who don't have a clue about writing manuals and make poor implicit assumptions about the "target audience".

2) It's frankly, often soul destroying work (hence the churn, especially at the bigger labs). They use the crappy manuals for crappy products (but everyone thinks their product is the bees knees) try and set it all up. Then it doesn't work. Or it fails because the customer didn't do any pre-compliance work and was "hoping it would just pass". Well time is money, now they have to break the setup down because they've wasted 1 hour on the phone to some engineer who doesn't know what's wrong and is trying to trouble shoot through the phone. Now they get to do ALL that again with one else's crappy product.

So how do you make it as easy as possible for them?

1) Your setup should be plug and play and I mean TRULY plug and play. No manual should be required for putting the device into some hacky test state. Get the software engineers to automate it.

Does a button need pushing? Automate it or just remove the requirement somehow.

Does it need wiring up? Nail it all down on a giant piece of ply wood. Zip tie down all the cables. All the dummy loads. Any other devices. The only thing they should need to connect is the power cable.

Does a laptop need to drive it? Automate everything on there. ONE SCRIPT, maybe a menu in there depending on what test they are running. Make the laptop bullet proof. Get a nice laptop that boots and runs fast (not the one at the bottom of the IT donor pile). Give them a mouse to use.

Remove ALL of these barriers. AUTOMATE it ALL. Don't require them to baby sit it. That's a waste of their time.

PLUG AND PLAY.

2) Make it easy for a technician to see if and when the device is working VS it's not working. Don't give them instructions on "open this menu, do this, do that ..." no.

Put a red LED on it and a green one. Don't have one in your product? Be creative, Retrofit something. Have a special test UX on the device. Hell you should have special test firmware as a reference point.

They should be able to, at a single glance, look at the product and know: "Is it still working/running?"

So now imagine you have done all of that effort. Now put yourself in the shoes of that technician. One of the test stands is available early because a crappy product failed. They gaze towards the giant pile of crap they have to get through. Many are a a giant plastic box with tangles of cable, hand written crappy instructions, an IBM thinkpad from 1995 to drive it, no labels on any of the cables ....

... but amongst it they see your PLUG AND PLAY testable product. It's all mounted on a plywood stand, ready to go. There is almost a light from heaven illuminating it, it's so beautiful, it's so easy throw on a test stand and GO (and then do something else).

Guess which one is jumping the queue and going on that test stand? (And time is money remember. A test stand not testing is loosing money).