My experience, and I do a lot of tape cases ...
The majority of issues have nothing to do with NBU - country to popular belief, NBU does not write or read to the tape, it's all done by the OS - at a high level, all NBU does is send data to the OS and request it is written to the tape a specified blocksize. Aside of that we do send various scsi commands, but again, these are an ‘industry standard’ and nothing to do with NBU, There are exceptions however ... I had a odd one a while back where it was actually something corrupted in the storage unit, recreating the STU fixed the issue ... There has also been a recent issue with WORM tape (LTO8 and above I think) which was a code issue.
WIth all due respect to vendors, they run a standard set of tests, if these don’t test the part where it is failing, they pass the drive as good - this tends to happen for the more unusal cases, as opposed to a simple write failure due to a drive fault or something, I have lost count of the number of times the vendor has blamed NBU, and it turns out to be hardware - it seems to be their standard response.
NBU config issues can cause issues, I would expect these to cause failure at the start of the job - but if your setup isn't that complex just delete the drives/ robot and reconfigure (nbemmcmd -deletealldevices -allrecords) - it may not fix it, but it does prove as much as we can that the config is good - all often, this is enough to rule out NBU as being part of the issue.
Activty monitor / job details is where I would start - this may well show the error, or at least whereabouts in the job it is failing. Is it always failing is the same place, is it always failing on the same few tapes, what is the frequency of failure, what status codes do you see, is it always in the write (or read part of the job), is the tape even making it as far as the drive (robot load error) or if it is, is it mounting correctly (tape physically in drive does not equal correctly mounted, several other things have to happen).
What does bptm log show (I'll upset Marianne, but I like VERBOSE = 5. The messages log could be good as well, if you see TAPEALERT, ASC/ ASCQ, ioctl or CRC errors, you're almost 100% certain to have a hardware issue.
In fact, set up the volmgr logs as per this article, include the various ‘touch files’
https://vox.veritas.com/t5/Articles/Quick-Guide-to-Setting-up-logs-in-NetBackup/ta-p/811951
Half the battle with these issues is confirming where about some the failure is ... and the history behind the issue - when did it start, where there any changes (eg firmware).
Linux is great, as we have quite a few ‘tools’ to test tape drives, tar, dd, cpio, mt, sg3_utils (optional package but certainly worth installing), scsi_command (ok, this one is Veritas, but is NOT anything to do with NBU), mtx and probably others I can’t think of right now. Tape should be massively reliable (in fact, more so than disk) but tapes can be damaged, drives and tapes wear out over time so Simon makes some good points, although a leader pin issue is rare, I've seen it once in 17 years. On the media server(s) , the /use/opens/net backup/db/media/errors files can be useful, and will also show if it's the same few tapes causing the issue.