3 database testing hurdles: How to get over them

Most projects face three database testing challenges: Under-testing, costly automation, and faulty in-term communication. These challenges often have a common root cause—the drive to save money. 

The result is painful: Project costs actually rise, and quality leaves much to be desired.

Here's how to deal with each of these challenges.

World Quality Report 2018-19: The State of QA and Testing

Challenge 1: Under-testing

Database testing is a complex effort that requires a structured, well-planned approach. When the testing team doesn't have enough experience, testing becomes lengthy and incomplete in terms of test coverage and the test data used. 

Incomplete scope of testing

Under-qualified testing teams perform only back-box database testing. They test the applications that rely on databases by acting like real users; they test only through the user interface (UI).

This approach provides valuable insights into the application's UI and user experience (UX), but the testing team never knows how much of the application they actually tested—and what they left behind.

For its part, white-box testing provides a clear idea as to test coverage, but requires testers with good SQL skills. Those testers cost more, but the cost is justified, as SQL queries also work for testing database triggers, procedures, functions and other critical database properties.

Although it's possible to use SQL queries written by developers, the latter often apply a limited perspective. This makes the queries less efficient.

Inexperienced testing teams also often fail to prioritize database features in terms of importance, which is critical to saving time and effort. They try to test it all, then lose valuable time by testing minor parts of the database, and leaving the major parts under-tested or not tested at all. Lack of experience may also lead to inefficient regression testing and continuous growth of technical debt, which may well drown overall testing efforts—and the project.

Incomplete test data

One common testing approach is to populate a database with a limited amount of mock data that you invent on the fly. Often these data have nothing to do with the real data, so the testing team can't detect certain faults (such as an incorrect number of symbols allowed, faulty fill-in permissions, and so on).

When you finally uncover these issues, you'll need to spend extra time and effort debugging and retesting. Luckily, it's possible to use realistic test data without exposing actual customer data. While you can't use the names of real people and companies, you can use postal codes, phone codes, or phone numbers specific to a target country or region. And that may help you to adequately address any front-end inconsistencies that users might experience.

Challenge 2: Pricey automation

An increase in time and effort is not the only source of sprawling project costs in database testing. Unwise automation can also take a heavy toll on your project.

That automation usually involves performance testing (stress and load subtypes). The goal of automation is to make testing faster and more efficient, so how can it result in a galloping growth in costs?

The problem is that testing teams are often unaware of the cost of tools. They tend to go for open source tools, hoping to get a seamlessly performing tool for nothing. But there’s no such thing as a free lunch. These tools may provide rich functionality free of charge, but open source tools may also lack the stability and convenience of commercial tools.

And you won't get much done using a free trial. Although commercial tool vendors typically  offer a free trial version, functionality availability during the trial is often limited.

For better service, you'll have to pay, so if you decide to go with a commercial tool it's critical to calculate your costs correctly. To do that you'll need a good understanding of the project specifics and tool functionality required. Do the calculations: Underestimating automation costs resulted in serious over-budgeting in DevOps teams in 2017, according to a recent report in Forbes.

Challenge 3: Faulty in-team communication

For agile projects, which cover about about 90% of software development, according to a recent survey, seamless communication is not a buzzword but an important success factor.

For applications that rely on databases, a lack of communication and a vague understanding of the business logic on the part of the testing team can have critical consequences. In the realm of testing, this translates to an unclear understanding of data structure and business logic, which make up key elements of database testing.

When communication is poor, testing teams are often the last to know about recent changes to data or schema. Test engineers then need even more time to rewrite test cases to adapt them to those changes.

In an agile project with many team members, additional issues may also arise when submitting tasks to testers. Common issues include:

  • On-the-fly code changes that go unreported and untested, leaving product quality to chance.
  • Tasks submitted late, resulting in ad-hoc and incomplete testing.

The result: Your whole testing effort goes south.

Faulty communication is especially harmful for database migration efforts. Often these efforts are treated as a simple relocation of the data to another environment, when in fact they require deep knowledge of the migrating databases' specifications. And that can only be achieved through good communication between all team members, from technical specialists to business analysts and stakeholders.

Those are just the most common database testing issues that stem from bad in-team communication practices. Poor in-team communication may also extend the project timeframe and hit your project budget hard.

These phenomena are telltale signs of project failure. So what are the counter-measures you can take?

How to leap the database testing hurdles

These database testing issues tend to stem from the same root cause, and are related. This creates a spider's web that captures agile projects, making them stagger and eventually fail. To prevent your project from falling into this trap, follow best practices, both at the testing and project management levels.

On the testing level, be sure to use:

  • Black-box and white-box testing. White-box testing gives you a clear idea of test coverage and ensures verification of numerous database properties (triggers, constraints, field conditions, and so on). But it says nothing about UI issues, which may be critical for users. That's why you also need black-box testing.
  • Realistic test data for the target country or region. This can help detect some bugs at early stages in order to avoid late—and expensive—rework.
  • A wise approach to automation. Your team should evaluate the capabilities of commercial and open source tools and weigh the pros and cons for the database under test.

On the project management level, be sure to:

  • Employ a qualified testing team. Testing is key to ensuring project quality. That's why using a low-cost, inexperienced testing team doesn't make sense. The amount you may lose if some bugs reach users may exceed the price for testing with quality vendors. 
  • Ensure seamless in-team communication. In agile projects, productive in-team dialogue is just as important as it is in international politics. Flawless communication among team members allows for a bird's-eye view of the project. Clear communication also helps to nip some database issues in the bud, as early as the architecture phase.

Taken together, these measures will help you to successfully address database testing challenges so you can keep your project timeline on track, your budget under control, and unexpected surprises in check. 

How are you tackling big database testing challenges? Share your thoughts and comments below.

Topics: Dev & Test