This was one of my major roles in a previous job. I worked for one of the sectorial utility regulators in the UK, and we collected a lot of data from external companies. Data quality was a chain, starting with the companies and arrangements for validating and confirming data collection methodologies, then the development, testing and deployment of the data collection tool (this was where I got into software testing), analysis and querying of the data return from the companies, data wrangling with a managed process to edit or amend data, and finally reflecting data changes in updates to the requirements for data collection and the spec for the next year’s data capture system.
This was mainly a manual system, because we were dealing with manual data collection in the real world (and because we are talking about the middle 1990s…). I ended up in this role because my managers felt I had the necessary attention to detail and similar skills that suited the role. It wasn’t deliberately created as a “dual role” with either testing or “day-to-day QA” (such as proof-reading reports, ensuring data quality and maintaining data validation audit trails from raw data to capture systems to databases to data extraction to reports; my strength in particular was reconciling “text to tables” - making certain that publicly-quoted headline numbers were consistent between report texts, press notices, keynote speeches and presentations, and the actual published data tables in the body of reports); but the role evolved into just that many-headed beast.
I wouldn’t say I was a “specialist” in this sort of thing when I started; but fifteen years later I certainly was! (Though that had its own set of pluses and minuses…)