Ana içeriğe geç
Versiyon: 1.0.7

Correct Use and Best Practices

AutoRunner can generate automation and repeatedly execute it against external systems. Treat scenario design, activation, test data, scheduling, and issue creation as separate review gates.

Write bounded scenarios

  • State the starting URL, application, or service.
  • Define the required action and expected outcome.
  • Explicitly prohibit credentials, submission, navigation, purchase, deletion, or messaging when those actions are outside the test.
  • Keep one scenario focused on one reviewable behavior.
  • Use synthetic accounts and reversible test data.

Keep lifecycle records distinct

  • A generation run explains how automation was proposed.
  • A review draft needs human decision.
  • An automation version is immutable.
  • An activation event selects the version used by execution.
  • A Test Plan organizes scenarios.
  • A Test Run supplies execution evidence.

Never use successful generation as a substitute for a Test Run.

Review generated automation

  • Resolve every review reason and inspect disabled steps.
  • Verify element locators and dynamic values.
  • Check control-flow bounds and failure behavior.
  • Remove unsupported internal node types.
  • Review setup and cleanup for partial-failure safety.
  • Publish deliberately and record the active version.

Protect data and access

  • Mask secret variables and keep credentials out of prompts and logs.
  • Import only approved DataCrate and local files.
  • Review screenshot and artifact contents before sharing or exporting.
  • Scope runner network access and secrets to approved projects.
  • Confirm the active workspace before changing shared sources, plans, or settings.

Validate execution

  1. Run manually with the intended Run Profile and environment.
  2. Confirm runner attribution and source revision.
  3. Read status and result separately.
  4. Inspect the first failing step, logs, screenshots, and artifacts.
  5. Re-run only after the cause or diagnostic change is understood.
  6. Compare like-for-like executions in Reports.

Schedule only stable plans

  • Prove each plan manually before scheduling.
  • Confirm time zone, recurrence, end rule, and exclusions.
  • Verify runner capacity and external-system rate limits.
  • Make setup and cleanup idempotent.
  • Pause schedules before source, credential, environment, or destructive-flow changes.

Use quality signals correctly

Dashboard widgets, report trends, and quality-gate evaluations guide investigation. They do not replace the exact Test Run and approved release policy. A quality gate blocks delivery only when an external pipeline explicitly enforces it.

Report issues safely

Attach the run ID, failing scenario or step, expected/actual result, and sanitized evidence. Verify the provider and project before creating, linking, assigning, or transitioning external issues.

Production-facing automation requires authorization

Do not point generated or scheduled automation at production or customer data without explicit authorization, a tested rollback or cleanup strategy, and the required operational safeguards.