PractiTest Test Management: Getting Started
PractiTest is a cloud-based test management platform built around a hierarchical model: Requirements feed into Test Cases, which are grouped into Test Sets, which are executed as Test Runs. Understanding that hierarchy upfront saves a lot of confusion when you start configuring your first project.
Creating a Project
After signing in, go to Settings > Projects > New Project. You fill in a name, key (used as a prefix for all entity IDs in that project, e.g. PT-123), and optionally a description. PractiTest separates projects completely -- test cases, custom fields, and integrations are all scoped to a single project.
Once the project exists, set up team access under Settings > Members. Roles matter: a "Tester" can execute test runs but cannot create or delete test cases. A "Manager" gets full CRUD access. Assign roles carefully -- over-permissioning a large QA team creates cleanup problems later.
Defining Test Cases
Navigate to Tests > Test Library. Click New Test. Each test case has:
- Name -- required, shows up in all reports.
- Description -- freeform, supports markdown.
- Steps -- ordered list of step + expected result pairs.
- Custom fields -- any fields your project administrator defined (more on this below).
Steps are the core of PractiTest's execution model. Each step gets its own pass/fail status during a run. If step 3 fails, steps 4 and 5 still get executed and marked. This captures partial results rather than stopping on first failure.
A practical test case for a login flow looks like this:
| Step | Description | Expected Result |
|---|---|---|
| 1 | Navigate to /login | Login form is displayed |
| 2 | Enter valid username and password | Fields accept input |
| 3 | Click "Sign In" | User is redirected to dashboard |
| 4 | Verify username shown in nav | Correct username appears in top right |
Organizing with Custom Fields
Custom fields are one of PractiTest's strongest features. Go to Settings > Custom Fields and create fields at the project level. Field types include: Free Text, Dropdown, Multi-Select, Date, Integer, and User.
Useful custom fields for most teams:
- Component (Dropdown):
Auth,Checkout,API,Mobile-- lets you filter the test library by area. - Automation Status (Dropdown):
Manual,Automated,Planned-- tracks which tests have automated equivalents. - Priority (Dropdown):
P0,P1,P2-- separate from severity, used for execution ordering. - Test Owner (User): assigns accountability for maintaining the test.
Once fields are defined, you can filter the test library by any combination. A filter like Component = Checkout AND Automation Status = Manual AND Priority = P0 gives you the manual checkout tests that should be automated next. Save that filter -- PractiTest lets you store named filters and share them with the team.
Building Test Sets
A Test Set is a collection of test cases selected for a specific execution cycle -- a sprint's regression scope or a release candidate's smoke suite.
To create one: go to Test Sets > New Test Set. Add tests using the filter panel on the left -- you can drag individual tests or add all results from a saved filter. Each test instance in a set is independent. The same test case can appear in multiple sets with separate execution history.
Test Sets also support custom fields. Add a Release field to tag which release a set belongs to, and an Environment field for Staging, Production, QA. This makes report filtering meaningful when you have 50 test sets across 10 releases.
Running Test Sets
When you're ready to execute, open a Test Set and click Run. PractiTest creates a Test Run -- a snapshot of the set at that point in time. Testers work through each test instance, marking each step as Pass, Fail, Blocked, or No Run.
For failed steps, testers can attach screenshots and log a defect. If you have Jira integrated, a Jira issue gets created automatically from that attachment.
The execution screen shows progress in real time: a progress bar at the top counts completed instances. Managers watching the run dashboard see the same view.
Filters as a Workflow Tool
PractiTest's filter system works across all entity types: requirements, tests, test sets, and runs. Filters are combinable with AND/OR logic, and results update live as tests are executed.
A useful workflow pattern: create a filter on Test Runs for Status = Failed AND Assigned To = Me. Share that URL with testers. They open it at the start of each day and see only their assigned failures from the last run -- no manual sorting required.
Next Step
Create one project, define 5-10 test cases with at least two custom fields (Component and Priority), and run them once manually. The execution data from that first run is what makes PractiTest's reporting useful -- without real run data the dashboards show nothing. Once you have run data, connect Jira and the traceability matrix becomes immediately valuable.
