QA must present verification of application correctness as data travels through system

Backend testing is the testing the integration between the application and the database. It is checking
the changes made in the database is getting reflected in the application

Back end Testing means ensuring that,

1 If you enter data in the front end, the data should be stored properly in the back end.

2 If you call that stored record from front end it should display properly.

What is Database?

The Collection of Interrelated Data is called Data Base.

Relational Database Concepts

RDBMS= DBMS +Referential Integrity (It is achieved through Foreign Key).

Referential Integrity: The existence of a value in one dataset is dependent on the existence of the same
value in another linked dataset

Ex: Oracle, Sqlserver, Mysql follow RDBMS model.

What should we Test in Data Base?

Database testing basically include the following.

1) Data validity testing.

2) Data Integrity testing

3) Performance related to data base.

4) Testing of Procedure, triggers and functions.

Data validity testing: Testing the correctness and reasonableness of data.

Ex: Account no falling within range, numeric data being all digits, dates having valid months

Note: Data validity errors are more common and most difficult to detect.

Errors in data validity are caused by End user/ by who enters Ex: 13/25/2006

Date integrity is nothing but enforcing the business rules (facts/data) into database table is called data
integrity

Types of Data Integrity:

Entity Integrity: can be achieved through Primary Key and Unique Key Constraints.

Should be tested: whether it is taking duplicate values, Whether it is taking null values.
Domain Integrity: can be achieved through Not null, Default, Check.

Should be tested: Whether it is taking default values even though if we won’t give, checking the values
in the column. Ex: age column should take < 60.

Referential Integrity: can be achieved through Foreign Key.

Should be tested: Checking Whether "child" rows are deleted or not when a parent row is deleted from
parent table.

For performance related Testing in DB:

Indexes are used to increase the performance.

It is nothing but ordered list of values taken from one or more columns in the tables and organized in to
b_tree structure

Need to test: whether we have created index on column for particular table or not.

Why back end testing is so important?

A back end is the engine of any client/server system. If the back end malfunctions, it may cause system
deadlock, data corruption, data loss and bad performance. Many front ends log on to a single SQL
server. A problem in a back end may put serious impact on the whole system. Too many bugs in a back
end will cost tremendous resources to find and fix bugs and delay the system developments.

It is very likely that many tests in a front end only hit a small portion of a back end. Many bugs in a back
end cannot be easily discovered without direct testing.

Differences between back end testing and front end testing

It is not easier to understand and verify a back end than a front end because a front end usually has
friendly and intuitive user interfaces.

A back end has its own objects, such as, tables, stored procedures and triggers. Data integrity and
protection is critical. Performance and multi-user support are big issues. Slowness in operation can be
vital to the project’s future.

There are no sufficient tools for back end testing. SQL language is mainly a testing tool. To be able to
do back end testing, a tester must have strong background in SQL server and SQL language. It is
relatively difficult to find testers who understand both SQL server and SQL testing. This causes a
shortage of back end testers.

Back end testing phases, database testing phases

There are several phases in back end testing. The first step is to acquire design specifications for an SQL
server. The second step is test specification design. The next step is to implement the tests in this design
with SQL code. The test specification design should contain information concerning component testing
(individual pieces of the system), regression testing (previously known bugs), integration testing (several
pieces of the system put together), and then the entire system (which will include both front and back
ends).

Component testing will be done early in the development cycle. Integration and system tests (including
interfaces to front ends and nightly processes) are performed after the component tests pass. Regression
testing will be performed continuously throughout the project until it is finished. The back end usually
does not have an independent beta test, as it only exercised by the front end during the beta test period.
The last step is to deliver users a quality product.

Back end test methodology

Structural testing and functional testing are more effective approaches in back end testing. They are
overlapped in some test cases. However, the two methods may discover different bugs. We strongly
recommend testers to do both types of testing. There are many other test methods that can be applied to
back end testing. We list a few below.

Structural testing

A back end can be broken down into a finite number of testable pieces based on a back end’s structure.
Tests will verify each and every object in a type of structure.

Functional testing

A back end can be broken down into a finite number of testable pieces based on application’s
functionality. The test focus is on functionality of input and output but not on the implementation and
structure. Different projects may have different ways to break down.

Boundary testing

Many columns have boundary conditions. For example, in a column for percentages, the value cannot be
less than zero and cannot be greater than 100%. We should find out these types of boundary conditions
and test them.

Stress testing

It involves subjecting a database to heavy loads. For incidence, many users heavily access the same table
that has a large number of records. To simulate this situation, we need to start as many machines as
possible and run the tests over and over.
DATABASE TESTING

Functionality Testing in Relational Databases

Stored procedures and triggers. Stored procedures and triggers should be tested just like your application
code would be.

Relationship Testing in Relational Databases

Referential integrity (RI). RI rules, in particular cascading deletes in which highly coupled "child" rows
are deleted when a parent row is deleted, should also be validated. Existence rules, such as a customer
row corresponding to an account row, must exist before the row can be inserted into the Account table,
and can be easily tested, too.

Data Quality Testing in Relational Databases

Default values. Columns often have default values defined for them. Are the default values actually
being assigned. (Someone could have accidentally removed this part of the table definition.)

Data invariants. Columns often have invariants, implemented in the forms of constraints, defined for
them. For example, a number column may be restricted to containing the values 1 through 7. These
invariants should be tested.

Validate the attribute size. Is the field size defined in the application is matching with that in the db.

Performance Testing of Relational Databases

Access time to read/write/delete a single row.

Access time for common queries returning multiple rows.

Access time for queries involving several tables.

Existence test for an index. Does the expected index exist or not?

Structural Testing in Relational Databases

Table existence. We can check whether all the data from the application is being inserted into the
database properly, or not
View definitions. Views often implement interesting business logic. Things to look out for include: Does
the filtering/select logic work properly? Do you get back the right number of rows? Are you returning
the right columns? Are the columns, and rows, in the right order?