When evaluating the capabilities of an application to read metadata, it’s useful to have a test file that has a lot of metadata filled out. This can tell you which fields the application reads.
I’ve created a test file, and I’m linking it here. To use the file, just download, unzip, and load the file into the application you want to test. If there is a metadata display in the application, you should be able to see the tags.
All applications will only show you a subset of all metadata fields. There are simply too many, created for too many purposes, to be universally supported. The test file has an entry in all fields that are currently supported by Photoshop, which is a pretty good benchmark.
Sometimes a metadata field will be indexed by an application, but not easily displayed. (It’s easier to index all the metadata, including little-used fields, than it is to build a comprehensive user interface for all fields.) To get around this, I’ve put a “code” into the tags, wherever possible. I’ve added a short string of letters and numbers to each tag which should make the search a lot easier than simply adding the name of the field.
Having a metadata test file is also useful for troubleshooting. I remember back in Bridge CS5 (I think), the labelling of certain metadata fields was incorrect and Bridge would write to the wrong XMP elements in the file. As a result, when my DAM would read the XMP on ingest and display the metadata to my users, my users complained that the DAM was buggy. Using a metadata test file, I was able to convince my users of what was happening — they really didn’t want to believe that it was an Adobe issue, they preferred it to be the DAM’s fault until the saw the results of the metadata test file. Adobe came out with a fix one or two versions later.