Many memory test programs are designed to maximize the probability of finding a problem in a certain number of testing steps, and are not at all optimal for diagnosing what the problem might be. A memory test is unlikely to pass unless (1) all write operations to each location store the correct data, (2) all locations continue to hold the last stored data, ignoring reads and writes of other locations, and (3) all read operations read the correct data. Memory tests will detect failures in any of the above steps, but are often not particularly well designed for determining which step failed (If the program stores 0x1234 to 0xABCD but read back 0x89AB, it's possible that address 0xABCD didn't get 0x1234 written to it, or that the correct data was stored to the correct place but subsequently overwritten, or that the correct data was stored--and is still stored--in the correct place, but the read operation doesn't correctly fetch it).
To diagnose a problem given nothing but a list of mismatches between expected and read-back values, one would have to know the sequence of read and write operations used for a test, to see if the mismatch conditions fit any sort of pattern (e.g. if there is a hold time violation on write cycle data, one might notice that the only errors occur when two consecutive write operations are performed and at least some bits are "1" in the first write and "0" in the second; all observed errors bits in the first-written value reading "0" when they should read "1"). Merely knowing an address where a read-back failure was detected, the expected data, and the actual data, won't help much if one doesn't know what other operations were performed at similar addresses.