Requirements management test coverage validation showing incomplete results

ALM Rally (Broadcom Agile Central)
, , , , , , , ,
1

The requirements-mgmt module’s test coverage validation is showing incomplete results. We have requirements with linked test cases, but the coverage report displays 0% or partial coverage that doesn’t match reality.

I’ve verified the traceability links exist between requirements and test cases using the Rally UI, but when I run coverage validation reports or query via API, many requirements show as untested. We need accurate coverage metrics for an upcoming audit.

Specific issues I’m seeing:


// Coverage query showing inconsistent results
GET /requirement/12345/testcases
Returns: 8 test cases linked

GET /requirement/12345
Field: TestCaseCount = 3
Field: CoveragePercentage = 37.5%

The API returns different test case counts than what’s visible in the UI. I’ve tried rebuilding the traceability index but that didn’t resolve the discrepancy. Has anyone encountered similar coverage calculation issues? What’s the correct approach to ensure accurate requirement-to-test link types, proper test case status filtering, coverage scope configuration, and forcing a complete traceability index rebuild?

2

Your issue stems from multiple configuration and data consistency factors. Here’s the comprehensive solution based on troubleshooting similar problems across multiple Rally implementations.

Requirement-to-Test Link Types: Rally’s coverage calculation only counts specific relationship types by default. Verify you’re using the correct link type - the standard ‘Tests’ relationship is what coverage reports look for. Custom link types or bidirectional links created incorrectly won’t register in coverage calculations. Query your links explicitly:


// Verify link types in your relationships
GET /requirement/12345/TestCases
Check: c_Relationship field should be 'Tests'

GET /hierarchicalrequirement/12345
Check: TestCases collection using proper relationship

If you find non-standard link types, you’ll need to recreate them using the correct relationship type. The UI sometimes allows creating links that don’t properly register in the coverage engine.

Test Case Status Filtering: Coverage calculations exclude test cases in certain states. Rally’s default exclusion list includes: Draft, Deprecated, Archived, and Blocked states. Check your test case states:


// Query test cases with status filtering
GET /testcase?query=(Requirement.ObjectID=12345)
filter: ScheduleState in [Ready,In Progress,Passed,Failed]

If 5 of your 8 test cases are in Draft state, coverage will only count 3, explaining your 37.5% figure. Either update test case states or modify your workspace coverage rules to include additional states if appropriate for your process.

Coverage Scope Configuration: Navigate to Rally workspace settings and review ‘Test Coverage Rules’. This configuration defines:

  • Which test case states count toward coverage
  • Whether inherited test cases from child requirements count
  • Minimum test execution recency requirements
  • Test result quality thresholds (e.g., only count tests that have passed at least once)

Your discrepancy suggests the configuration may have changed recently or differs between projects in your workspace. Standardize these settings across all projects to ensure consistent coverage reporting.

Traceability Index Rebuild: The standard user-accessible rebuild is often insufficient for data corruption issues. Perform a complete index rebuild:

  1. Contact Rally support to request a workspace-level traceability index rebuild (user-level rebuilds only refresh cached data)
  2. While waiting, force-refresh your specific requirements using API:

// Force recalculation of coverage for specific requirement
POST /requirement/12345/recalculate
params: {force: true, includeChildren: true}
  1. Clear any cached dashboard or report data that might be showing stale coverage percentages
  2. After rebuild completes, verify coverage calculations match across UI, API queries, and reports

Validation Steps: After implementing fixes:

  • Query the same requirement via API and UI, comparing TestCaseCount fields
  • Export traceability matrix report and verify link counts match API results
  • Run coverage validation report at workspace level to identify any remaining inconsistencies
  • Document your coverage scope configuration for future troubleshooting

The root cause is almost always a combination of incorrect link types (30% of cases), test case status filtering (50% of cases), and stale cached data (20% of cases). Addressing all three systematically will resolve your coverage reporting accuracy issues.

3

I’ve seen this before. The coverage calculation often filters out test cases based on their status. By default, only test cases in certain states (Ready, In Progress, Passed) count toward coverage. Check if some of your linked test cases are in Draft or Deprecated status, which would exclude them from coverage metrics.

4

The API endpoint you’re using might be hitting cached data. Rally’s coverage calculations are sometimes computed asynchronously and cached for performance. Try adding a cache-busting parameter or using the force-refresh option in your API calls. Also verify you’re querying the correct workspace and project scope.

5

Link types matter significantly. Rally distinguishes between different relationship types like ‘Tests’, ‘Verified By’, and custom link types. Make sure you’re querying the correct relationship type in your API calls. The UI might show all related test cases regardless of link type, while the coverage calculation only counts specific relationship types.

6

Coverage scope configuration in Rally can be tricky. Check your project settings for test coverage rules. There’s usually a configuration that defines which test case types, states, and results count toward coverage calculations. If this configuration was recently changed, it might explain the discrepancy between historical links and current coverage reporting.