Skip to content

Test Suites Best Practices & Use Cases

2 min read

Test suites help you control what gets executed, when, and why. A well-structured test suite strategy reduces maintenance effort while improving execution reliability.

This guide outlines recommended practices and common use cases.


  1. Logical Grouping
    Group test cases by feature, module, workflow, or business capability.

  2. Clear Naming
    Use names that clearly reflect intent, such as:

    • Login – Smoke
    • Payments – Regression
    • Calendar – High Priority
  3. Meaningful Descriptions
    Describe why the suite exists and when it should be used.

  4. Reusability First
    Design suites so they can be reused across multiple test runs and releases.


Manual selection is best when test inclusion must be explicit and stable.

Recommended when:

  1. Selecting critical-path test cases
  2. Creating fixed regression or certification suites
  3. Defining smoke suites with a small, known set
  4. Ensuring specific test cases always execute

Why manual works well:

  • Predictable execution
  • No dependency on metadata
  • Ideal for release gates

Filters are ideal for dynamic and evolving test coverage.

Recommended when:

  1. Test cases change frequently
  2. Coverage should grow automatically
  3. Grouping is rule-driven instead of curated

Common filter strategies:

  • Priority-based (e.g., High, Critical)
  • Status-based (e.g., Active)
  • Tag-based (e.g., smoke, api)
  • Folder-based (entire modules or features)
  • Custom field–based

Why filters work well:

  • Minimal maintenance
  • Automatically includes new matching test cases
  • Ideal for large or fast-moving repositories

Hybrid test suites combine manual selection (green) and filters (violet).

Best practices:

  1. Manually include non-negotiable test cases
  2. Use filters for coverage expansion
  3. Allow deduplication to handle overlaps automatically
  4. Review filters periodically, not manually selected tests

Result:

  • Stable core
  • Flexible growth
  • Minimal upkeep

  1. Create a suite per feature
  2. Use folder or tag-based filters
  3. Manually add critical edge cases
  4. Execute during feature validation cycles

  1. Create a regression suite
  2. Manually include historically sensitive test cases
  3. Add filters for high-priority or critical tests
  4. Run regularly or before releases

  1. Create a small, fast-executing suite
  2. Manually select essential workflows
  3. Keep the suite intentionally small
  4. Use it post-deployment or post-build

  1. Tag test cases by environment
  2. Use filters to include environment-specific tests
  3. Manually add exceptions if needed
  4. Execute environment-aligned suites

  1. Create suites by test type (manual vs automated)
  2. Use filters to separate automation-ready tests
  3. Maintain suites aligned with testing phases
  4. Avoid duplicating suites unnecessarily

  • Review filters periodically
  • Remove unused or obsolete suites
  • Avoid deeply nested or overly broad filters
  • Keep suite sizes manageable
  • Don’t create a suite for every minor scenario
  • Prefer fewer, purposeful suites
  • Let filters do the heavy lifting

  1. Overly complex filters
    Keep rules simple and readable.

  2. Manual-only everywhere
    This increases maintenance effort over time.

  3. Unclear suite intent
    Always document why a suite exists.

  4. Ignoring hybrid capability
    Hybrid suites are often the most practical choice.