Jira, Trello and project management tools

Bugmole can keep your tests in the tracker your team already uses. With Jira Cloud connected:

1. You add Bugmole to a Jira project.
2. Bugmole proposes the test scope and test cases.
3. You review and approve the test plan.
4. Bugmole creates a Jira ticket for each approved test.
5. After every run, Bugmole moves passed tickets to Done. Failed tickets move to Blocked, and Bugmole mentions the people on them.
6. Your team reviews and fixes the issues.
7. When a ticket is ready for another test, someone mentions Bugmole in a comment.
8. Bugmole retests only that ticket's test and posts the result on the ticket.

Jira Cloud is available today. Asana, ClickUp and Monday.com aren't supported yet.

Link bugs to your tracker

Any bug Bugmole finds, a visual bug or TestFlight feedback, can be linked to an issue in your team's tracker so that closing the issue can be checked against a fresh run:

On a bug, choose Link issue (or Link elsewhere once it's linked) and pick a connected tracker; trackers that aren't connected yet say where to connect them. A bug can be linked once per tracker.

Issues → Linked lists every linked bug on one board, each card with its tracker's logo, in Open, Closed and Unknown columns. GitHub tells Bugmole when an issue changes; Jira, GitLab and Trello are asked each time someone opens the page. An issue is Closed when Jira puts it in a Done status, GitLab closes it, or a Trello card is archived or marked complete.

Set up Trello

1. Signed in to Trello, open Trello's Power-Up admin, create a Power-Up for your workspace and generate its API key.
2. In the dashboard, open Settings → Trello, paste the key, then open Get a token while signed in as the Trello account Bugmole should create cards as, and allow it. Paste the token.
3. Paste the board's link (https://trello.com/b/…) and choose Connect Trello. New cards go to the board's first open list; pick another list there any time.

Bugmole checks the key, token and board before it saves anything. The key and token are encrypted, write-only (nobody can read them back, not even through the API), and used only by Bugmole to create and read cards. Only an owner or admin connects or disconnects Trello; anyone who can edit the project can link a bug to it.

Set up Jira

Before you start

• A Jira Cloud site (your-team.atlassian.net). Jira Server and Data Center aren't supported.
• An Atlassian account for Bugmole to act as. A dedicated account named "Bugmole" works best: people @mention it by name, and its own comments never start a retest. It needs permission to browse, create, edit, transition and comment on issues in the project.
• Owner or admin access to the Bugmole project.

1. Create an API token

Signed in as the Bugmole account, open id.atlassian.com → Security → API tokens and create a token. Copy it; Atlassian shows it only once.

2. Connect the project in Bugmole

In the dashboard, open Settings → Jira and enter:

Bugmole checks the token and the project before it saves anything. The token is encrypted, write-only (nobody can read it back, not even through the API), and used only by Bugmole to call Jira.

3. Add the webhook in Jira

After you connect, Bugmole shows a webhook URL and a secret. The secret is shown once; Rotate webhook secret makes a new one.

In Jira, a Jira admin opens Settings → System → WebHooks and creates a webhook:

• URL: the webhook URL from Bugmole.
• Secret: the secret from Bugmole. Jira signs each delivery with it, and Bugmole rejects deliveries without a valid signature.
• Events: Comment → created.
• Optional JQL, to send only Bugmole's tickets: labels = bugmole-test.

If you can't use Jira's system webhooks, a Jira Automation rule works too. Trigger it on Comment added with a Send web request action that POSTs to the webhook URL with the header X-Bugmole-Webhook-Secret: <secret> and this body:

{"webhookEvent":"comment_created","issue":{"key":"{{issue.key}}"},"comment":{"id":"{{comment.id}}","body":"{{comment.body.jsonEncode}}","author":{"accountId":"{{comment.author.accountId}}"}}}

Bugmole records every retest a ticket asks for in the workspace audit log, and rejected deliveries at most once a minute per connection. Deliveries it accepts but has nothing to do with (a comment without the keyword, say) aren't recorded.

How the workflow runs

Propose the plan (steps 2–3)

Bugmole writes test cases as proposals: an agent proposes them while exploring, or a person proposes them on the Tests page. On the Tests page, Propose test plan to Jira creates one Jira task labelled bugmole-plan. It lists every waiting proposal with its steps and expected results, and links back to Bugmole. Choosing it again with the same proposals won't create a second task.

You approve the plan in Bugmole under Proposed changes, following the project's approval mode. Once every proposal on the plan task is decided, Bugmole comments with how many were accepted and moves the task to Done.

Tickets for approved tests (step 4)

When a proposal is accepted, Bugmole creates a Jira task for that test case. Each ticket is labelled bugmole-test, holds the test's steps and expected results, and links to the Tests page. Each test case gets exactly one ticket. When an accepted change makes a new revision of a test case, Bugmole updates that test's existing ticket. When a test case is retired, its ticket gets the bugmole-retired label and a comment, and Bugmole stops posting results to it.

Create tickets for approved tests on the Tests page does the same on demand. Also ticket existing tests also creates tickets for test cases that were already in the project before Jira was connected (for projects on Bugmole storage).

Ticket creation is idempotent. Each ticket also carries a label unique to its test case (bugmole-case-…), so if Bugmole loses track of a ticket, it finds the same one again instead of creating a duplicate.

Results on tickets (step 5)

After every run, Bugmole reads each test case's result and updates its ticket:

• Passed: moves the ticket to a Done-category status (preferring one named "Done"), removes bugmole-blocked, and comments with a link to the run and its evidence.
• Failed, or never reached: moves the ticket to a status named Blocked if the workflow has one. If it doesn't, the ticket stays where it is and gets the bugmole-blocked label. Either way, Bugmole comments with the failure, a link to the evidence, and @mentions of the ticket's assignee and reporter.
• Needs setup: comments only.

Each run is reported once, however often Jira or Bugmole retries.

Retest one ticket (steps 7–8)

When a comment on a bugmole-test ticket contains the retest keyword, or @mentions the Bugmole account, Bugmole queues a run of that test's plan scoped to that one test case. It comments that the retest is queued. When the run finishes, only that ticket is updated. Other tickets keep their state, and other test cases keep their latest results.

Bugmole ignores its own comments, comments without the keyword, and tickets it didn't create. A retest needs a published plan for the test's journey; without one, Bugmole says so on the ticket. Delivering the same comment twice doesn't start a second run.

Security

• Credentials are encrypted with AES-256-GCM under a key of their own for each project. Each value is bound to its project, connection and field, so a copied ciphertext can't be opened anywhere else. No route returns a token or webhook secret after you save it, and neither appears in logs or the audit log.
• Only project owners and admins, signed in to the dashboard, can connect, change or disconnect Jira. API keys and runners can't.
• The site must be an https://<name>.atlassian.net address, so a connection can't point Bugmole's requests anywhere else.
• Webhooks are checked against the connection's own secret with a constant-time comparison. Bugmole accepts it as Jira's X-Hub-Signature (HMAC-SHA256 of the body), as an X-Bugmole-Webhook-Secret header, or as a token query parameter. Prefer the first two: a query parameter can end up in proxy logs.
• Disconnecting deletes the stored credentials and Bugmole's links to tickets. The tickets stay in Jira; if you reconnect, Bugmole finds them again by their labels.

Limitations

• One Jira site and project per Bugmole project.
• Jira Cloud only.
• Tickets are Jira Task issues. Pick a project whose issue types include Task.
• Per-test results of a whole run reach tickets only for projects on Bugmole storage: for projects that keep results on their own machine, Bugmole can't read them. A single-ticket retest that finishes is always reported, using the retest run's own outcome; a canceled one isn't. Tickets for existing tests can be created only for projects on Bugmole storage.
• Approval happens in Bugmole. Moving the plan task in Jira doesn't approve anything.