As technology is growing, things are getting more complex in computer world. When we access any website, mobile application or desktop application we think its quite easy and useful. But the fact is very different then what we think, to build those kind of application requires tremendous amount of effort. Complexity of user interface shows the complexity of their back end design. So as a tester it is always good to understand the whole architecture of the project including the database design.
In a simple word database is the place where data get stored. Data usually get stored in tables but that’s not an only object in data base there are other objects like views, stored procedure and functions. These objects helps the user to get the data in required forms.
Before we proceed lets look some other aspect of Database that we have to validate.
1) Data mapping: Data mapping is just one of the simple thing that every tester has to verify. Usually tester have to verify the user interface front end field mapping with the corresponding back end database field. Usually this information is given in SRS or BRS. But if it is not given then its better to dig in code if you can, otherwise ask the team lead. For any action preformed in frontend there is a corresponding CRUD action get invoked, and tester have to check the every invoked action is successful or not.
2) ACID Validation: ACID stands for Atomicity, Consistency, Isolation and Durability. These are the sets of properties that assures that transaction of database is processed reliably.
- Atomicity: Atomicity allows either all or nothing, it means a single transaction consist of many transaction, and if one part of the transaction gets failed then whole transaction gets failed. That why it is called all or nothing
- Consistency: Consistency stands for consistency of data that is data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof.
- Isolation: If there are multiple transactions and they are executed all at once, the result/state of the DB should be the same as if they were executed one after the other.
- Durability: Once the sql statement executed then result should get stored in database, and this data should not be lost because of any Power Loss, Crashes or errors.
3) Data Integrity: Data integrity is a broad term and have a widely different meanings depending on context. In a simple term we can explain that Data Integrity is opposite of data loss. This technique ensure that all data is recorded as intended and upon later ensure the data is same as it was when recorded.
4) Business Rule Conformity: Business rules provide the correct and consistent Control of your application data access. As a tester we need to verify the data with the help of SQL queries.
How to test?
Once the user has got the information regarding the data flow then he can start testing on Database. There are so many things to verify in Database but I will short-list only few of them for now.
- Schema Validation
- Data Mapping and Integrity
- Verification of Stored procedure and triggers
Schema validation is very basic but very important thing, we should always check whether schema is validated properly or not.
Data Mapping and Integrity is another important factor that every tester should verify. Consider about different modules present in one project perform a CURD operation on single data base table. Then it is important to verify that CURD operation perform as per expectation from all the modules. This thing can be verified manually and by writing sql queries.
Verification of Stored procedure and trigger is little tricky part. Some time it needs in-depth coding knowledge or advanced level of SQL knowledge. But still without knowing this tester can test this. First of all need to understand the condition when and how these triggers and stored procedure invoke. These conditions can be easily understood by looking into code or by simply asking the developers. Then simple make a scenario to invoke these stored procedure and trigger, once it is done verify the business logic and data that has been changed by CURD operation.
Regarding the testing of SQL queries I will post another article. Hope you al have enjoyed this. Please feel free to give any suggestion and ideas regarding the article.