CRUD stands for Create, Read, Update and Delete. (Retrieve may occasionally be substituted for Read.)
Different users may have different CRUD cycles based upon the requirements of the system. A customer, for instance, might have the ability to create an account, retrieve it upon return to a website, update billing information, or delete it if necessary. An operations manager, by contrast, might create product records, (Read) call them up as needed, (Update) modify packaging or raw materials details or delete it if the product was discontinued.
You should test such operations from both Front-end (User Interface) and Backend (Database queries) e.g. you have a web application where you as an Admin create users and maintain their data. So,
- Login to application as the Admin user
- Open the Create user page, enter all necessary information for creating user like Firstname, Lastname, Email ID, User name, Phone no. etc. -- This is the create operation
- Hit the save button
- Now, go back to the user list and search for that user record and open its detail page, verify all the information is as it has been entered by you -- This is the Retrieve operation
- Go to Database, fire a query on the User table and search for your created record, verify all the values are as it has been entered by you on the UI, also they are in the same field column where they should be e.g. sometimes Last name on UI is wrongly mapped with First name in DB, so you should verify these things too.
- From the UI, edit that user record and update the Email ID or any other preferences. Save the changes and again verify the changes on UI and DB too.
- Now, Update the value directly from the DB for any field of the user record, and see that change should be reflected on the UI too (be sure that all referenced tables are also updated by you if there is no such tigger to update reference tables) --- This is the Update Operation
- Delete the record from the UI and verify that it should no more be visible on the User List and it should not be in the DB too, but here you need to validate the data according to the Business requirements e.g. you client says on Delete user data should be there in DB but it should be Inactive (like Active = 0, for the deleted user). Then you need to verify it accordingly that data exists in DB with Active = 0 and it should not be shown over the UI.
- Delete the User record from the DB directly (as per Business requirements) and see the changes are reflected on UI or not. Here double check your query which you are going to execute, else you have delete whole table or multiple users or their data might get corrupted. So, always verify you delete commands before executing them. Now, when deleting from the DB directly, delete from the referenced tables, else data will be corrupted and there can be some errors shown over the UI.
- Verify the formats of the data being stored in Database e.g. Date format, Time Format (if you application supports multiple time zone then it should be verified for different time zones). Validate where your application save NULL and where it saves ' ' (i.e. Blank). This NULL and Blank sometimes seems to be same but during retrieve it may cause issues.
For the next level, you can create your own Stored Procedures (SP) for verifying these CRUD operations, once you know about the queries and tables being used, you can create these SP where on firing the Delete SP, it will itself verify the main and referenced tables and provide you the results.
For the DB testing, you need to read about the queries, syntax and keywords required for creating and executing queries. Syntax of different DB differs from each other in one or more respect, so you should first read about the DB on which you want to perform the DB testing.