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 codePAYwill have casesPAY-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
CONFIRMto 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.