Aller au contenu principal

Using AI for Manual Testing

Ora can help with every stage of manual API testing — from building a request from natural language to filling in complex request bodies, analyzing responses, and turning a working call into an automated test step.

info

Screenshot: API Playground view with the Ora panel open and a request filled by Ora.

Importing an API Specification​

Ora can import an API description for you — ask it in conversation, or hand it an address:

"Import the OpenAPI spec at https://petstore.swagger.io/v2/swagger.json"

Ora first shows you a preview — the protocol, the operations and schemas it found, and any warnings — without installing anything. Only when you agree does it generate and install the service, after which the operations appear in the service tree and Ora can fill and send real requests.

Two rules matter:

  • Ora proposes the protocol and the application and service names from the source you gave; it always reports what it guessed, so correct it before importing rather than after.
  • If the names you gave would replace an already-installed service, Ora refuses at first and asks whether to replace it. It never decides that itself — importing under the same names deletes the existing package.

Credentials are never passed through the conversation: for an authenticated specification, export it and import from a file.

Refreshing a Specification and Seeing What Changed​

When a specification you already imported has changed, ask Ora to refresh it and report the difference:

"The spec at <address or file> was updated — re-import it and tell me what changed"

Ora re-imports under the same rules as a first import, then reports the contract diff against what was installed before the refresh: which operations were added, removed, or renamed, and how many are unchanged. The previous operations are captured before the service is replaced, so the comparison happens in one step — after a plain re-import the previous operation list is already gone.

Two things to know:

  • A refresh of the same source proceeds without asking; replacing an installed service with a different document (same names, different specification) still requires your explicit agreement, exactly like a first import.
  • The diff is at operation level. Changes inside a request or response schema are not part of the report when the operation itself kept its address — those surface at runtime, when a response no longer matches the shape your request expects.

Building Requests from Natural Language​

Tell Ora what you want and it builds the request in the ManualTesting view:

"Generate a GET request for the Petstore /pet/{petId} operation"

"Build a POST request to create a user with name, email and password"

Ora inspects the operation schema, sets the URL, method, path/query parameters, and a default body for you.

Filling in Requests​

Ora understands API semantics and fills in realistic request data automatically (handled by the TestBuilder specialist):

"Add an assertion that the response status is 200 and the body has a 'name' field"

"Set up Bearer token authentication with the token in variable $&#123;authToken&#125;"

The Request/TestBuilder specialist fills in:

  • Request body fields with sample values matching the schema
  • Query parameters and path parameters
  • Headers (Content-Type, Authorization, custom headers)
  • Authentication configuration

Polymorphic schemas are handled too: when an operation takes several payload shapes (a discriminated union), Ora sets the schema's own discriminator property for JSON services and falls back to the serializer's $type marker where a service needs it — so the payload deserializes to the right shape on the first try.

Sending Requests​

When Ora sends for you, the send is checked before anything leaves:

  • An empty URL is refused before the send (blocked_no_url) — a request without an address is never silently routed to the local simulation server.
  • The URL is the endpoint BASE only for REST operations — the engine appends the operation's path at send time, so a URL that already contains the path would carry it twice and 404. Ora knows this rule and reports the exact URL that went out.
  • While a non-default environment is active, the endpoints belong to that environment — the URL fields are read-only and Ora fills/switches through the environment instead of editing the request behind your back.
  • A send that cannot be dispatched (no registered client for the operation) answers send_failed with the host's reason immediately instead of burning a 30-second timeout.

Every send result carries the response status line, the elapsed time, a response preview, and the resolved URL — so "what exactly went out?" is always answerable from the exchange on screen.

When an exchange was produced at the service simulation instance level, Ora loads that operation into the manual editor with it — the exchange you clicked appears on screen in the editor, not only in the instance's own view.

Checking the Fill and the Verdict​

Before sending, Ora can wire the playground's manual-check rows for you:

"Add a filling rule that requires the departure city" "Assert the response status is 200 and extract booking_ref from the body"

The rows appear in the live editor immediately; a send then evaluates them and returns the verdicts with the result summary — a refusal names the rule that failed. When Ora reports what a request looks like, it also says where it read from — the manual editor as you see it, or a stored instance state — so a stale instance can't be mistaken for what's currently on screen. A whole-body JSON set that would silently drop a member (for example a payload shape without its discriminator) is reported as partial, naming the keys that were lost.

Analyzing Responses​

Ask Ora to interpret a response — it reads the actual response from the current context (the response is already visible in the Studio response panel, so Ora explains rather than echoing raw data):

"What's wrong with this 400 response?"

"Check if the response body matches the API spec"

"Explain the PII implications of this response"

Saving a Request as a Test Step​

When a request works, Ora can turn it into an automated test step without re-filling the body:

"Save this request as a new test step in the active case"

The Orchestrator switches to the TestAutomation view and dispatches TestBuilder, which copies the current request into a SendRequest step and can then add data-driven setup, assertions, and mapping rules.

Generating Request Variants​

Quickly create variations of a request for edge-case testing:

"Create a variant of this request with an empty body"

"Duplicate this request but change the user role to admin"

Context Awareness​

When the ManualTesting view is active, Ora knows which service and operation you are looking at through the live Studio context. You can reference elements naturally:

"Change this service to use the staging base URL"

"Add a new saved response for the default case"

Tips​

  • Be specific — "Fill in all required fields with French locale data" works better than "Fill this in".
  • Use relative references — "this request", "this service" — Ora knows your current context.
  • For complex scenarios, describe the workflow step by step.
  • To watch Ora reason as it works, enable Show thinking process in Settings → Ora — the model's reasoning renders collapsed above each reply (off by default).
  • Images and text files can go straight into the conversation — see Attachments and Images.

See Also​

Dernière mise à jour le