0

In database testing, I learnt sql queries and then compare the expected and actual result. Like this if I search for the GUI elements parameters, the DB entries will be displayed in the DB I can compare the expected and actual. This is the process I am following now. May I know I am doing it right?

But I couldn't get any bug. If there were more than 100,1000 pieces of data, it will take time to check and if it repeats the case takes more time. So should every tester go for automating or not?

  • Are you saying that you're cross-checking your web app/GUI results to the DB, using the same query the web app is doing? This seems like really low value testing. If the results are correctly displayed in the GUI, making sure it read the right info from the DB sounds highly repetitive . . . – ernie Aug 4 '17 at 15:34
2

I don't think you should be testing each and every record in the database, I would rather suggest considering the following testing types:

  1. Positive testing: use criteria which definitely return result. If your application doesn't have "static" scenarios it can be substituted with Fuzz Testing or Pairwise Testing
  2. Boundary testing: depending on your application specifics use boundary inputs to check edge conditions and how does your application handles them
  3. Negative testing: your application should not display anything when criteria not matching any db data are given
  4. Security testing: ensure that non-privileged users cannot see the data they should not be seeing. You can put testing against any forms of SQL injections here as well.
  5. Load Testing: you need to ensure that your application works well under the anticipated load. Additionally you can perform stress testing and soak testing to see how it behaves under prolonged load and where it starts to break.

If it makes sense to invest into automation (i.e. the time required for automation will be less than the aggregate time of all anticipated executions) it is better to go for it, moreover load testing assumes automation.

0

It depends

If most or all of your processing and data manipulation happens at the GUI or server end, you can get away with manual checks of the database to make sure of things like checking that you don't get orphaned records when you delete, that any database auditing happens, and so forth.

If there is a lot of processing and data manipulation happening in the database, you may want to employ one of the database unit testing tools to check that processing.

If all you are looking for is checking that the records match a baseline, that can be done with some simple scripting in any language.

Every tester who works with database driven software should know enough SQL to inspect database records, but whether it's necessary to automate the database checks will depend a lot on the nature of the application.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy