Results 1 to 4 of 4

Thread: Concept of Database testing

  1. #1
    Contributing Member
    Join Date
    Aug 2007

    Concept of Database testing

    As a Tester i can understand the importance/concept of Database Testing

    and i would like to share it whats followed in Database testing

    This article will discuss some quick and easy ways that a tester can start to perform 'grey box' or 'white box' testing against the databases in their application, which will allow them to more easily uncover problems with the database.

    Functionality of the database is one of the most critical aspects of your application's quality; problems with the database could lead to data loss or security breaches, and may put your company at legal risk depending on the type of data you are storing.

    Considering how important the database is to the success of applications, it is surprising how little attention is focused on database testing. In my experience, the biggest barrier is that most testers simply don't have time to directly test the database, so they end up focusing their testing efforts on testing via the GUI.

    Referential Integrity:

    As the name implies, relational databases store data as well as information about the relationships between various data. Data records will often contain references to other data records in other tables. Maintaining integrity of these relationships is critical; if relationships between data become broken, the function of your application could be compromised.
    Database developers use a number of different tools to provide referential integrity including constraints (rules within the database which require references to be maintained), triggers (processes which are 'triggered' by changes to specific data) and application code (logic contained in the application which describes how to manipulate the data).
    Depending on which methods your database developers have used, the database will be vulnerable to different sorts of referential integrity issues. Constraints are the most effective way to maintain integrity, since the RDBMS will prevent anyone from making changes that will break integrity. Maintaining referential integrity via application code is the most risky (but also most flexible) approach, since you are relying on the programmers' code to make every modification correctly.

    As a tester, the first thing to do is find out how referential integrity is being maintained in your database. One of the best ways to do this is via a schema, which is a visual diagram of all the tables in the database. You can ask your database administrator (DBA) or the development team for a schema, or you can create one yourself via tools like Visio.

    The tools used by the developers and/or DBA to create the database will also show you any constraints and triggers used in the database, and are usually pretty easy to set up.

    Once you know how integrity is being maintained, you can then begin to analyze how it could be broken, and what the risks are in your application. For instance, if your application relies on the application code to maintain integrity, then you will want to make sure that every piece of code that modifies the data is thoroughly tested and doesn't introduce data integrity issues. If the application relies on triggers, then you will want to have tests which cause every trigger to be fired, and make sure that the data is being modified correctly by the triggers.


    There are a number of ways that security of the database is maintained. The most common ways are via usernames and passwords, or via integration with a directory such as LDAP. Some of the key questions to consider are:
    • Does each user of the application have a separate password to the database, or is their a shared database account for all users of the application?
    • What is the permission-level of the account(s) used to access the database?
    • What interface is used to manage the accounts used to access the database? What other ways are there to access the database using the same login information as the application?

    In practice, many applications require that each user has a different account at the application-level, but there is a single account shared by all users to access the database. As a tester, it's important to understand how the database is being accessed, with what level of permission, and to make sure that all stakeholders are aware of the risks being introduced via the chosen methods.

    The best resources for testing the security of your database are the developers/DBAs, and the management tools provided by your RDBMS. Developers can tell you how the database is being accessed, and the RDBMS can provide information about the privileges associated with the accounts your application is using.

    Last edited by raj1402; 04-08-2010 at 02:36 AM.

  2. #2
    Contributing Member
    Join Date
    Aug 2007

    Re: Concept of Database testing


    In today's complex applications, data must pass between one or more (typically many more) interfaces. Some of the typical types of interfaces which exist between the user entering or reading data, and the database may include, but are not limited to:

    • Graphical user interfaces (GUIs) on the web or desktop
    • Java, COM, or .net classes
    • Web Services
    • Screen-scraping of a legacy mainframe application
    • Application programming interfaces (APIs) for access the database, such as ODBC, JDBC, and OLEDB
    Bugs can be introduced at any of these interfaces, no matter whether you are reading, writing, updating, or deleting data.

    Testing the interactions between all of these interfaces can be very complex, but I would suggest that at a minimum, you:
    1. Understand all of the interfaces that data passes through between the user and the database.
    2. Learn about the technologies used to implement each interface, and what the possible bugs are due to that interface.

    It is possible to create tests which are run against each of these interfaces; however some of these tests may require some programming. If you are going to test against an interface other than the UI, it is important to understand what formats of data are expected at that interface. This leads us to the next topic, data formats.

    Data Formats

    Data in a database may be input from and displayed on a number of different types of systems, including Web-based applications, desktop applications, and handheld devices. Each of these types of systems has unique system limitations, which may dictate how data should be stored and/or formatted in your database.

    Take dates as an example. Most Windows applications can accept dates up to the year 9999, but many handheld devices can only accept dates up to the year 2039, due to memory capacity limitations. If your database allows users to store dates past 2039, what happens when you try to display one of these dates on a mobile handset?

    The format of data may also change as it passes through various interfaces between the user interface and the database. For instance, data may first be extracted from the database in tabular format, then converted into XML format so it can be transferred via a web service, then be transformed into HTML for display within a browser. At each one of these interfaces, the format of the data will be changed, and new bugs may be introduced.

    Again, you can test the data at each of the interfaces, but it may require some programming. At a minimum, you should be able to identify all of the formats used to transfer the data between each interface, and understand some of the fundamental limitations of the technologies being used. This will allow you to create better test cases, and more intelligently analyze data-related bugs that appear during testing or pop up in production.


    Database testing is one of the most challenging tasks facing a software QA team. At a minimum, team members should understand referential integrity and database security, and have a good grasp on the various technologies and data formats used to transfer data between the user and the database.

  3. #3
    Junior Member
    Join Date
    Mar 2010

    Re: Concept of Database testing

    that was really good about dbase testing .

  4. #4
    Junior Member
    Join Date
    Dec 2007

    Re: Concept of Database testing

    It is too good answer.

  5.  Sponsored Ads


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
About us
Applying for a job can be a stressful and frustrating experience, especially for someone who has never done it before. Considering that you are competing for the position with a at least a dozen other applicants, it is imperative that you thoroughly prepare for the job interview, in order to stand a good chance of getting hired. That's where GeekInterview can help.