A Bug in Azure Boards, filed from the session that found it
Connect an Azure DevOps organisation and a personal access token, pick a project, and testers file a Bug work item without leaving the device session, automated run or scan in front of them.
Organisation name and a personal access token · no OAuth app to register
🐞 Bug #4821 — Checkout: payment step assertion failed
Open work item →
- Empty username
- the PAT is the password — Azure's own scheme
- Every item is a Bug
- title and description, api-version 7.1
- Two calls to attach
- upload the bytes, then patch the relation
- One-way filing
- nothing is read back from Azure DevOps
What gets filed, and how
One filing turns the failure in front of you into a Bug in your Azure DevOps project, with the evidence attached.
A Bug in the project you chose
Setup lists the projects in your organisation and you pick one, which becomes the organisation default. It is one level — there is no area or iteration picker underneath it — and every work item is created as a Bug.
Two fields, mapped exactly
The title you type becomes System.Title and the body becomes System.Description, sent as a JSON-Patch to the work-items endpoint pinned to api-version 7.1. There is no separate repro-steps field; the body goes into the description.
The screenshot, carried in two calls
Azure has no single-request upload, so the bytes go up as a loose attachment first, then the work item is patched with an AttachedFile relation pointing at the URL Azure hands back. If either step fails the work item is still created and you are told the screenshot did not attach.
Your token, sent the way Azure expects
The personal access token travels as HTTP Basic authentication with an empty username and the token as the password — Azure DevOps's documented PAT scheme. There is no OAuth app to register and no bearer-token flow.
Set up once by an administrator
An admin connects the organisation name and the token under Organization, then Integrations, then Defects. Testers then file work items without ever touching or seeing the credential.
Connect, not migrate
Nothing is copied out of Azure DevOps and nothing is read back. Each filing creates a new work item in your project and records the link between it and the run that produced it.
What the work item gets, and what it does not
Filing sets two system fields on a Bug and attaches the screenshot. Everything below that line is left to the project's own template, or is not part of filing at all.
Set on the work item
- System.Title — from the title you typed
- System.Description — from the body you wrote
- Work item type — always Bug
- Attachment — the screenshot, in two calls
Left to the project default
- Area Path and Iteration Path
- Assigned To — arrives with nobody on it
- Tags — none applied, none created
- Priority and Severity
- Repro Steps — Azure's separate field is left empty
Not part of filing
- Other work item types — no Task, Story or custom type, and no type picker.
- Links to a commit, branch or pull request.
- Anything in Azure Test Plans — nothing is read or written there.
- Status read-back — filing is one-way; closing the work item has no effect here.
- Calls Azure needs to attach one screenshot — upload the bytes, then patch the relation
- 2
- The Azure DevOps API version this integration is pinned to
- 7.1
- How your token is encrypted at rest, with a random IV per record and an auth tag
- AES-256-GCM
- Bug tracker an organisation holds at a time
- 1
The 32-byte key lives in an environment variable outside the database, resolved lazily so a missing key breaks filing rather than boot. No API in the product returns a stored credential, so once the token is saved neither an administrator nor the settings page can read it back — you can only replace it. A raw status line, a hostname or a stack trace never reaches the screen; a 401 or 403 becomes a plain instruction to reconnect the tool.
Frequently asked questions
Yes. A device session, an automated run or a scan that found a fault becomes a Bug work item in your Azure DevOps project, with the title and description filled and the screenshot attached. Filing is one-way — nothing is read back from Azure DevOps.
Two values: the name of your Azure DevOps organisation, and a personal access token with permission to create work items in it — one more than most trackers, and the same shape as Trello. The token is sent as HTTP Basic authentication with an empty username and the token as the password, which is the scheme Azure DevOps documents for PATs. There is no OAuth app and no bearer-token flow.
Because that is how Azure DevOps expects a personal access token to be presented. People new to the API put their email address in the username field and get a 401 they cannot explain. TestKase never asks for a username, so you supply the organisation and the token and nothing else.
No. Every work item is created as a Bug. Azure's per-project custom work item types are not modelled, so there is no type picker — the same trade-off the GitHub and GitLab integrations make. If your team files defects as a custom type, this integration will not produce it.
The adapter sets only the title and the description — no Area Path, no Iteration Path, no assignee, no tags, no priority or severity, and no separate repro-steps field. So a process template that requires, say, an Area Path or a custom field on creation will make Azure refuse the work item, and you see Azure's own wording explaining which field it wanted rather than a generic failure from us. Nothing here can fill that field in for you.
No. Filing is one-way. TestKase records the work item id and its URL against the session, test or scan that produced it, so the evidence and the work item stay connected, but nothing polls Azure DevOps and no state is read back. Closing or deleting the work item has no effect here. An organisation holds one bug tracker at a time, so connecting Jira or GitHub replaces Azure Boards in that slot.
No. Azure Boards is the work-tracking side of Azure DevOps, and this integration creates work items in it. Running tests as part of an Azure Pipelines build is a different job, covered by the CI/CD integration rather than this one. The two can be used together, but connecting one does not connect the other.
Connect Azure Boards and file the next bug from the session
Start free, paste an organisation name and a token, pick a project. The integrations overview lists everything else TestKase connects to.