QA & Testing

Test Case Management

Build and maintain a structured test library — create cases with numbered steps, organize them into nested folders, import from Excel, and keep full version history.

8 min read

Creating Test Cases

Navigate to Test Cases in the project sidebar and click + New Test Case. Fill in the fields below and save.

FieldOptionsDescription
TitleShort, action-oriented summary — e.g. "User can log in with valid credentials"
DescriptionContext and scope: what feature or flow this test covers
PreconditionWhat must be true before execution starts — user role, test data, environment state
StepsNumbered steps a tester follows. Each step should be a single, concrete action.
Expected ResultThe observable outcome that confirms the test passed
PriorityCritical / High / Medium / LowControls ordering within a test run — Critical cases run first
StatusActive / Passed / FailedLifecycle state of the case itself, not a run result
FolderThe suite this case belongs to — used for filtering and bulk run selection
Write steps in the imperative mood: Click the Login button, not The user should click…. Concrete steps make execution faster and failure notes far more precise.

Keyboard navigation

When a test case detail panel is open, press the and arrow keys to jump to the previous or next test case without closing the panel.

Folders & Organization

Group test cases into a folder hierarchy that mirrors your product structure. Folders nest to any depth and collapse in the sidebar for a clean overview.

Creating and managing folders

  • Click the folder icon next to any suite, or right-click an existing folder and choose Add subfolder.
  • Drag and drop test cases between folders at any time — order is preserved.
  • Rename or delete a folder from its context menu. Deleting a folder moves its cases to the parent folder.
  • Selecting a folder filters the case table — only cases in that folder (and its children) are shown.

Search and filter

  • Use the search bar at the top of the Test Cases page to filter by title, description, or steps.
  • Combine the folder filter with the search bar to narrow results to a specific suite.
  • Filter by priority to quickly isolate Critical or High cases for a focused run.
Aim for suites of 20–50 cases each, named after features or user flows — Authentication, Checkout, Admin Panel. A flat list of hundreds becomes unmanageable quickly.

Bulk Import & Export

Importing from Excel

1

Prepare your spreadsheet

Create an Excel file (.xlsx or .xls). The first row must be a header row with these column names exactly: title, priority, description, steps, expected_result. You may also include a precondition column.

2

Fill in your data

Each subsequent row is one test case. Required columns: title, priority, description, steps, expected_result. Priority must be one of: critical, high, medium, low.

3

Upload the file

In the Test Cases page, click Import from Excel (visible to workspace admins). Select your file — Everia validates all rows before inserting.

4

Confirm the import

If any row is missing a required field, Everia reports the row number and stops. Fix the issue in your file and re-upload. On success, all cases are added to the project immediately.

Importing from Jira or TestRail

Export your existing test cases from Jira or TestRail as an Excel file, then map their column names to Everia's required headers (title, priority, description, steps, expected_result) before uploading.

Import a batch of 10–20 cases first to verify column mapping before migrating your entire library.

Exporting to Excel

  • Select the test cases you want to export using the checkboxes in the case table.
  • Click Export to Excel — a download starts immediately.
  • The export includes all fields: title, description, precondition, steps, expected result, priority, and status.
  • Use exports for compliance audits, stakeholder reviews, or migration backups.
Import is available to workspace admins only. Any team member can export cases they can view.

Traceability & Coverage

Link every test case to the tickets and requirements it validates. Traceability ensures nothing ships untested and makes release sign-off faster.

Linking to board tickets

  • Open a test case and use the Link panel on the right to attach one or more board tickets.
  • Search by ticket number or title to find the right item.
  • The linked ticket shows the test case in its detail sidebar — creating a bidirectional trace.
  • When a bug ticket is filed from a failed test run, the link is created automatically.

Linking to KnowHub pages

  • Link test cases to requirement or spec pages in KnowHub from the same panel.
  • This lets you trace from a business requirement all the way through to the test result.

Coverage view

The Coverage dashboard shows what percentage of your tickets and KnowHub specs have at least one linked test case. Check it before a release to spot untested areas and close the gaps before they become production incidents.

Version History

Every save creates a new version of the test case automatically — there is nothing to configure.

  • Click the clock icon on any test case to open the full version timeline.
  • Click any version entry to preview the exact content at that point in time.
  • Click Restore to revert — the current version is preserved as a new entry, so nothing is lost.
  • All versions record who made the change and when — essential for compliance audits.
Version history is retained indefinitely. Only structured test case content is versioned — large file attachments are not included in version snapshots.

Best Practices

One assertion per test case

Cases that check a single behaviour are easier to maintain and give clearer failure signals. Split compound checks into separate cases.

Use a consistent naming pattern

"[Subject] can/cannot [action] when [condition]" keeps the library scannable. Example: "Guest cannot add items to cart when not logged in".

Always fill in Precondition

State the required user role, test data, and environment at the top so no tester is blocked at step 1. A missing precondition wastes everyone's time.

Prioritise deliberately

Reserve Critical for cases that, if failed, would block a release entirely. Don't mark everything Critical — it dilutes the signal.

Review after each sprint

Mark stale cases as Needs Review so the library stays execution-ready. A stale test library is a liability, not an asset.

Link before you run

Establish traceability links before a test run, not after. Linked runs produce meaningful coverage reports; unlinked runs produce noise.

Ready to try it yourself?

Start free — no credit card required. GDPR compliant.