TestgrityBack to portal

Beta browser support, limitations, and support

This page defines the supported client setup and support process for the Testgrity private beta. It is not a service-level agreement.

Supported browsers and viewport

The beta supports the latest stable desktop versions of:

  • Google Chrome on Windows and macOS.
  • Microsoft Edge on Windows and macOS.

Use a viewport of at least 1280 × 720 CSS pixels at 100% browser zoom. 1440 × 900 or larger is recommended for the three-column Designer, run details, and report views. A physical high-DPI display is supported; the CSS viewport, rather than the panel resolution, is what matters.

Chrome or Edge is required for interactive environment sign-in, extension recording, and Browser execution because those features use the Testgrity Recorder extension. Keep the Testgrity and D365 tabs open until recording or a Browser run finishes, and allow the extension to open the configured D365 site.

Firefox, Safari, mobile browsers, tablets, browser private/incognito modes, and viewports below 1280 × 720 are not part of the supported beta test matrix. Basic pages may render in some of those clients, but beta support should first reproduce an issue in a supported desktop Chrome or Edge configuration.

Known beta limitations

  • Browser execution is sequential in one Chrome or Edge tab. It does not produce genuine Playwright traces. It can produce screenshots, WebM tab videos, browser diagnostic bundles, and Playwright HTML/JSON summaries. Video capture requires one explicit click on the Testgrity extension button at the beginning of the run.
  • Browser execution supports the common recorded actions documented in the user manual. Unsupported advanced actions fail with a diagnostic instead of switching silently to Background execution.
  • Background execution depends on a valid saved environment session. Microsoft MFA, Conditional Access, password changes, or session expiry can require an environment reconnect.
  • Suite concurrency is limited to three cases. Parallel browser contexts do not isolate Dataverse records, views, users, queues, or business-process state; use isolated test data for concurrent cases.
  • Metadata and app references reflect the last successful environment refresh. Refresh metadata after D365 app, table, field, form, or choice changes.
  • Screenshots, video, traces, and reports can contain customer or personal data. Workspace owners must choose appropriate capture and retention settings.
  • The beta does not promise uninterrupted availability, backward compatibility for every experimental workflow, or a contractual response or resolution time.

Requesting beta support

Use the in-app Report button and choose Report an issue when it is available. Otherwise email contact@dynamicsduo.com.au. Do not include passwords, session cookies, access tokens, unredacted production screenshots, or confidential Dataverse records.

Include:

  • the affected TEST or PROD environment;
  • the page URL and approximate time, including time zone;
  • the visible run ID, test case number, and environment name when applicable;
  • Chrome or Edge name/version and viewport size;
  • the expected and actual result;
  • minimal reproduction steps; and
  • a redacted screenshot or trace only when it is safe to share.

For suspected security incidents, data exposure, destructive test behaviour, or a complete production outage, put URGENT BETA INCIDENT in the subject and stop the affected run or disconnect the affected environment when safe. The team will triage beta reports on a best-effort basis, prioritising security, privacy, data integrity, and complete service outages over ordinary defects or feature requests. Any contractual support commitment must be stated in a separate written agreement.

Support triage

The responder should:

  1. acknowledge the report and remove any unnecessarily shared sensitive data;
  2. assign impact as critical, high, normal, or low;
  3. link the report to the relevant run ID, deployment version, and incident when one exists;
  4. reproduce in TEST before changing PROD whenever practicable;
  5. communicate containment or workaround guidance; and
  6. close the report with the fix version, outcome, or documented limitation.

Operational responders must use the internal rollback and incident-response checklist at Docs/azure/07-rollback-and-incident-response.md for production incidents.