How to Set Up Test Case Execution Tracking in qTest: A Practical Guide

Problem: Tracking Test Execution Status Across Manual Test Runs

When executing manual tests in qTest, you need a reliable way to record pass/fail/block status, capture execution notes, and maintain traceability to requirements and defects. Without proper execution tracking, test results become scattered across spreadsheets and emails, making it difficult to generate accurate quality reports or identify defect patterns.

Prerequisites

• qTest Professional or Enterprise edition with Test Management module enabled
• Active user account with "Test Execution Manager" or "Administrator" role
• Existing test cases created in the Test Management module
• Requirements and defects configured (optional but recommended for traceability)

Procedure: Creating and Configuring Test Executions

1. Navigate to Test Executions

   Go to Test Management > Test Executions in the qTest main navigation. You'll see the executions dashboard showing any existing test runs.

2. Create a New Test Execution

   Click + New Test Execution. Enter a descriptive name (e.g., "Regression Sprint 23 - Build 1.4.5"), select the appropriate test cycle, and set the execution date range. Save the execution.

3. Add Test Cases to the Execution

   Within your new execution, click Add Test Cases. Use filters to select test cases by priority, module, or test suite. You can add individual cases or entire test suites at once. For bulk operations, select multiple cases using checkboxes and choose "Add Selected"

4. Execute Test Cases

   Open each test case in the execution by clicking its row. For each step:

   • Select status: Pass, Fail, or Blocked
   • Add execution notes in the provided text area
   • Attach relevant screenshots by clicking the paperclip icon
   • Link defects using the Link Defect button if a failure is found
   Click Save after each test case execution.

5. Configure Execution Settings for Reporting

   Before finalizing, click the Settings gear icon. Enable "Link to Requirements" if you need traceability. Set up custom fields if your team uses specific defect categories or severity levels.

Expected Checks and Verification

After completing test executions, perform these verification steps:

• Status Aggregation: Navigate to Reports > Test Execution Summary. Verify that pass/fail/block counts match your manual records.
• Requirement Traceability: Open a requirement and check the "Test Executions" tab. Confirm that related test cases show their execution status.
• Defect Linking: Visit the defect module and open a linked defect. Verify it shows the test execution where it was discovered.
• Data Persistence: Refresh the page or log out and back in. Ensure all execution data, notes, and attachments remain intact.

Recovery Options

If execution data appears lost or corrupted:

1. Check User Permissions: Verify your role has write access to test executions. Contact your qTest administrator if unsure.
2. Browser Cache Issues: Clear your browser cache and cookies, then log back into qTest. Some execution data may not persist in certain browser configurations.
3. Network Interruptions: If your internet connection dropped during execution, unsaved changes may be lost. Always click Save after each test case.
4. Large Execution Performance: For test executions with 100+ test cases, consider breaking them into smaller executions (25-50 cases each) to prevent timeout issues during data saving.

Key Limitations to Consider

Be aware of these constraints when planning your test execution strategy:

• Attachment Size Limits: qTest may restrict individual screenshot sizes (typically 10MB max). Compress large images before attaching.
• Concurrent Editing: Multiple testers cannot simultaneously edit the same test execution. Coordinate access or use separate executions for parallel testing.
• Export Capabilities: Basic editions may not support exporting execution results to external formats. Check your edition's documentation for export options.
• API Rate Limits: If integrating with CI/CD pipelines, be aware of qTest API rate limits that may affect automated execution reporting.

Practical Example: Manual Regression Testing

For a typical 30-test-case regression suite:

Test Execution Name: "Sprint 23 Regression - Build 1.4.5"
Test Cases: 30 (selected from Test Suite "Core Functionality")
Execution Time: 2 hours (4 testers, 8 cases each)
Expected Outcome: 25 Pass, 3 Fail (linked to defects), 2 Blocked
Verification: Run Test Execution Summary report to confirm 100% coverage

This approach ensures all execution data is centralized, traceable, and ready for quality metrics dashboards.