---
title: Regression suites that only grow | qventis blog
description: Suites grow because adding feels safe and deleting feels risky. Why tag filters do not fix it, and how to select tests as a plan with a purpose and a budget.
---

[Skip to content](https://qventis.ai/blog/regression-suites-that-only-grow#main)

[![qventis](https://qventis.ai/hubfs/raw_assets/public/qventis-one/images/qventis-logo.svg)![qventis](https://qventis.ai/hubfs/raw_assets/public/qventis-one/images/qventis-logo-reverse.svg)](https://qventis.ai/)

- Product
  
  [**Qventis Engine**Any app, any stack, in plain English. Zero AI tokens at run time.WebDesktopTerminalAPIDataOne plain-English suite](https://qventis.ai/engine)
  
  [**Qventis One**One pane of glass across every app](https://qventis.ai/one) [**App Model**Your app, learned once](https://qventis.ai/one/app-model) [**Quality View**Live quality signals and alerts](https://qventis.ai/one/quality-view) [**Agent gateway**Coding agents create and update tests](https://qventis.ai/platform/agent-gateway)
  
  [**Studio**Write tests in plain English](https://qventis.ai/platform/studio) [**Eight engines**Functional to accessibility](https://qventis.ai/one#engines) [**Integrations**CI, ALM and chat](https://qventis.ai/platform/integrations) [**Trust and security**People approve every AI change](https://qventis.ai/platform/trust)
  
  How it works[Detect](https://qventis.ai/release-intelligence)→[Assess](https://qventis.ai/one/app-model)→[Automate](https://qventis.ai/engine)→[Assure](https://qventis.ai/one/quality-view)
- Enterprise apps
  
  [**Release Intelligence**Every vendor update read, traced to your processes and tested before it lands.PreviewTestProdNextImpact known before the window opens](https://qventis.ai/release-intelligence)
  
  [**Oracle**Quarterly updates](https://qventis.ai/platforms/oracle)[**Workday**R1 and R2](https://qventis.ai/platforms/workday) [**SAP**S/4HANA releases](https://qventis.ai/platforms/sap)[**Salesforce**Three a year](https://qventis.ai/platforms/salesforce) [**ServiceNow**Family releases](https://qventis.ai/platforms/servicenow)[**Dynamics 365**Release waves](https://qventis.ai/platforms/dynamics-365) [**nCino**Two calendars](https://qventis.ai/platforms/ncino)[**Coupa**Major releases](https://qventis.ai/platforms/coupa) 
  
  [**All 40+ apps**ERP, HCM, CRM, ITSM, banking, insurance](https://qventis.ai/engines/packaged-apps)
  
  [**Release testing**Test only what a change affects](https://qventis.ai/solutions/release-testing) [**Industries**Regulated and complex businesses](https://qventis.ai/industries) [**Legacy desktop**Apps automation never reached](https://qventis.ai/solutions/legacy-desktop) [**Quality CoE**One standard across the business](https://qventis.ai/solutions/quality-coe)
- Learn
  
  [**Blog**Field notes on releases, quality and AI](https://qventis.ai/blog) [**Briefs**Platform briefs by email](https://qventis.ai/resources) [**Customers**Example scenarios by role](https://qventis.ai/customers) [**Support**Guides for customers](https://qventis.ai/support)
- Company
  
  [**About qventis**Why we built one platform](https://qventis.ai/about) [**Editions**Start with one need, grow](https://qventis.ai/editions) [**Contact**Send us a request](https://qventis.ai/contact)

Search platforms, releasesCtrl K

[Book a demo](https://qventis.ai/contact#demo)

[Blog](https://qventis.ai/blog)/STLC pitfalls

# Regression suites that only grow

Suites grow because adding feels safe and deleting feels risky. Why tag filters do not fix it, and how to select tests as a plan with a purpose and a budget.

qventis teamSeptember 22, 2026

Regression suites in enterprise programs follow a familiar curve. Each project adds tests for what it built. Each escaped defect adds a test so it never happens again. Each vendor update adds a few more. Very little is ever taken out.

For a while this is fine. Then the nightly run spills into the morning, then into the weekend. The full suite becomes something run before major releases, if at all. Day to day, people run a subset chosen by tag, by folder or by memory. Nobody can say exactly what that subset covers.

## Why suites only grow

- **Adding is rewarded, removing is risky.** No one is blamed for an extra test, while the person who deleted the one that would have caught a defect is easy to find
- **Tests lack a reason.** Without a link to a requirement or process step, no one can tell whether a test still matters
- **Duplicates go unnoticed.** Different teams write tests for the same step and expected result in different words
- **Retired behavior lingers.** When a vendor removes a feature, the tests for it keep running, or keep being skipped

## Why tag filters do not fix it

The usual response is to tag tests, such as smoke, payables or critical, and run subsets by tag. Tags help organize. As a selection method they have three weaknesses.

First, a filter selects by label, not by purpose. "Run everything tagged payables" says nothing about what question the run is meant to answer. Second, tags rot. They are applied once, by whoever wrote the test, and rarely revisited when the test or the application changes. Third, a filter has no budget. It runs whatever matches, however long that takes, and gives no guarantee that the most important risks were covered first.

## Start from the question

A better approach treats selection as a plan. A plan starts from a purpose and a constraint, then works out which tests best serve that purpose within that constraint. Different questions produce different plans from the same suite.

| Plan | Purpose | How tests are chosen |
| --- | --- | --- |
| Monday health check, 60 minutes | Is anything critical broken? | Blockers and one pass through each critical chain, ranked by risk, until the hour is used |
| Quarterly update certification | What did this update change? | The test delta for the update, in execution waves |
| SOX audit evidence | Do key controls still hold? | Every check tied to a control's expected result, with evidence retained |
| Change to one integration | Did this change break its neighbors? | Steps on both sides of the handoff, plus their chains |

Each plan states what it is for, how long it may take and what it will cover. When it finishes, it can also state what it did not cover, which is just as important.

## What a plan uses to select

Good selection draws on several signals at once, weighted by the plan's purpose:

- **Change.** Which modules, steps and objects were touched by a deployment, configuration change or vendor update
- **Risk.** The impact score of the change and the business criticality of the process step
- **Coverage.** Each critical process step checked at least once before any step is checked twice
- **History.** Tests that failed recently or cover areas with recent defects
- **Cost.** How long each test takes, so the budget is spent where it buys the most

The coverage rule is what separates a plan from a ranked list. A plan with a 60-minute budget should not spend 50 minutes on the riskiest module and leave three critical chains untouched. It should spread across the process steps that matter, then go deeper where time allows.

## Prune with evidence

Selection keeps runs fast. The suite still needs to shrink where it has grown without reason. With step-level traceability in place, pruning becomes a review rather than a gamble.

- Retire tests for behavior a vendor has removed, using the release content as the reason
- Merge tests that check the same step and expected result
- Review tests that trace to no requirement or step, and either record what they cover or retire them
- Keep retired tests in history, so a decision can be reversed

Pruning based on evidence is easy to defend. "This test checked a page the vendor retired last quarter" is a reason anyone can accept.

## Report the plan, not just the results

A run report usually lists passes and failures. A plan-based report adds three things: what the plan was for, what it covered, and what it deliberately left out. A release owner reading "Monday health check passed, all critical chains covered, payables reports not included this week" knows far more than one reading "312 passed, 4 failed".

## How Qventis One helps

Test Selector in Qventis One builds a plan, not a filter. Plans such as "Monday health check, 60 minutes" or "SOX audit evidence" choose tests from the App Model by change, risk, coverage, history and run time, and report what they covered and what they left out. Release Intelligence adds a retire list to every test delta, so the suite shrinks where vendor behavior is gone, and Quality View shows the plan alongside its results. [Book a demo](https://qventis.ai/contact#demo) to see a plan built from your own suite.

**The Qventis Engine** automates any app in plain English with zero AI tokens at run time. Qventis One scales it to one view of quality.

[Book a demo](https://qventis.ai/contact#demo)

More in STLC pitfalls

### [Oct 9, 2026 End-to-end handoffs: the accrual that never clears Every module passed its tests, yet the receipt accrual never cleared. Why handoffs between modules and systems go untested, and how chain tests catch them.](https://qventis.ai/blog/end-to-end-handoffs-accrual-that-never-clears)

### [Sep 8, 2026 Test data bottlenecks in shared environments Shared test environments turn data into the slowest part of testing. Six provisioning strategies, when each fits, and how to stop tests colliding.](https://qventis.ai/blog/test-data-bottlenecks-shared-environments)

### [Aug 21, 2026 Flaky tests: classify failures by cause Flaky is a symptom, not a diagnosis. How to classify every failed check by cause, from data and environment to timing and vendor change, using evidence.](https://qventis.ai/blog/flaky-tests-classify-failures-by-cause)

[![qventis](https://qventis.ai/hubfs/raw_assets/public/qventis-one/images/qventis-logo.svg)![qventis](https://qventis.ai/hubfs/raw_assets/public/qventis-one/images/qventis-logo-reverse.svg)](https://qventis.ai/)

[Support](https://qventis.ai/support)[Trust](https://qventis.ai/platform/trust)[Privacy and terms](https://qventis.ai/legal)Contact

© 2026 qventis.aiThird-party product names are trademarks of their respective owners.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "qventis team",
    "url" : "https://qventis.ai/blog/author/qventis-team"
  },
  "dateModified" : "2026-10-11T09:03:21.326Z",
  "datePublished" : "2026-09-22T15:00:00.000Z",
  "headline" : "Regression suites that only grow | qventis blog",
  "mainEntityOfPage" : {
    "@id" : "https://qventis.ai/blog/regression-suites-that-only-grow",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject"
    }
  }
}
```