Major Issues to focus on while Performing Black-Box Database Testing
While performing the black box testing for a database system, it is important to concentrate on the following issues:
1. Data loaded from the interface is correctly stored in the database:
We need to check that whatever data we are entering, whether through text boxes, menu items, checkboxes, etc. is being stored as it is in the database or not. Also, the data needs to be correct in terms of both syntax and semantics. For example, a date entered through a text box should be stored in the database as in the form of date and time format and not plain text.
a. We have to know about source data (table(s) columns datatypes and Constraints)
b. We have to know about Target data (table(s) columns datatypes and Constraints)
c. We have to check the compatibility of Source and Target (back-end to front-end).
d. Then we should compare the column’s data of Source and Target.
e. We have to check the number to rows of Source and Target.
f. Then we have to update the data in Source and see the change is reflecting in Target or not.
g. We have to check about junk character and NULL values.
2. Data fetched from the database is properly displayed at the front end:
This means that if we are trying to fetch some data from a table through a query or join, it should return the same set of data in terms of number of records, columns, format, etc. To give an example, if the birth date of a person is stored in table in the date time format, it will be stored as say, “1981-01-10 00:00:00:000” but on the user information page only the date information might be required. Also it has to be seen that if database stores date in YYYY/MM/DD format and the client want the display in DD/MM/YYYY format, then the correct values appear in the respective text-boxes.
3. Data integrity, consistency and non-redundancy is maintained throughout:
Data Integrity – Data integrity refers to the wholeness or completeness of data during operations involving transfer, storage and retrieval. It also refers to the preservation of data so that whatever process in undergoes through, it will still remain to be what it has been intended for. In other words, data integrity is the assurance that data will always be correct, consistent and accessible. Integrity is related to the quality of data. Integrity is maintained with the help of integrity constraints. These constraints are the rules that are designed to keep data consistent and correct. They act like a check on the incoming data. It is very important that a database maintains the quality of the data stored in it. DBMS provides several mechanisms to enforce integrity of the data.
Entity integrity is an integrity rule which states that every table must have a primary key* and that the column or columns chosen to be the primary key should be unique and not null. A direct consequence of this integrity rule is that duplicate rows are forbidden in a table. If each value of a primary key must be unique no duplicate rows can logically appear in a table. The NOT NULL characteristic of a primary key ensures that a value can be used to identify all rows in a table.
Referential integrity is a property of data which, when satisfied, requires every value of one attribute (column) of a relation (table) to exist as a value of another attribute in a different (or the same) relation (table). Referential integrity preserves the defined relationships between tables when rows are entered or deleted. In SQL Server, referential integrity is based on relationships between foreign keys and primary keys or between foreign keys and unique keys, through FOREIGN KEY and CHECK constraints. Referential integrity makes sure that key values are consistent across tables. This kind of consistency requires that there are no references to nonexistent values and that if a key value changes, all references to it change consistently throughout the database.
When you enforce referential integrity, SQL Server prevents users from doing the following:
- Adding or changing rows to a related table if there is no associated row in the primary table.
- Changing values in a primary table that causes orphaned rows in a related table.
- Deleting rows from a primary table if there are matching related rows.
*Primary key – The primary key of a relational table uniquely identifies each record in the table. It can either be a normal attribute that is guaranteed to be unique (such as Social Security Number in a table with no more than one record per person) or it can be generated by the DBMS (such as a globally unique identifier, or GUID, in Microsoft SQL Server). Primary keys may consist of a single attribute or multiple attributes in combination.
*Foreign Key – A foreign key is a field in a relational table that matches the primary key column of another table. The foreign key can be used to cross-reference tables.
4.Constraints related to data type, data size, defaults and nulls are satisfied.
Data types specify what the type of data can be for that particular column. If a column called “Last_Name”, is to be used to hold names, then that particular column should have a “varchar” (variable-length character) data type.
Here are the most common Data types:
|char(n)||Fixed-length character string. Size is specified in parenthesis. Max 255 bytes.|
|varchar(n)||Variable-length character string. Max size is specified in parenthesis.|
|number(n)||Number value with a max number of column digits specified in parenthesis.|
|number(n,d)||Number value with a maximum number of digits of “size” total, with a maximum number of “d” digits to the right of the decimal.|
What are constraints?
When tables are created, it is common for one or more columns to have constraints associated with them. A constraint is basically a rule associated with a column that the data entered into that column must follow. For example, a “unique” constraint specifies that no two records can have the same value in a particular column. They must all be unique. The other two most popular constraints are “not null” which specifies that a column can’t be left blank, and “primary key”. A “primary key” constraint defines a unique identification of each record (or row) in a table.
Other important points to remember
1. To perform database testing you need to have a sound knowledge of database system and its structure. Prepare database test scenarios and write SQL scripts in advance. Do not use SP’s or triggers used in existing database system, they might be defective. Just try to evaluate different conditions for which data is displayed at the front end and validate this data with the results obtained by executing SQL scripts.
2. Only focus your attention in validating your front end data with the database. Do not try to analyze database system, unless otherwise a performance or data reliability issues observed at front end (any ways that’s a job of database administrator to find a root cause).
The element of gray-box testing
The true black box tester looks only at the GUI and can not touch intermediate files, registry entries, databases, etc., nor is they permitted to see the results their actions have wrought, other than through the UI. They are, therefore, only permitted to use the UI to do their testing.
The typical gray box tester is permitted to set up his testing environment, like seeding a database, and can view the state of the product after their actions, like performing a SQL query on the database to be certain of the values of columns. It is used almost exclusively of client-server testers or others who use a database as a repository of information, but can also apply to a tester who has to manipulate XML files (DTD or an actual XML file) or configuration files directly.
Written By: – Devesh Sharma, QA Engineer, Mindfire Solutions
Posted on April 9, 2014, in DataBase Testing, Manual Testing and tagged Black-Box Database Testing, Data Integrity testing, database Testing, Devesh Sharma, element of gray-box testing, gray-box testing, Manual Testing, Mindfire Solutions, QA Engineer, SQL Server testing, Web Application Testing. Bookmark the permalink. 1 Comment.