Skip to main content
Written from your schemaChecks inside API suites

The API returned 201.
Did the order reach the database?

QAEverest tests the data behind your features. It writes database test cases from your real schema, and it checks the database during API automation runs, so a run shows what the API answered and what it stored.

Works with PostgreSQL, MySQL / MariaDB and MongoDB. Every query is read-only.

Coverage
6
Areas of database coverage
Schema constraints, CRUD integrity, referential integrity, transactions, migrations and data quality.
Databases
3
Database families
PostgreSQL, MySQL / MariaDB and MongoDB, with connections saved per test environment.
One run
1
Suite for API and database
The API call and the check on what it stored run side by side, in the same suite and the same report.
Two ways in

Plan the database tests, then check the database on every run.

Test case generation

Database test cases written from your schema

Point generation at a test or staging database and the cases name the tables and columns you really have.

  • Choose Database Testing as the type of testing on the story or Jira generate page.
  • Pick a saved database connection, and the cases name your real tables and columns.
  • List up to 20 Tables to focus on. The tables they link to through foreign keys are described first.
  • No connection yet? Pick None (story only) and the cases use placeholders such as <orders table> instead of made-up names.
  • BDD (Gherkin) or TDD, and the results page says which connection the cases were written against.

Generated database cases are for review and manual runs. The automated checks live in your API suites.

API automation

Database checks inside your API suites

Put a check on the database right behind the API call that changed it, and run both together.

  • Add a Database step to any API suite, or switch an existing step to Database.
  • Read rows, a count or whether a row exists, with a query that takes :name parameters.
  • Save a value from an API response, such as a new order id, and use it in later steps as {{order_id}}.
  • Click Verify in DB on an API step and the AI drafts the database check. You preview it and confirm it before it's added.
  • The run report and its PDF exports show the connection, the query, the row count and the rows.
Coverage

Six areas of database coverage

Each area has its own label on the test case cards, so a reviewer can see at a glance what a case is about. Pick any of them under Includes, or leave it empty to get all six.

Schema Constraints

Each table and column the story touches has the type, nullability and default it should, with the right primary keys, unique and CHECK constraints.

SCH · for exampleorders.total rejects a negative amount

CRUD Integrity

What each create, update and delete actually leaves behind: stored once, in the right table, with every field the request sent.

CRI · for exampleA placed order is stored once, with every field the request sent

Referential Integrity

Child rows always point to a parent that exists, and the app refuses one whose parent is missing.

RFI · for exampleAn order item for a missing order is refused

Transactions and Concurrency

A multi-step change is all-or-nothing. When a later step fails, nothing half-done is left in the tables.

TXC · for exampleA failed payment leaves no half-written order behind

Migration and Versioning

The migration history records the expected version, and rows from before a migration keep their values.

MGV · for exampleOrders created before the migration keep their totals

Data Quality

No duplicates where values must be unique, and no empty values in columns the story says are required.

DQL · for exampleNo two customers share the same email address
How it works

From an API call to a checked row, in four steps

01

Connect

Under API Automation > Environment Settings, add a database connection for each environment. Test connection lists its tables and columns.

02

Add the check

Add a Database step yourself, or click Verify in DB on an API step and review the query the AI drafts.

03

Pass values along

Save the id, header or status the API returned as {{order_id}}, and pass it to the database step as a :parameter.

04

Run and read

Run in any environment. Each step uses that environment's connection with the same name, and the report shows the rows it found.

Checks you can add
  • Row count
  • A row exists
  • No row exists
  • Cell value
  • Columns
  • Query time

A step with no check on its rows is flagged in the editor and marked Rows not checked in the run report, so a check that cannot fail never passes quietly.

Built for real databases

Read-only, by design.

Database steps are built to read your test or staging database and never change it. A step that tries to write is stopped before it reaches your data.

UPDATE orders SET status = 'PAID'
Refused when you save the step
Database steps run read-only queries: start with SELECT, WITH, VALUES, TABLE, SHOW, DESCRIBE or EXPLAIN.

Queries can only read

One statement per step, and writes are refused when you save the step and again when it runs.

Generation reads the schema only

Table and column names, types, keys and constraints go to the AI. Row values do not.

Environments stay separate

A Staging run uses the Staging connection and never another environment's database.

Passwords stay sealed

Connection passwords and URIs are encrypted with AES-256-GCM and shown only as a mask.

Secrets stay out of reports

Passwords, tokens and similar values are replaced with [REDACTED] before a result is stored.

Response data never becomes SQL

Values saved from an API response are passed as query parameters, never pasted into the query text.

Test what your API stored, along with what it said.

Add a database connection, generate your first database test cases, and put a Verify in DB check behind the API call your team worries about most.