Use Test Automation

​

What this does

LoopIQ Test Automation turns product requirements and delivery work into reviewable manual test cases, framework-native automation, isolated test runs, and release-ready evidence. Use this area to:

• generate documented manual test cases
• generate Playwright, Selenium, or Karate automation
• review generated content before creating test records
• reuse captured page objects across multiple application pages
• model cross-page user journeys
• run approved automation in disposable Kubernetes jobs
• review step-level screenshots, traces, page references, and failures

LoopIQ always applies your current organization and selected team context. If expected applications, modules, work items, repositories, or runs are missing, verify the active team and your Test Automation permissions.

​

Supported frameworks

LoopIQ supports:

• Playwright for browser UI automation
• Selenium for browser UI automation
• Karate for API automation

Generated code never runs inside Django, Helix, or long-running AI agent pods. Only approved automation assets can be submitted to isolated runners.

​

Generate a review-only test package

1. Open Test Management.
2. Select Test Automation.
3. In Generate test coverage, select the application.
4. Select a module when the requirement belongs to a specific module.
5. Select the target framework.
6. For Playwright or Selenium, select a Page Object Repository.
7. Optionally select a cross-page user journey.
8. In Requirement or test intent, search for and select one work item.
9. Select Generate manual + automated tests.

The requirement selector can include:

• ideas
• stories
• tasks
• issues
• change requests
• incidents
• service requests

The selector displays work-item titles. After selection, LoopIQ sends the selected title and description to the generator so the resulting tests remain grounded in the source work. Generation creates a Generated test package in draft status. It does not immediately create manual test cases or executable automation assets.

​

Review a generated package

The review area displays:

• draft manual test cases
• draft automation assets
• selected framework
• coverage summary
• generator warnings
• generation timestamp

Review each manual case for:

• a clear title and objective
• realistic preconditions
• complete steps
• observable expected results
• appropriate priority and test type
• traceability to the selected work item

Review each automation draft for:

• the correct framework and language
• stable page object references
• appropriate API endpoints and payloads
• specific assertions
• correct journey step order
• absence of secrets or sensitive personal data

​

Approve or discard a package

To publish a reviewed package:

1. Open the draft from Draft package history.
2. Review the manual cases, automation assets, coverage summary, and warnings.
3. Select Approve and create.

Approval creates the manual test cases and draft automation assets. You can then approve individual automation assets before execution. To reject the generated content, select Discard draft. Discarding a draft does not create test cases or automation assets. Draft package history shows recent draft, published, and discarded packages so users can return to unfinished reviews.

​

Approve an automation asset

Publishing a package creates automation assets in draft status.

1. Open the published generated package.
2. Locate the automation asset.
3. Select Approve asset.
4. Confirm that the approved asset is the version you intend to execute.

Only approved assets show the option to queue an isolated run.

​

Manage Page Object Repositories

An application or module can have multiple Page Object Repositories. A repository can contain multiple pages and immutable versions. Use separate repositories when product areas, workflows, or ownership boundaries should be maintained independently. Within a repository, use pages to organize objects captured from individual routes or application screens. You can:

• create repositories with user-friendly names
• search and select repositories
• add multiple captured pages
• rename pages
• archive or restore pages
• reorder pages
• browse immutable repository versions
• compare object and locator changes
• restore a previous version as a new version

Restoring a repository version does not erase history. LoopIQ creates a new immutable version and records an audit event.

​

Create a cross-page user journey

A user journey tells LoopIQ to generate one end-to-end automated flow across multiple captured pages.

1. Select a Page Object Repository with at least two active pages.
2. Find Cross-page user journeys.
3. Enter a journey name and optional description.
4. Select Add page visit.
5. Add at least two distinct pages.
6. Use the up and down controls to arrange the visits in execution order.
7. Select Save journey.
8. Select Use for generation, or choose the journey in Generate test coverage.

A page can be used more than once later in a journey. Archived pages cannot be used for new journeys, and a page used by an active journey must be removed from or replaced in that journey before it can be archived. Karate API generation does not require a browser page journey.

​

Run approved automation

1. Open the approved automation asset.
2. Select Run asset.
3. Select or confirm the target environment when prompted.
4. Monitor the run in Recent automated runs.

Run statuses include:

• queued: LoopIQ accepted the request and is preparing isolated execution.
• running: The disposable runner job started.
• passed: All required assertions completed successfully.
• failed: One or more test steps or assertions failed.
• error: Setup, runtime, callback, timeout, or infrastructure prevented completion.

Queued and running jobs have a maximum non-terminal lifecycle of 60 minutes. Stale runs are moved to a terminal error state rather than remaining active indefinitely.

​

How isolated execution works

Playwright, Selenium, and Karate run in separate disposable Kubernetes jobs. Runner protections include:

• organization and team-scoped execution context
• no generated-code execution in the LoopIQ backend or AI agent pods
• no mounted Kubernetes service-account token
• read-only filesystem controls where supported
• strict CPU, memory, and execution limits
• secrets supplied only for the approved execution
• one-time result callback
• tenant quotas and concurrency controls
• cleanup of temporary credentials and completed jobs

​

Review journey evidence

Expand a completed run to review Journey evidence. Each journey step can include:

• step number and status
• journey and page name
• page URL
• instruction and expected result
• execution duration
• locator references
• failure type and redacted failure message
• screenshot
• downloadable trace

Evidence downloads require an authenticated LoopIQ session and are scoped to the current organization.

​

Evidence retention and redaction

LoopIQ redacts common sensitive values before storing test evidence, including:

• authorization headers and bearer tokens
• JWTs
• passwords and secrets
• API and access keys
• cookies and session values
• email addresses
• sensitive values identified by credential-related field names

By default, binary evidence files such as screenshots and traces are retained for 30 days. Redacted evidence metadata is retained for 365 days. Organization policy or platform configuration can change these periods. Expired files and metadata are removed by the evidence cleanup process.

​

Troubleshooting

​

Generated content is not visible

• Open Draft package history.
• Confirm the package was generated in the selected team.
• Open the package and review its manual cases and automation assets.
• Remember that draft packages do not create real records until Approve and create is selected.

​

Generation reports a missing test case reference

Regenerate the package. Every automation artifact must reference a generated manual case or an existing test case in the selected team.

​

A repository or journey is missing

• Confirm the application and module selection.
• Search using part of the repository name.
• Confirm the repository and journey are active.
• Confirm you have access to the selected team.

​

A run stays queued or running

• Refresh Recent automated runs.
• Confirm the asset is approved.
• Ask an administrator to check runner capacity, quotas, callbacks, and Kubernetes Job creation.
• Runs exceeding 60 minutes should automatically transition to error.

​

Evidence is missing

• Wait for the runner callback to finish.
• Confirm the run reached a terminal status.
• Expand the run and check whether it predates step-level evidence support.
• Ask an administrator to verify evidence storage and retention configuration.

​

Recommended practices

• Review generated packages before publishing them.
• Keep manual cases readable and traceable to source work.
• Use Page Object Repositories instead of duplicating locators in generated tests.
• Capture each application page separately within the appropriate repository.
• Use journeys for real end-to-end flows across pages.
• Approve only automation you understand and intend to run.
• Run tests against controlled non-production environments unless production execution is explicitly approved.
• Treat failures, screenshots, and traces as governed release evidence.