T-Tip #4 How to use AI to identify qTest entities
The qTest MCP Server finds objects by name — requirements, test cases, runs, releases, suites, cycles, builds and defects. Give it the project ID once and it carries that forward. After that you're naming things: show me the Homepage module, get me defect DF-12.
The bigger unlock is what happens after retrieval. Search gets you candidates; the agent reads them. Point it at one module, have it list the test cases, then ask which ones touch the invoice screen — it'll read the descriptions and steps and tell you. Narrow the scope, let the agent interpret. Faster and more accurate than asking for everything in a project.
For execution questions, skip search. Ask for an execution scope summary on a release, cycle or suite: structural tree plus run statistics in one call — passed, failed, never run. Then pull the latest test log for any run, with step-level results and linked defects.
Writing works too. Create requirements, update test cases, link cases to requirements, create defects from a failed log. Ask it to propose first, then approve.
Setup: bearer token from Download qTest Resources, an mcp.json in Cursor or VS Code, and view/create/edit permissions for your MCP user — missing permissions is the most common day-one failure, and it looks like the server being broken.
Run an execution scope summary on your current release this week and see what comes back unexecuted. Post your prompt in the qTest space.
Use PDFs, documents, or tables as an additional source of context. For example, your document may contain a UML diagram that defines how the application works. Combined with the product documentation, a Jira ticket, or GitHub, this allows the Tricentis QA agent to generate very precise test steps for local or automated testing.
