We have a simple CRUD application.  QA has a test script where they are doing the following:Call Create Customer serviceQuery the database for the newly created CustomerVerify the Customer in the database matches the expected resultCall the Get Customer serviceVerify that the Customer returned from the services matches the expected resultMy question is: should be QA even be running steps 2 and 3?  Or should they be agnostic to how the data is stored and just validate the application output (run steps 1, 4, 5).On the one hand, it would be good to check that we are saving data correctly to the database (especially if we are saving in calculations, foreign keys, generating timestamps, etc.).On the other hand, QA shouldn't care how/where we are storing data, as long as it is returned correctly from the application.
Should QA be agnostic to how data is being stored?
testing;integration tests;qa
In my experience, it isn't unusual for QA to carry out these kinds of tests. The priority of course is to check basic behaviour (black box tests). As an extra sense check, you may want to check the system internals (white box tests). Steps 2 & 3 would fall into the white box testing category.I don't know how your system is structured but it is possible to imagine a scenario where data is cached in some kind of mid-tier. If the database wasn't checked, tests 1, 4 & 5 would pass with flying colours but if the mid-tier were re-started, those tests could fail. Also, if the test script contained static data to be submitted, you couldn't be sure this wasn't hard coded into the application somewhere.You can also spot potential sources of bugs by comparing the submitted data to the saved and retrieved data. If the submitted and retrieved data are the same but the saved data in the database is different, it may be worth doing some additional testing to ensure all conversions for the value in question are carried out correctly. A system I worked on had an issue handling gender. A dropdown in the application had M(ale), F(emale) & U(nknown), but only M, F or space was stored in the database. On further inspection, other parts of the system used a variety of strings to represent blank such as unspecified, not known etc. This is something we wouldn't have found if we hadn't checked the database.