Tests

The Tests page is the core evidence engine of DSALTA. It shows every automated compliance check running against your connected integrations and against your workspace data — each test produces a pass or fail result that serves as audit evidence.

​

How tests work

When you connect an integration (e.g., AWS, Google Workspace, GitHub), DSALTA automatically generates compliance tests specific to that integration. For example, connecting Google Workspace generates tests like “MFA should be enabled for all users” and “Offboarded users should not have active access.” Tests run on a nightly schedule. You do not need to configure or schedule them — they activate as soon as the integration is connected and data is synced. See Run schedule for the exact cadence.

​

Viewing your tests

The test list shows all active tests with: Integration is not a column — it is a Select Integration dropdown in the toolbar above the table, which filters the list down to one integration’s tests. Click any test to open its detail panel. Results carries the current status and an About This Test block that links to this check’s guide in this help center, Source Data lists its recent runs with the evidence payload for the latest one, and Evidence, Controls and Comments hold your uploaded files, the controls the test supports, and the discussion thread.

​

Test statuses

Every test shows one of six statuses:

• Completed — The check ran to completion. It does not by itself mean you passed: for an integration-powered test, a run that found a compliance gap is also Completed. Open the test’s Source Data tab and read the result code.
• Failed — DSALTA was blocked and could not evaluate the check, almost always a missing permission (403) or a setting it still needs from you (428). A DSALTA-run system test also shows Failed when it genuinely fails.
• Error — Reserved for execution errors. In practice an integration test that errors surfaces as Failed, not Error.
• In Progress — The test is running right now.
• Not Run — The test has not executed yet, typically because the integration was only just connected.
• Deactivated — The test has been switched off and no longer runs or counts toward your posture. See Deactivating a test.

​

System tests vs. integration tests

Every test is one of two types, and both run automatically — DSALTA has no manual test type that you create and tick off by hand. Integration tests run against a connected integration and are generated when you connect it. The detail panel’s Source row names the integration, and the Provider column shows its logo. System tests are run by DSALTA itself against data already in your workspace — policies, risks, vendors, changes, and so on. Their Source row reads DSALTA and the Provider column shows the DSALTA logo. Both types appear in the same list and carry equal weight during audits. If a control needs evidence that no test can produce, attach a document or upload evidence to the test rather than looking for a manual test.

​

Run schedule

The two types run on separate nightly jobs:

• Integration tests re-run daily at 02:00 America/New_York.
• System tests re-run daily at 15:30 Europe/Istanbul.

There is also an hourly integration sync at five minutes past the hour, and for the cloud, identity and developer-platform integrations DSALTA syncs on that schedule it refreshes Access, Inventory, Vulnerabilities and Code Changes. Test runs stay on the two nightly jobs above. To get a result sooner than the nightly job, use Run in the panel’s Run Test row.

​

Working with failing tests

When a test fails:

1. Click the test’s row to open its panel.
2. Check the Source Data tab first — the result code tells you whether the check found a gap (207), was blocked (403 or 428), or errored (500).
3. Read the run’s summary line in the Evidence block on that same tab — one sentence stating what the check found and why it got that status. The status card at the top of Results carries the same headline for a passing run, and the run’s error text for a failing one.
4. Apply the fix: when the run produced one, the same Evidence block carries a remediation line naming it, and View Documentation in the Results tab’s About This Test block opens this check’s platform-specific guide in this help center.
5. After making the fix in the source system, DSALTA picks up the change on the next run and records a 200 result. On an integration-powered test the status pill does not change — it was already Completed — so confirm the fix by the code, not the pill.
6. To see the result sooner, click Run in the Run Test row of the panel, or click Sync from integrations on the Integrations page (Connected tab) to refresh every connected integration first.

​

Deactivating a test

If a check does not apply to your environment, deactivate it. Open the test from Data Library → Tests, then use the ⋮ menu at the top right of the panel and choose Deactivate Test. For example, if you do not use AWS Redshift, you can deactivate the Redshift-related tests. It applies immediately, with no confirmation step. To reverse it, open the same menu — the item now reads Activate Test. A deactivated test shows a gray Deactivated pill, is skipped by the daily run, and is excluded from the pass percentage on the Tests card.

​

Linking tests to controls

Tests are automatically linked to the compliance controls they provide evidence for. When a test passes, it satisfies part of the control requirement. You can see which controls each test supports on the test detail page.

​

Related pages

• Integrations
• Controls
• Audits