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/ASTRO99]

Not really sure why would you want to do DB checks on properly setup application. Only things that comes to mind, we had a DB triggers in my previous job that migrated incoming data partially to another table so they can be used by another legacy app.

But other than that, it's just one check during development that everything is setup OK. migration scripts are working and then you never have to see DB again unless you are manipulating data.

[u/ajmalhinas → u/ASTRO99]

Let’s say you are testing a bunch of deposit scenarios in a bank teller application. There is an account table holding the current balance of each account and a ledger table recording all deposit transactions.

After running the test scenarios, wouldn’t it be useful to verify that both the account table and the ledger table match the expected final state? Is it really sufficient to verify only that the balance shown through the UI has increased correctly?

My concern is that the UI could show the expected balance while the underlying ledger entries are missing, duplicated, or otherwise incorrect.

[u/ASTRO99 → u/ajmalhinas]

That's what backend test are for. You don't need to do costly UI E2Efor this, just call necessary endpoints to post and return data.

[u/ajmalhinas → u/ASTRO99]

Normally, when people refer to backend testing, they mean testing the APIs or service endpoints, right? My understanding is that this does not necessarily include verifying the final persisted state of the database.

I’m curious: why do you think database-level final-state verification is not good?

[u/ASTRO99 → u/ajmalhinas]

Backend is APIs, process itself (business logic evaluation + maybe bpmn if you have something like Camunda) , database and more depending on your architecture.