Qase organises testing around a small set of objects that mirror how QA actually works: you define what to test, execute those tests, and track what broke.
Understanding how these objects connect saves you from fighting the tool later.
The Object Hierarchy
Everything in Qase lives inside a Project. Projects don't share data — each has its own repository, runs, defects, and team access settings.
If you're testing multiple products, create separate projects.
How They Connect
This is the cycle most teams repeat: define cases, group them into plans, execute runs, record results, file defects, fix the bugs, run again.
Qase is built around making that loop fast and traceable.
Projects
A project is a boundary. It contains your test repository, all run history, defects, dashboards, and integrations. Think of it as the container for a single product or application.
Most teams create one project per product. If you maintain separate mobile and web apps with different release cycles, those are separate projects. If they share a backend and release together, one project with suites for each platform usually works better.
Suites
Suites are folders for your test cases. They can nest — Payments > Checkout > Guest Checkout — and there's no hard depth limit, though we recommend staying under three levels to keep navigation usable.
Suites exist purely for organization. They don't affect how tests execute or how results roll up.
Test Cases
A test case is the atomic unit of your testing strategy. At minimum, it has a title. A thorough case includes preconditions, steps with expected results, priority, severity, and automation status.
Cases live in suites but can appear in multiple test plans and runs. Editing a case updates it everywhere — there's one source of truth in the repository.
When you run a case, Qase creates a snapshot so historical results always reflect what the case looked like at execution time.
Test Plans
A test plan is a named, reusable collection of test cases. It answers the question: "What should we test for this scenario?"
Plans are optional. You can create runs by picking cases directly from the repository.
But for any test set you'll repeat — regression, release certification, sprint exit — a plan saves time and ensures consistency.
Test Runs
A test run is an execution event. It tracks which cases are being tested, who's assigned to each, and what the outcomes are. Every run captures a point-in-time snapshot of the included cases.
A run also carries context: which environment (staging, production), which milestone (v2.1 release), and which configuration (Chrome, Firefox) it targets.
Results
A result is the outcome of a single test case within a single run. It records the verdict — passed, failed, blocked, skipped, or invalidated — along with time spent, comments, attachments, and step-level detail.
Results are immutable. They form the audit trail that feeds dashboards and traceability reports.
Defects
A defect is a bug tracked inside Qase. Defects can be created standalone or linked directly from a failed test result. When you fail a case during a run, Qase prompts you to create or link a defect.
If you have an issue tracker integration, the defect can sync to an external issue automatically.
Defects have their own lifecycle: open, in progress, resolved, or invalidated.