Well Jeff there is referring to static data. Do you know if the data in that table is static data or is it dynamic data?
Comparing data in QA to Production shouldn't be a thing ideally as you should be scrubbing anything which could be a data breach violation from the database prior to moving it to QA/UAT/DEV/TEST, as your opening yourself up for data breaches, HIPPA GDPR violations etc.
So anything names, addresses, emails, phone numbers, zip codes, anything which can personally identify anybody should be scrubbed to test data prior to moving to lower environments, so you cannot compare your customer table in QA to the customer table in production as the data wouldn't be a match as an example.
Also as the data drifts through regular QA routines again the data in these dynamic tables will not match your production databases, so you should really not compare QA to Production in terms of data, unless you have a solid data dictionary which details what table stores what information and if that table is static / configuration data or if it is tied to the daily OLTP processes etc.
Comparing the schema on the other hand is totally OK as yes you could end up with schema drift should the deployments be manual or something hasn't made its way to production yet, but schema <> data so yeah schema is OK, data is generally not OK unless you know the data.