Thursday, 24 November 2011


This document is to discuss general test specification issues for SQL server back end
testing and to provide testers a test design guide that includes test methodology.
Most systems, i.e. Forecast LRS, Delta, KENAI, KBATS and so on, that are developed
by ITG have client-server architectures. However, only a few projects have their back end
completely tested.

1.1 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 bug 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.
Back end testing has several advantages: The back end is no longer a "black box" to
testers. We have full control of test coverage and depth. Many bugs can be effectively
found and fixed in the early development stage. Take Forecast LRS as an example; the
number of bugs in a back end was more than 30% of total number of bugs in the project.
When back end bugs are fixed, the system quality is dramatically increased.

1.2 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. MS Access and MS Excel can be used to verify data but they are not perfect for
testing. However, there are a large number of test tools available for front end testing.
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.

1.3 Back end 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
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.

1.4 Back end test methodology

Back end test methodology has many things in common with front end testing and
API testing. Many test methods can be used for back end testing. 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. For other test methods, please
check other test design references.
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

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.


Post a Comment

TrainingHUB. Powered by Blogger.

Total Pageviews


QTP Training in hyderabad

Sql Tutorial

Popular Posts

Our Facebook Page