Console

Create a project

Overview

The project creation wizard is the fastest path from empty tenant to reviewed, executable validation inventory. It sequences decisions that later affect generation quality, agent routing, and coverage traceability, so each step deserves deliberate input rather than default acceptance.

You can create a project with only a name and application URL, then attach requirements later. However, teams that upload structured requirements during creation see more actionable scenarios and cases on the first generation pass.

After the wizard completes, you remain in governed workflows: human review of AI output is expected before release-critical reliance, and execution targets must match registered application environments.

Who should read this

QA engineers, SREs, platform teams, and developers operating Zof Console and APIs.

Prerequisites

Create project permission in your organization
Application URL or planned application registration
Optional: requirements file (PDF, DOC, DOCX) within upload limits shown in the UI

When to use this workflow

Onboarding new team members to Zof terminology and workflows
Authoring internal runbooks aligned with Console labels
Designing CI/CD or webhook integrations against documented behavior

Step-by-step procedure

Launch Create project

From Console Home quick actions, Projects list, or ⌘K → "Create project", open the wizard.

Enter a descriptive name such as "Payments API, Reliability 2025 Q3" for future searchability.

Add a short description stakeholders will recognize in reports and notifications.

Connect the application target

Provide the primary application URL for web flows or select an existing registered application.

Specify default environment (staging vs production) consistent with your first planned runs.

For endpoint-only desktop targets, complete Agent Console application registration before expecting cloud execution.

Upload or link requirements

Upload a requirements document or link a specification record already in the catalog.

Ensure acceptance criteria sections are explicit, vague narratives produce vague generated cases.

Wait for processing completion before advancing if the UI shows ingestion progress.

Select test types and categories

Choose test types aligned to risk: functional paths, accessibility, security-oriented categories as enabled.

Avoid selecting every type "just in case"-broader generation increases review burden without proportional value.

Consult compliance stakeholders when regulated categories apply to your product.

Generate scenarios and cases

Start generation and monitor progress; large documents may take several minutes.

Review scenario groupings for requirement traceability before drilling into individual cases.

Edit steps and expected outcomes where AI misinterpreted domain rules or data constraints.

Approve inventory and plan first run

Mark review completion per your organization policy before scheduling production-impacting runs.

Optional: organize cases into suites for smoke vs regression batches.

Launch the first run from the wizard exit, project detail, or Operate → Runs with explicit environment confirmation.

Key concepts

Organization scope: All Zof Console and API operations are isolated to your authenticated tenant.
Governed execution: Agent output and remediation follow policy packs with human approval when configured.

Best practices

Upload requirements with numbered requirements IDs for traceability matrices
Complete review in the wizard before inviting executives to demo run results
Mirror service catalog naming from your CMDB in project titles when integrations exist
Revisit test type selection when application architecture shifts (API-only vs full web)

Common issues

Upload fails: Check file size and type against UI limits. Retry on stable network; contact admin if org storage policies block ingestion.
Wizard advances but generation is empty: Requirements may be image-only scans without extractable text, or test types were not selected. Add text criteria and retry.

Example acceptance criteria excerpt (requirements input)

REQ-PAY-014 Refund eligibility
Given a settled charge older than 30 days
When a customer requests a partial refund within policy limits
Then the Console workflow records refund intent
And audit fields capture operator ID and reason code
And declined refunds return a machine-readable denial code

Was this page helpful?