Do these SNMPv3 credentials work via SNMPwalk from poller? If not, are you seeing any log entries indicating an issue?
Also, from my experience, valid credentials seemed never to work after the first click of the 'TEST' button. I don't believe additional tests accomplish anything. Seems I always had to navigate away from page and retry. Can anyone confirm?
I use NCM and NPM to manage those same brand/model switches via snmp-v3 successfully, so you should be able to as well. We retired all the 15.0 code due to security vulnerabilities or bugs; it's always possible you've got a Cisco bug that's preventing something from working correctly with your snmp-v3 deployment, and I'll assume you've investigated this (possibly with TAC?) and eliminated it as a possibility.
I'd bet there's a typo somewhere, some difference between what your switches are configured to accept and what you've set your Orion product to use for them.
Go through and compare them with a fine-toothed comb; if you find that tiny difference and correct it, you'll be all set.
Also, for your security policy, seek advice about using snmp read-write strings. NPM and NCM can do all the work I need for 47,000 devices without requiring snmp read-write privileges, and that helps reduce the exposure of not knowing who issued what command (via NPM or NCM) that may have made a change via snmp-v3 that ended up causing problems. It's enough for those products to have read-only access--for my environment.
Instead of using snmp-v3 read-write credentials to make changes to your switches and routers, you could leverage an Active Directory service account for NCM, and then let NCM manage those devices via SSH v2. Better still, use TACACS and you'll have a complete history of who logged into the device, whether they had permission to issue a given command, what that command was, and when they did it. AAA provides all that info, plus Orion tracks who told it to issue that command via the service account.
If you have serious need to use snmp-v3 for read-write purposes, OK. Just make sure you have great tracking on it, so you're not surprised unpleasantly when it's used to make configuration changes that might have negative results.
As folks are pointing out, using both read and read/write can confound your troubleshooting efforts. Get one working and determine what the issue was (remove the other from the credentials for the node). Potentially same issue affecting the other. They would both have to be right for the test button to pass. I can see read/write being useful if you have Engineer's Toolset and the nature of your issue precludes SSH access. It can be used to regain SSH access, or to make config changes that need to be made until SSH access is possible. But perhaps not ideal for normal operations.