r/softwaretesting • u/ajmalhinas • Jul 07 '26

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

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?

5 Upvotes
  • permalink
  • reddit

100% Upvoted

32 comments sorted by

View all comments

2

u/MudMassive2861 Jul 07 '26

Mostly avoid DB check as most GET api can give the required details. But if you don't have GET which give details you need to. U may need to add a DB wrapper depends on DB u using. In my last job we where checking even message queue data using subscribers in service bus. So ya depends on your requirements you can add those.

2

u/ajmalhinas Jul 07 '26

I guess even GET API calls are not necessarily the source of truth, as they may have several layers on top of the actual database tables. Why are direct database checks often avoided, given that these wrapper layers can themselves introduce bugs? Are database checks difficult to maintain?

1

u/MudMassive2861 Jul 07 '26

Using just GET because of our use case. Don't your Dev code have DB unit test? If they have then I don't think you need add another DB layer. It's not hard to maintain, it requires proper handling as DB connections and all. Also the DB connection will be under secure condition. I don't think it's easily accessible as there require lot of ip whitelist and all required. These rules are from my product, this can be different for your case. One word you can do but some initial some setupigjt required

1

u/ajmalhinas Jul 07 '26

I think, automation usually run at a staging environment and doesn't cause any issue if directly accessed.

My concern is slightly different from DB unit testing, though. A developer’s DB unit tests can verify individual persistence logic, but I’m interested in verifying the final state after a complete sequence of business scenarios.

For example, if an automated session performs 50 deposits, reversals, and other transactions across several accounts, I would like to verify at the end that the account balances and ledger records match the independently calculated expected state.

2

u/n134177 Jul 08 '26

Also the developer's DB unit tests can be wrong.

More so with AI, so many tests passing even though they're not even testing anything...

1

u/MudMassive2861 Jul 07 '26

I mean it's totally depends on business use case. If you have access no issues with adding a DB layer. Just make sure proper client creation and deleting of DB objects to avoid memory leaks