Projects Overview

Projects are the top-level containers that separate your testing work into distinct, self-contained spaces.

Overview

Every test suite, test case, test run, and defect in Qase belongs to a project. Think of projects as boundaries — they prevent your mobile app regression cases from mixing with your API integration tests.

A common setup: one project per product or platform. If you maintain a web app, an iOS app, and an Android app, create three projects. Each gets its own repository, its own runs, and its own team access controls.

Creating a project

Click Create New Project from the Projects view. You'll configure four things:

Project Name — A descriptive name visible everywhere in Qase.
Project Code — A 2–10 character identifier (Latin letters and digits only). This becomes the prefix for every test case ID in the project — a project with code PAY will have cases PAY-1, PAY-2, etc. Choose something short and recognizable; it can be changed later.
Description — Optional context for your team about the project's scope.
Project Access — Controls who can see and work in this project:

Access type	Who gets access
Public	Every current and future workspace member
Private — Add all members	Every current member (new members added later need manual access)
Private — Group access	Only members of a selected user group
Private — Don't add members	Only you (the creator) until you grant access

For most teams, we recommend starting projects as Private with group access. It keeps things controlled without requiring per-person management. Workspace owners can always view all projects, including private ones.

Project settings

Open any project and navigate to Settings to configure its behavior.

General

Edit the project name, code, description, and image. This is also where you see the project's unique identifier used in API integrations.

Repository

Delete confirmation — When enabled, bulk-deleting test cases requires typing CONFIRM to prevent accidents. We recommend keeping this on.
Review settings — Enable test case review to require approval before cases are merged. Configure whether review is mandatory, whether self-merge is allowed, and the minimum number of approvals required.
Show clone links — Displays a hyperlink from cloned cases back to their original.

Test run

Settings that control how runs behave in this project — completion rules, auto-assignment, and result behaviors.

Test case

Toggle visibility of specific fields (milestone, tags, dataset) per project. Set the default step type (Classic or Gherkin).

Webhooks

Configure webhooks to notify external systems when events occur in the project — case creation, run completion, defect filing, etc.

Access control

Manage project access from Settings → Access control. For private projects, you can:

Add groups — Grant access to entire user groups. All current and future members of those groups get project access automatically.
Add individual members — Grant access to specific people regardless of their group membership.
Change the project owner — Transfer ownership to another workspace member.

Individual access is stable — it persists even if group memberships change. Group access is dynamic — when someone joins or leaves the group, their project access updates automatically. Use individual access for key stakeholders and group access for teams.

Archiving projects

Completed projects can be archived from project settings. Archived projects are hidden from the default Projects view but remain fully accessible — switch to the Archived or All filter to find them.

Archiving doesn't delete anything. It's a visibility toggle for keeping your active project list clean.

Milestones

Milestones mark specific points in your release or development cycle — sprint boundaries, version releases, or any deadline your team tracks.

Why milestones matter

Without milestones, test runs and defects exist in a flat timeline. Milestones add a dimension: you can see which test cases were validated for v2.1, which defects were found during Sprint 14, and whether a release candidate has been fully tested. They turn isolated test data into release-scoped progress tracking.

Creating a milestone

Navigate to the Milestones section within your project and click Create Milestone. Each milestone has:

Field	Purpose
Name	The milestone label (e.g., “v2.1 Release” or “Sprint 14”)
Description	Context about what this milestone covers
Status	Active or Completed
Due Date	The target completion date

Linking milestones

Once created, milestones can be applied to:

Test cases — Set the milestone field when creating or editing a case. Use bulk edit to assign a milestone to many cases at once.
Test runs — Select a milestone during run creation to scope the run to a release.
Defects — Attach a milestone when filing a defect to track which release it was discovered in.

Tracking progress

The Milestones list shows the count of linked test cases for each milestone. Use this to gauge coverage: if your “v2.1 Release” milestone has 200 linked cases and 180 have passing results in the latest run, you have a clear picture of release readiness.

Sort milestones by name, status, or due date to find what you need.

Project views

The Projects page supports two layouts:

List view — Compact rows showing project name, unresolved defects, run count, milestones, and team size. Includes a menu for editing settings or deleting the project.
Card view — Visual cards with the same summary data.

Star a project to mark it as a favorite — favorites sort to the top in both views.

FAQ

Can I change a project code after creation? Yes. Project code can be changed from the project's settings. But, please be careful - this may break integrations that you may have setup.

What's the difference between archiving and deleting a project? Archiving hides the project from the default view but preserves everything. Deleting removes the project and all its data permanently. Archive first; delete only when you're certain.

Can a test case belong to multiple projects? No. Each case lives in exactly one project. To reuse cases across projects, clone a test suite into the target project.

Who can see private projects? Only members explicitly granted access (individually or via groups), plus workspace owners who can see all projects.

Can milestones span multiple projects? No. Milestones are project-scoped. If you need cross-project tracking, use dashboards to aggregate data across projects.