Best practices for MCP prompting

When you work with test cases, reference the fields exactly as they appear in qTest. For custom fields, use the display name of the field as it appears in qTest.

If the AI doesn't recognize a custom field name, ask it to list the available test case fields for your project first: "What custom fields are available for test cases in project [ID number]?"

The MCP returns all file types supported by qTest. Executable files such as .exe, .class, .bat, .cmd, and .bin are blocked at the qTest Manager level and will not appear in results.

Use precise terminology and avoid ambiguous language. Specify exactly what you want to achieve and include relevant context and constraints.

Good examples:

• "Create a test plan with test cases that cover gaps in requirement [ID number]"

• "Show me the test logs for the latest test run in test case [ID number]"

• "Find all failed test runs in module [ID number]"

Avoid vague requests:

• "Create test case"

• "Show test logs"

• "Find failed test runs"

Make sure you provide the AI with enough context to complete the task. For example, unless you've already talked with the AI about a project, don't assume it has the knowledge.

Include relevant information to help the AI understand your context, such as: 

• Project IDs

• Module IDs

• Requirement IDs

• Test case IDs

Good examples:

• "What requirements are in project [ID number]?"

• "Please find all test cases attached to requirement [ID number]"

• "Create test cases that fill gaps for requirement [ID number]"

Avoid ambiguity:

• "Find all test cases"

• "What test cases do I need?"

Start broad, then narrow down based on results. This conversation flow helps you discover and focus on what matters most:

1. "Show me recent test cases from requirement [ID number]" → Get overview

2. "Focus on the failed test logs from last week" → Narrow scope

3. "Create defects for the failures of the test logs" → Actionable insights

Avoid overwhelming complexity and break complex tasks into clear, logical steps. That way, you don't overwhelm your AI with everything, everywhere, all at once.

For example:

• Instead of: "Analyze everything and tell me all the problems and solutions and comparisons and trends"
• Use: "Start by showing me which test runs failed this week, then we'll dig deeper"

Let's get more specific. To get the most control over your workspace, you may also find it helpful to ask the AI to generate objects for you to preview before finalizing them. For example, once the AI provides a test plan, you can review the test cases and specify which ones it should add.

Instead of:

"Create and add test cases to cover gaps in requirement [ID number]"

Use:

"Please help me create a test plan. I need:
1. A list of reusable test cases from requirement [ID number]
2. Identification of any testing gaps that currently exist in the requirement
3. A list of test cases that cover these testing gaps"

Then, once you've reviewed the AI's output, you can follow this prompt with:

"Please create these test cases and attach them to requirement [ID number]"

• Write as you would speak to a knowledgeable colleague.

• Avoid overly technical jargon unless necessary.

• Use conversational connectors ("Then", "Next", "Also").

Good examples:

• "Can you help me understand why our test run [ID number] failed?"

• "Let's dig deeper into those error patterns."

• "What test cases would you recommend for improving response times?"

Make your goals explicit rather than leaving them ambiguous:

• Instead of: "Create some test cases"

• Use: "Create 5 test cases that cover security testing for requirement [ID number]"

"Tell me about project [ID number]."

"Show the details for test case [ID number]"

"Show me all test cases attached to requirement [ID number]"

With previous context, you can use shorter prompts:

"List all test cases"

"Find all test runs related to test case [ID number]"

With previous context, you can use shorter prompts:

"List all associated test runs"

"What are the details of test logs attached to test case [ID number]?"

With previous context, you can use shorter prompts:

"List all associated test logs"

1. Discovery: "Show me all test cases attached to requirement [ID number]"

2. Generate: "OK, now create a test plan for this requirement that focuses on any gaps in test coverage. Get ready to add test cases, but don't create the test cases yet"

3. Finalize: "OK, please create these test cases and attach them to requirement [ID number]"

1. Historical Data: "Can you locate the requirement in qTest linked to the Jira story [name]?"

2. Generate: "OK, I'd like to create a test plan for this requirement and get ready to add test cases. There's a requirement called "verify navigation bar" that you can reference with existing test cases. Please propose a test case plan that reuses existing test cases. Don't create the test cases yet though"

3. Finalize: "OK, please create the new test cases"

1. Discovery: "Show me recent test runs from test case [ID number]"

2. Narrow down: "Focus on the failed test logs from last week"

3. Generate: "OK, now give me a list of defects that cover the failures of the test logs. Don't create the defects yet though"

4. Finalize: "OK, please create the new defects"

1. Discovery: "What are the valid priority, status, and testing type values for test cases in project [ID number]?"

2. Generate: "Please propose a test case for requirement [ID number] with High priority, Ready to Review status, and Functional testing type. Don't create it yet."

3. Finalize: "OK, please create the test case with those settings and attach it to requirement [ID number]."

To include a custom field, add it to your finalize prompt: "...and set the [custom field name] to [value]."

Structure: [Question] + [Context] + [Desired Action]

Example:

"What's causing the high test failure rate [Question]
in the last three test runs from module [ID number] [Context]?
Please analyze the patterns and suggest specific defects [Action]"

Structure: Compare [Item A] with [Item B] focusing on [Specific Metrics]

Example:

"Compare the test results between:
- Test run 1 [ID number] (baseline)
- Test run 2 [ID number](new feature)
Focus on the checkout and payment transactions"

Frame requests from specific perspectives:

"As a QA Engineer preparing to create test cases for Requirement A [ID number 1], review Requirement B [ID number 2] and tell me what test cases we can reuse in Requirement A

Set clear boundaries and requirements:

"Generate test cases for requirement [ID number]that:
- Cover gaps in existing test scenarios for the requirement
- Do not repeat existing test scenarios for the requirement
- Do not cover performance testing
- Do not cover security testing"