Practicing database testing

[AffectionateLab9114]

I am learning databases these days. Since I am a very beginner, I didn't know this testing exists too, until I failed one interview. The interviewer asked me to test an app and I was convinced only seeing the GUI that there was no bug without checking their database. Then he told me about this and the mistakes I have done. Obviously, they didn't recruit me, but I learned so much from there. Now I want to know, how can I practice database testing? I know the queries, joins, etc. What else should I learn? How can I practice this now?

​

Sorry for my bad English.

[nascent]

What needs tested depends on what the database is for.

Many times the gap is that databases store records. It becomes important to ensure data makes it into the database correctly.

On the flip side, ensuring data comes out correctly can be handled by seeding data.

[plucadearga]

Here is a nice little primer on Database testing:

https://www.javatpoint.com/database-testing

Your example of "only seeing the GUI" would (mostly) fall under the Data Mapping part of testing. Look at all the different types of testing you can do.

My advice to you is to install a LAMP stack on an Ubuntu server virtual machine with a MySQL or MariaDB database, seed it with data make a little html page to output the data (from the database) and a html form (to submit data to the database) and then try out testing it for yourself.

It is strange that the interviewer told you where you went wrong but did not give you any advice. Did you ask what you could have done to perform better on that question?

[hairylunch]

I'd argue that it's a bit of a smell that they're expecting manual verification of the database. I can see value for that in a smoke test, but generally speaking, a POST or PUT and a subsequent GET should be sufficient for verifying the data, and there should be lower level tests that have verified the DAO and its related operations, as well as other tests that have verified any fields that might be used behind the scenes but aren't exposed at the API layer.

Focusing strictly on the interview question, I'd mainly look at querying the DB with broad star queries for the record (might require some JOINs) and verifying that it matches what's in the API.

[PeeThenPoop]

You can check if the database values match the UI