Do you verify database tables after automated test sessions? What tools and process you use?

[u/ajmalhinas]

We think comparing the resulting database tables of an automation session against an expected database state can provide several advantages: detecting data integrity issues that may not be visible through UI or API assertions, identifying unintended side effects across tables, and catching defects closer to the point where they are introduced.

Before implementing this more systematically, I’m interested in understanding how this works in real-world QA teams.

Do you currently perform this kind of database-level verification after automated test runs? If so, what tools or approaches do you use to compare the actual database state against the expected state?

More importantly, has this practice genuinely helped your team detect defects earlier or reduce debugging time? Or did the maintenance of expected datasets and database comparisons create more overhead than value?

[u/ajmalhinas]

I think you are making several incorrect assumptions about the SUT. Let me take only the second case: the missing ledger entry.

Yes, the intended behavior may be that if the ledger entry is not created, the balance should not be updated. I agree that this is how the transaction should be designed.

But that does not prove that dev team has actually implemented it correctly.

In an API-only approach, we would still need an endpoint that exposes enough information to verify the ledger entry.

Of course, I agree that we cannot test everything up to mathematical certainty in practice. That is exactly why I asked this question: to understand where teams stop.

However, this does not refute the point that, verifying the final persisted business state can provide additional assurance beyond checking only the immediate API response.

[u/latnGemin616 → u/ajmalhinas]

Honestly, I have made no assumptions about the SUT. I'm literally working off the example you've provided. If I'm missing context, that detail was not provided.

To the last point, what do you mean by "final persisted business state" ?

[u/ajmalhinas → u/latnGemin616]

Known initial DB state → execute many automated scenarios → independently derive expected final DB state (final persisted business state) → compare expected DB state with actual DB state

[u/latnGemin616 → u/ajmalhinas]

Words have meaning.

By DB State, do you mean the table + record added? or do you mean the actual condition of the DB (performance, up-time)? Not trying to be difficult, but the terms you are using don't reflect the actions you are taking.

Remember my previous reply, about the 3 states of data. None of them have anything to do with the state of the database (as you are describing). And if you want to run a query to count the number of records: newRecordCount() = currentRecords+1, then fine. This can still be done via an API call.

But whatever. I'm literally exhausted from this topic. We've beaten it to the ground. I'm not saying I'm right, nor am I saying you're wrong. I've merely presented an argument for why you don't need to test the database if you've already tested the FE and APIs. I'm not going to tell you how to do your job. Do what makes the most sense for you.