Test Management Concepts

Core concepts for effective test management in RabbitQA.

Test Case Hierarchy

RabbitQA organizes work in a nested hierarchy. The workspace is the boundary — everything below it belongs to one workspace and is invisible from another.

Company
└── Workspace
    └── Project
        └── Folder (test tree)
            └── Test Set
                └── Test Case
                    └── Test Steps

A test set groups cases for execution; folders in the test tree organize them for browsing. A case can belong to more than one set.

Test Case Structure

Essential Fields

Field	Description	Required
Title	Clear, descriptive name	Yes
Description	What the test verifies	No
Preconditions	Setup requirements	No
Steps	Sequential actions	Yes
Expected Result	Success criteria	Yes
Priority	Critical/High/Medium/Low	Yes

Test Steps

Each test step contains:

**Step 1:** Navigate to login page **Action:** Open browser and go to /login **Expected:** Login
form is displayed

**Step 2:** Enter credentials **Action:** Type username and password **Data:** [email protected] /
TestPass123 **Expected:** Fields accept input

Test Execution

Execution Status

Status	Description	Color
Pass	Test completed successfully	Green
Fail	Test did not meet expected result	Red
Blocked	Cannot execute due to blocker	Gray
Skip	Intentionally not executed	Yellow
In Progress	Currently being executed	Blue

Test Plans and Test Runs

Execution is organized in two levels rather than a single "session".

A test plan is the unit of work for a release or a cycle. It holds the scope, the target environment and the runs beneath it.

A test run sits inside a plan and is what testers actually execute. Each run carries:

Attribute	Meaning
Scope	The test cases included in the run
Environment	The environment the run targets, for example Development or Production
Assignee	Who is responsible for executing it
Platform	Web, API, Mobile or Desktop, which filters the case tree
Results	Per-case outcomes, aggregated into a run summary

An execution is one case being run once, recording a status, evidence and any defect raised.

note

Earlier versions of RabbitQA grouped runs under a Release layer, and this documentation once described a "test session". Neither is current. Test Plans replaced the Release layer, and there is no session object in test management.

Coverage Concepts

Requirements Coverage

Track which requirements have test coverage:

Requirement: REQ-001 - User Login
├── TC-001: Valid login ✓
├── TC-002: Invalid password ✓
├── TC-003: Account locked ✓
└── TC-004: Password reset ✗ (no coverage)

Coverage: 75%

Risk-Based Testing

Prioritize testing based on risk:

Risk Level	Test Priority	Coverage Target
Critical	P1	100%
High	P1-P2	90%
Medium	P2-P3	70%
Low	P3-P4	50%

Traceability

Traceability Matrix

Link requirements → test cases → defects:

REQ-001 → TC-001, TC-002 → BUG-101
REQ-002 → TC-003, TC-004 → (no defects)
REQ-003 → (no tests) → (untested)

Impact Analysis

When requirements change:

1. Identify linked test cases
2. Mark as "Needs Review"
3. Update test steps
4. Re-execute affected tests

Best Practices

Test Case Design

• Atomic - One scenario per test
• Independent - No dependencies between tests
• Repeatable - Same result every execution
• Clear - Unambiguous steps and expectations

Naming Conventions

[Module]_[Feature]_[Scenario]_[ExpectedOutcome]

Examples:
- Login_ValidCredentials_SuccessfulLogin
- Cart_AddItem_ItemAddedToCart
- Payment_InvalidCard_ErrorDisplayed

Maintenance

• Review tests quarterly
• Archive obsolete tests
• Update for new features
• Remove duplicates