For your role · QA and test engineers

For QA: verify the data a test leaves behind

A test that passes on screen can still leave the wrong rows behind. DataTug keeps the queries that check data state in one project, so you can rerun them after every run, and is building Checks that spot a known data bug before it reaches users.

Watercolor of an inspector on a slipway tapping a tugboat’s hull with a small hammer, holding a checklist with ticks, chalk circles on the checked spots.

The UI says the test passed. I still need to see what it wrote to the database, and whether last month’s data bug is back.

Your day

  • Data state after a run. Did the test create one order or two, and did the payment row get its status? The answer is in a database, not the UI.
  • Recurring data bugs. The same broken record shows up again a few releases later, found by a customer instead of a test.
  • Access to staging and production. Checking real data means asking for a login or borrowing a developer’s, with more access than the check needs.
  • Finding the right test data. The test needs an order that is paid but not shipped. Finding one means a query you write from scratch each time.

One task, before and after: verify the data a checkout test left behind

Who: QA and test engineers

Today

3 tools1 hand-offno shared password

  1. You · SQL clientRun the test, then open a SQL client against staging.
  2. You · SQL clientWrite the same checks by hand: one order, one payment, the right status.
  3. You · Test reportPaste the results into the test report.
  4. Next release · NotesHope someone remembers the check next release.
Today3 tools · 1 hand-off · no shared passwordRun the test, then open a SQL client against staging.Write the same checks by hand: one order, one payment, the right status.Paste the results into the test report.Click to see

With DataTug

1 workspace0 hand-offsno shared password

Some steps are planned or in development.

  1. Every runKeep the verification queries in the project and rerun them after each run.Query workspace in the web appAvailable
  2. Every runTurn a known data bug into a Check that says pass or fail (in development).Reusable ChecksIn development
  3. YouFollow a test order to its payment and shipment as related records.Related records in the web appAvailable
  4. YouRead staging or production with scoped access policies today, and through one Perimeter, in development.Access policiesAvailable
With DataTug1 workspace · 0 hand-offs · no shared passwordKeep the verification queries in the project and rerun them after each run.Turn a known data bug into a Check that says pass or fail (in development).Follow a test order to its payment and shipment as related records.Click to see

Each step names the part of DataTug it relies on and that part’s status today. “Planned” and “In development” steps describe where the product is going, not what you can use now.

Solutions for you

Also useful: Incident InvestigationData Quality & Monitoring

Try it on sample data

The public demo project opens in the browser with sample Northwind and Chinook data. No sign-up.

Explore the demo project