Execution context and environment
In Complex QA, environment is not a single free-text field on a bug or an informal note on a run. It is a consistent set of conditions under which a tester executed work or where a defect was found.
Below: the data model concept and what is already available in the UI (the project Execution context area).
Why it matters
Without fixed context, reproducibility fades: “bug on staging” six months later does not answer which browser, build, or URL was meant. Context links manual testing, run results, and bugs through one vocabulary-the same environment dimensions-not separate ad hoc fields per entity.
Two layers: catalog and snapshot
Catalogs are shared dimensions: browser, OS, screen resolution, device class, locale, deployment target. Some values ship with the service; a project can add its own entries.
An execution context snapshot (execution_context) records what actually applied at the moment: chosen catalog entries, host, base URL, protocol, build version on the snapshot. History should not “drift” if a catalog label is renamed later: the API returns hydrated reference objects, not bare IDs only.
Environment axes (catalogs)
| Axis | Snapshot field | Example values |
|---|---|---|
| Browser | browser_context_id | Chrome, Firefox, Safari, … |
| OS | os_context_id | Windows, macOS, Linux, Android, iOS |
| Screen resolution | screen_resolution_context_id | 1920×1080, 390×844, … |
| Device | device_context_id | Desktop, Mobile, Tablet |
| Locale | locale_context_id | ru-RU, en-US, … |
| Deployment target | deployment_target_context_id | staging, production, preview, … |
Catalogs are service-wide (reference search is not scoped by project_id). The snapshot still stores project_id-it belongs to a project.
Additional snapshot text fields:
| Field | Purpose |
|---|---|
context_title | Short snapshot name (title) |
context_description | Description (HTML) |
protocol | HTTP or HTTPS |
host | Host without scheme |
base_url | Full base URL |
build_version | Build version at snapshot time |
UI: Execution context area
Available from the project card and project sidebar.
Listing
- Table of snapshots for the current project.
- Create - new empty row in the project.
- Inline edit in cells (including environment axes via reference selects).
- Open details from a row click.
Snapshot details
- Editable title (
context_title). - Details tab: pivot field table + description block.
- Bugs tab: linked defects for this snapshot.
- Environment axes - searchable reference dropdowns (live search on
context_name). - Actions: Clone, Delete.
When saving a reference field, the UI shows the catalog label, not a raw ID. While the API request runs, the table shows a loading overlay.
Reference selects
- Empty search loads the full catalog for that axis (client cache on repeat opens).
- Typed search hits the backend (
LIKEoncontext_name). - “Not assigned” clears the link (
null).
Where context is used
| Entity | In the UI today |
|---|---|
| Project snapshot | Listing + details, CRUD |
| Bug | Tab Execution context on bug details - link/unlink snapshots |
| Test case | Tab Bugs on case details |
| Test run result | Tab Bugs on result details |
| Execution context | Tab Bugs on snapshot details |
| Automation | Same catalogs in API; runner auto-fill - planned |
Test accounts stay a separate entity; a snapshot may reference an account when run flows support it.
Product versions vs environment
Build version on a bug (bug_build_version, affected/fixed) is about the product release.
build_version on a snapshot is what was recorded in the environment at event time.
These do not replace browser/OS catalogs.
What’s next
- Presets (“typical desktop Chrome on staging”).
- One-click bug from a failed run result with context carried over.
- Project custom attributes on snapshots.
- CI integration and runner auto-fill.
See also
| Version | 1.2 |
| Last updated | 2026-06-14 |