Console
Projects
Organize reliability work under projects tied to applications and teams.
Overview
Projects are the primary organizing unit for reliability work in Zof Console. A project binds an application, requirements or specifications, generated and authored tests, execution history, reports, and, when enabled, release gate context for a single initiative.
Strong project hygiene improves searchability, access control, and stakeholder reporting. Name projects for operational clarity (product area + initiative + period), assign team ownership, and archive completed initiatives rather than leaving stale inventory active.
The project wizard guides first-time setup; mature teams also create projects programmatically via API for pipeline-driven onboarding. Both paths converge on the same review-before-execute discipline.
Who should read this
- QA engineers, SREs, platform teams, and developers operating Zof Console and APIs.
Prerequisites
- Permission to create or view projects in your organization
- At least one registered application or URL target for web validation
- Optional: requirements document ready for upload during wizard setup
When to use this workflow
- Starting a new product initiative or major feature reliability program
- Isolating execution history and coverage for a specific application release train
- Separating staging experimentation from production-critical validation inventory
Project lifecycle
Project lifecycle
Projects move from creation through governed generation, execution, analysis, and archival.
Step-by-step procedure
Open the Projects list
From the left navigation, open Projects or use ⌘K and search for your project name.
Filter by team, status, or application when the list grows large in enterprise tenants.
Review archived projects separately when auditing historical release evidence.
Inspect project detail structure
Project detail typically includes overview, requirements linkage, scenarios and cases, runs, and settings tabs.
Confirm the linked application URL and environment metadata match your intended execution target.
Verify team ownership for escalation paths when runs fail during on-call.
Maintain requirements linkage
Attach or refresh requirements when product behavior changes to keep generation and coverage honest.
Prefer specification records for long-lived documents shared across multiple projects.
Trigger regeneration or manual library edits after major requirement updates.
Govern test inventory inside the project
Review scenarios and cases before adding them to suites used in production schedules.
Use consistent naming conventions (see test scenarios documentation) for cross-project search.
Deprecate obsolete cases rather than deleting history tied to prior runs.
Execute and monitor project-scoped runs
Start runs from project detail or Operate → Runs with project filter applied.
Compare consecutive runs when investigating regressions after deployments.
Export artifacts from run detail when attaching evidence to change requests.
Report and archive
Generate project-scoped reports for milestone reviews or audit requests.
When an initiative completes, archive the project to reduce clutter while retaining historical runs.
Document archive decisions in your change management system for traceability.
Key concepts
- Project
- Initiative-scoped container linking application, requirements, tests, runs, and reports.
- Project wizard
- Guided flow for create → requirements → test types → generation → review.
- Archive
- Soft lifecycle end state preserving history while hiding active worklists.
Best practices
- One project per initiative or release train, not per individual test case
- Mirror application team ownership on the project for accountable escalation
- Re-run coverage analysis after requirement changes before declaring release readiness
- Use API project creation in CI templates for standardized service onboarding
Common issues
- Cannot see a colleague project
- Team or role scope may exclude it. Confirm project team assignment and your role permissions.
- Generation produces irrelevant cases
- Requirements may lack acceptance criteria detail. Enrich requirements and regenerate, then human-review output.
Was this page helpful?