AI Testing & MCP

Set Up Custom Fields and Configuration by Chat

Configuration work is real work: custom fields, setup choices, and the drift between your sandbox and production. Over MCP it becomes a conversation, including the move nobody’s import wizard covers: promote this config from sandbox to prod.

Config lives in clicks, and clicks do not travel

You build a careful custom field setup in a sandbox project. It works. Now production needs the same thing, and the only path is a screenshot on one monitor and a settings screen on the other. Configuration management tools for Jira cover Jira; your test management app’s settings are usually on their own.

This exact question came from a customer evaluating configuration management tooling: can changes made in a sandbox be pushed to production? For BesTest data the answer is yes, through your agent: it reads configuration over MCP and applies it wherever you point it. We set up our own live project’s configuration this way, and the agent nailed it.

The re-entry ritual

  • Screenshot the sandbox settings, screen by screen
  • Re-create each custom field in prod by hand, hoping the types match
  • Diff the two projects by eyeballing them
  • Repeat the whole ritual after the next round of changes

The promotion prompt

  • Ask the agent to read the configuration from one project
  • It recreates fields and settings in the target through the MCP
  • Ask for a diff first, so you review before it writes anything
  • The next round of changes is the same sentence again
Try it yourself

One prompt, start to finish

you ask your agent
Read the BesTest custom field setup from our sandbox project SBX and recreate it in project PROD. Show me a diff of what you are about to create before you write anything.
  1. 1

    Reads the source configuration

    Over the MCP it pulls the custom fields and setup from the sandbox project: names, types, options, the details that never survive manual re-entry.

  2. 2

    Shows you the plan

    Because you asked for a diff first, you get the list of what already exists in prod, what is missing, and what it will create. You approve before anything is written.

  3. 3

    Applies it to the target

    The same fields land in production, created through the MCP under your permissions. Run the same prompt after the next sandbox round and only the delta moves.

The result

Configuration stops being tribal knowledge trapped in screenshots. Sandbox to prod becomes a reviewed, repeatable prompt, and "how did we set this up?" always has a current answer.

BesTest · Project settings
Test typeSelect · Manual, Automated, Exploratorytest cases
Automation ownerUser pickertest cases
RegulatoryCheckbox · flags audit scoperequirements
Release trainSelect · Q3, Q4cycles

The same prompt replays against the next project, so sandbox to prod stops being a screenshot exercise.

More prompts to steal

You

List every custom field in project ALPHA with its type and options.

You

Compare the BesTest configuration of projects ALPHA and BETA and show the differences.

You

Set up custom fields for test environments, browser versions, and severity in our project.

Scoped to your permissions, granted per user

Your agent acts as you: everything it reads or writes stays inside your Jira permissions. The MCP is in closed beta while we harden it, with GA coming. The request form asks for a few details from BesTest’s Project Settings in your Jira, which is what lets us enable exactly your site and user.

Request beta access

Frequently asked questions

Does this cover Jira configuration too?

No, and the boundary is worth knowing: the BesTest MCP covers BesTest configuration, like custom fields and setup inside the app. Jira-side configuration belongs to Atlassian tooling: the Jira MCP, or dedicated configuration management apps. Together they cover both halves.

Can it change production without me noticing?

Only if you tell it to write without review. The safe pattern, and the one we bake into every example prompt, is diff first: have the agent show what it will change, then approve. Everything runs under your permissions either way.

What about moving test data along with the config?

The same MCP covers requirements, test cases, and links, so "copy the config, then bring over the test case library" is two prompts, not a migration project. See the migrate and import guide for the data half.

Ready to Get Complete
Testing Visibility?

Start using BesTest today and experience complete testing visibility from requirements to release. Free to get started!

Available on the Atlassian Marketplace. Install in seconds, free for up to 10 users.

Start Free on Marketplace
Enterprise SecurityBuilt on Atlassian Forge.Built by TestersDesigned by QA professionals.Free to StartGet started for free and scale as you grow