We are starting from scratch on how to get better visibility of how and what our software suppliers are actually testing and the governance around that process. Would welcome any input or examples of what has worked. No point in reinventing the wheel
You can request the supplier to share their test documents like Test scenarios, Test Cases, use Cases which they used while testing. By reviewing these documents, you can understand how much the testers have tested or going to test.
You may also request automation scripts if you have any technical person to review them. You may ask for results of the tests conducted.
Talking to the Tester regularly will help you to understand how much testing is done and on what grounds. Also, your feedback to the tester about the software application will surely help the tester to explore more test scenarios.
This is a common practice. Many customers audit their suppliers processes and quality standards. Though this is usually done whilst selecting suppliers.
I've been on both sides of the fence where the team I am working have audited a supplier and the company I've worked for has been audited.
When this has happened to me, I've been expected to demonstrate that I adhere to my company's quality procedures. I maintain my tests in a controlled fashion and the tests offer value.
It's not unreasonable to ask what tests your supplier runs. You expect to see developers continually running unit tests. You would also expect that you supplier has tested before releasing to you.
In terms of reducing testing effort on your part, my opinion is that you should still test the software and the users should run UAT.
Your supplier will be focused on system tests, whereas your organisation ought to test and the users are concerned with making sure the software meets their business needs.
For example, one of the projects I am working now, the vendor tests the software and share the tests. I have written my own functional tests whereby I check each option works. By this point, the expectation is that during UAT, our users will not suffer from frustrating crashes, broken links etc. This leaves them to focus on solely making sure the software meets their needs.
Where software is bug-ridden and/or crashes a lot, you find they very quickly lose interest and can disengage. This happens as users have to stop doing their 'day job' to run UAT and when they make time, they get frustrated when things don't work.
Just to throw in my two cents and add to the existing answers - you can (and definitely should) ask for proof of testing, but they might not be contractually obligated to share that information.
Alternatively, you might get lucky and have some really open and honest suppliers who don't mind airing their dirty laundry.
I've seen it both ways, when asking for the exact same thing. We suggested they host daily stand-ups, share defect logs, generate spreadsheets, etc. and one company didn't share anything, whilst the other shared absolutely everything.
I like checklists. Because you can see all actions that testers do from their side of work. And as a developer, checklists can give you an extra information. Like, if you have columns with modules or integration - an aggregation of major code parts. So developer can see as a white box inspector which buggy module can influence other modules.
Any company I worked, they used some kind of variations of this checklist template. I add some of my new ideas (with module and integration). Quality control and inspection plan
The other way of ensuring it to ask for module wise test results on daily basis, be it an automation test reports in simple email format or a spreadsheet with daily test round report, you can have an independent testing team/organization that can help you understand , what has been done in a testing point of view for testing of product, or if the company is open, you could ask them to share document covering test scenarios, test case, and RTM, but for this some companies might bill you extra charges.