User Guide / Projects & Planning

Projects & Planning

Every piece of testing work in Plan'O'Test — requirements, test cases, executions, bugs — lives inside a project. This page covers setting one up and organizing the work inside it.

Creating a project

From Projects in the sidebar, click New Project. You'll set:

  • Name and a short Key (like WEB or API) — the key becomes the prefix on generated Bug and Test Case codes if you turn on numbering for this project.
  • Status — Planning Active On Hold Completed Archived
  • Priority — Low, Medium, High, or Critical.

Archiving a project hides it from day-to-day lists without deleting anything — everything underneath it is preserved and can be unarchived later.

Members & co-owners

Add teammates to a project from its detail page. Most roles only see and act on projects they've been added to; a handful of roles (Admin, Super Admin, Project Manager) see every project in the organization regardless. A project can also have more than one co-owner if ownership needs to be shared.

Releases & milestones

A release represents a version you're shipping — v2.4, Sprint 12 Release, whatever your team calls it. Releases move through:

Planned In Progress Released Cancelled

  • Milestones — named checkpoints inside a release with an optional due date and a completed/not-completed flag, useful for tracking sub-deadlines like "Code Freeze" or "Regression Complete."
  • Release Notes — a free-text changelog attached to the release, with its own published date.
  • Release Calendar — a separate, cross-project page (in the sidebar) showing every upcoming release across every project you can see, grouped by month — useful for spotting scheduling collisions between teams.

Sprints

Sprints are time-boxed iterations inside a project, each holding a set of Stories — which are really just Requirements marked as the "functional" type, added directly from the Sprint page rather than the main Requirements screen. A sprint's progress is tracked by how many of its stories are complete, not by story points (this app doesn't have a points field).

If a sprint is marked Completed with incomplete stories still in it, those stories automatically carry over rather than getting silently dropped.

Numbering Schemes

By default, Bugs and Test Cases are just referred to by their title. If your team wants readable codes instead — BUG-00042, WEB-TC-00104 — turn on a numbering scheme for the project (its own settings screen, linked from the Project page) and set a prefix and how many digits to pad to. It only applies going forward; existing records aren't renumbered retroactively.

Who can do this: creating and editing projects, releases, and sprints is generally limited to Admins, Super Admins, and Project Managers; QA Leads can typically create releases and sprints within projects they're a member of. Everyone added to a project can view it.

Next: Requirements & Traceability →