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.
- 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 | Today | Planned |
|---|---|---|
| Project snapshot | Listing + details, CRUD | — |
| Test run result | In data model | UI linking |
| Bug | Separate product version fields | Reproduction snapshot link |
| Automation | Same catalogs in API | Runner fills snapshot at start |
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”).
- Linking snapshots to failed results and creating bugs with context carried over.
- Project custom attributes on snapshots.
- CI integration and runner auto-fill.
See also
| Version | 1.1 |
| Last updated | 2026-06-13 |