Test authoring strategy

Recommended practices for building reliable, maintainable testcases from the start — across Web, API, and Performance.

Plan before you build

• Choose the right automation type up front — Web, API, or Performance — since testcases, run configs, and results are organized by type.
• Keep each testcase focused on one scenario — smaller, single-purpose testcases are easier to debug, especially because Web execution is fail-fast and stops at the first failed step.
• Sketch reusable building blocks early — identify shared flows (login, setup, teardown) and capture them as Step Groups and Elements from the start rather than refactoring later.
• Decide your test data up front — choose whether each input is fixed (Data Set), generated (Random Variable), or captured at runtime before you author the steps.

Author locally, run of record in the cloud

Use the Local Agent while building and debugging — it gives fast, live feedback but doesn't save results. Use Cloud for runs you want stored and tracked in Test Results.

Record, then refine

Capture the flow with the recorder, then clean up steps, fix locators, and add Verify checks rather than shipping the raw recording.

Make results meaningful

• Add Verify steps (e.g. element displayed, text matches, value equals/greater/less) instead of assuming "it ran = it passed."
• Control failure behavior in the Test Run Config — by default a failed step stops the run; set On step failure → Report and Continue when you want the remaining steps to keep executing.
• Read COMPLETED as "finished," not "passed" — always confirm the PASSED/FAILED result and step-level detail rather than trusting the run status alone.

Drive data, don't hardcode

Parameterize inputs with Data Sets, Random Variables, and Runtime Variables instead of typing literal values into steps.

Design API tests deliberately

• Match the extraction type to the response — use JSONPath for JSON bodies, XPath for XML/HTML, and Regex for raw text; mismatches return empty values.
• Chain steps with variables — extract a value (e.g. an ID) in one step and reference it later with ${variableName} instead of re-typing it.
• Handle auth tokens explicitly — capture the token from the login/auth response, pass it on subsequent requests, and re-fetch it when it expires.
• Assert with Verify steps — check status and specific body fields rather than assuming a 2xx response means the test passed.

Before you run

• Save before the first run — a brand-new web testcase must be created/saved (with at least one step) before it can run, and Cloud runs always require a saved testcase. Once saved, later edits don't block a local run.
• For cloud runs, prepare a run tag and a Test Run Config before starting the run.
• For a combined performance API + Web run, prepare both a Web and an API config — each automation type needs its own.
• Confirm your org/project context before running, since testcases, configs, and results are all scoped to it.

Manage execution and runs

• Tag every cloud run meaningfully so it's easy to identify and track in Test Results later.
• Keep environment-specific Test Run Configs (scoped by automation type) rather than editing one config back and forth between environments.
• Use releases to group and compare runs over time, so you can see how a flow trends across versions.

Review and triage results

• Read step-level detail — it shows actual vs. expected and the failure message for the failing step.
• Use the Bug Report "Steps To Reproduce" view on Web failures to reproduce the issue quickly.
• Remember screenshots are cloud-only and follow the config's capture mode (e.g. failure-only); Local runs capture none.
• Compare against a baseline (Performance) to judge whether a run regressed rather than reading numbers in isolation.

Name consistently

Use clear, consistent names across testcases, step groups, elements, and datasets so assets stay findable as the project grows.