Project

Where to draw the boundary

One project per product or application that ships on its own schedule is the default that holds up best. The signals that something deserves its own project are separate releases, separate requirements and a separate group of people who need access. A web app and a mobile app of the same product can share one project if they release together from shared requirements, and should be split if they ship independently.

Too many, too few

Too many projects and the same login flow is tested in five places, each copy drifting from the others, and every management question needs a cross-project report. Too few and a single project holds everything: access cannot be scoped, every report needs filters, and a milestone for one product fills up with runs from another. Of the two, too many is harder to undo, because merging projects means merging libraries and the duplicates that come with them.

Settings live at project level

Custom fields, execution statuses, the tracker connection and access are usually configured per project. Two projects for one product will drift apart in those settings unless someone owns both, which is one more reason to keep a product in one place.

In QAM Hub

Projects sit inside an organization. Each project has its own roles (Admin, User, Viewer), its own custom fields and custom statuses, its own tracker connection, and modules for automation, requirements and checklists that can be switched on or off. The project slug appears in every URL, so renaming a project is safe but changing the slug breaks bookmarks. A deleted project goes to the Archive and can be restored for 14 days. Setup is in creating your organization and first project.