Say a database has a listing of states and abbr. An application is creating invoices. Who 'owns' testing the quality of the data in the database: QA, Application, BA? Would an application test all variations? Would this even be a business test or user acceptance test?
In this case, there are two pieces.
First, there should be documentation somewhere on what the data in the state abbreviation database should look like. Worst case, it's in the code. That's what you write the tests against.
Second, the data you use should be a copy of the production data. You shouldn't be maintaining your own test databases that could diverge from what's in production, you should, on a regular basis, be getting copies (possibly sanitized copies) of the production data, and using that in your testing.
Because it's how the application behaves with the data that's in production that matters. If you have an application that works fine with the test database, but blows up with the data in the production database, you have a failing application in production. I'm sure at that point there would be lots of finger pointing, but it's best to avoid that and just use a copy of the production database.
If the data in the production database needs to be protected/formatted in a specific way, you can always write that into the application, and test that it will reject invalid data, and some databases will let you put constraints on the data format, so you could use that as well, if you want to additionally guarantee data integrity.
This is totally up to the way your org is setup. In general I have seen this belong to the QA team as it is a quality metric. I have also seen separate responsibility to the sales team etc... depending on what database it is being utilized.
In general though QA needs to have tests that verify data integrity throughout the application functionality. Not testing data accuracy, but to be sure that the integrity of the data is consistent with expected behavior despite what functionality is being utilized.
Whoever is performing the testing is responsible for ensuring their test data is correct. This does not mean this person is responsible for ensuring their test data is up to date.
Testing often cares much less about what the data actually is and much more about the families of data. If you're testing $5.43 as a sum, you probably don't also need to test $5.42. You might want to test $999.99 and $1,000.00 to make sure thousands are formatted properly (and that sub-thousand values don't have $,999.99 or something silly like that.) So as long as your test data covers all your test cases, you should be fine.
In terms of states (meaning US states) there's not much difference as far as your system is concerned between Alabama and Wyoming. They're both fields with a long name and a short name. If it works for one, it probably works for them all. Testing the first in the list, last in the list, and one in the middle is probably sufficient. If you've found a bug that says otherwise, add that test case. But you don't need to test all 50 states. And if Guam becomes a state, you probably don't need a new test for it.
As for whether it's QA or BAT, well that depends on who is doing it and why they're doing it. At my firm regression testing is run against a new (within a few days) copy of the production database. If a bug is identified and it's the result of data not being in the test database that covers a case we didn't know, that data gets added to the test database.
Bottom line is, if you want to test against a real dataset, that's fine. It might not catch all the bugs, because there may be families of data that aren't yet in the live data set but could exist later. You want to test those before there's a bug. But just because the data is live doesn't mean it's a RT, BAT, FT or any other capital T-test - what matters is what you're doing and why you're doing it. The data is just, well, data.
It depends on the agreed scope of testing.
If your team has developed the invoicing application and that is the scope of your testing then the QA team does not own the testing the quality of the data in the database (states and abbr). In fact nobody from your project team owns that.
As far as accountability for an error with this data is concerned; the team that did the implementation of state/abbr data should be held responsible.
Because while working on this application for generating invoices; the assumption is that all the data that is being pulled from different sources has been tested and is correct. This assumption should be clearly stated in the project plan/test plan.
Invoices display a lot of data from different tables and sometimes from different databases. As long as that data is pulled and displayed in the invoice; the application is working fine. And if you start testing the source data for everything that is displayed in the invoice then you will increase your scope by many folds. But, in any case if that is defined in the scope of your project and estimates have been provided for the same then it will land in the bucket of QA team to test.
But if the states/abbr related data is displayed on invoices and if you observe that the data related to states and abbr is incorrect then you can share this observation with your PO/PM/QM;and can say it out loud that this issue has a severe impact on generated invoices; and your job is done. But, testing this data is not an obligation for you if not defined in the scope. You are just doing it for value addition. I mean if for the state of "Washington" the abbreviation is mentioned as "XYZ" and it is displaying the same way in your invoice, then your job is done.
After you shared your observation, it's the job of the management to decide what went wrong with that data? Who will fix this issue? Who will test this issue?
Apart from this, if anything else is wrong with the generated invoices (within your scope of testing) , then testing team is accountable for that.
To bring the testing of states and abbreviations testing under your umbrella, the scope needs to be redefined.
Who 'owns' testing the quality of the data in the database: QA, Application, BA? Would an application test all variations? Would this even be a business test or user acceptance test?
Every shop decides how static database content gets tested and who "owns" that testing. For some shops, QA would be the owner. For other shops, the DBAs would own it. In some cases, a script would build and populate the table. The Devs would develop the script and QA would test the script.
Here, the list of states and abbreviations seems to be an integral part of the application system. Thus, I'd expect QA to "test" it in my shop.
If the requirement here is that this be a complete list of States and official Post Office abbreviations, it would likely be sufficient to:
- Ensure that the application uses this table whenever it should
- List and read the table for completeness and correctness
There's likely no need to "test all variations" here. But when in doubt, ask your boss.