Stop Running a Full Regression Sweep on Every Seasonal Release

Salesforce ships three seasonal releases a year. Spring, Summer, Winter, on fixed dates the platform sets, not dates any single org gets to negotiate. The Summer '26 sandbox upgrade window opened around May 9, with production rollout weekends following on June 5 and June 12. Pre-release org registration had already closed by then, back on April 16.

Lay that timeline next to a full regression suite that takes two or three weeks to run properly, and the math stops working. Most teams do not talk about this gap openly. They just quietly test less than they meant to, module by module, release by release, and call it done when the clock runs out.

That is not a testing strategy. It is undocumented risk.

Why "test everything" was already a myth

A full regression sweep sounds thorough. In practice, on a three-times-a-year release cadence, it usually means one of two things happens. Either the team blows past the release date trying to finish testing, which nobody's business stakeholders will accept twice, or coverage gets quietly triaged under pressure, by whoever is running the suite that week, based on gut feel rather than any documented reasoning.

Neither is really a decision. Both are just what happens when a fixed-length process meets a fixed release date.

The fix is not more automation, though automation helps. The fix is a different question. Instead of asking "did we test everything," ask "did we test the right things, and can we show our reasoning."

A tiered, risk-based structure

Here is a framework worth adapting, built around two scores instead of one binary "did we test it" checkbox.

Impact score. If this process fails in production, what does it cost the business? Lost revenue, a broken customer-facing flow, a compliance exposure. Rate it low, medium, or high.

Change exposure score. How often does this specific area of the org actually change? Some flows, integrations, and automations get touched almost every release. Others have not changed in two years. Rate that low, medium, or high too.

The two scores should come from different people. Business or finance stakeholders are better placed to judge impact, since they know what a broken quote-to-cash flow actually costs. Technical leads are better placed to judge change exposure, since they know what has actually shipped into that part of the org recently. Scoring both from the same desk tends to produce optimistic numbers on both axes.

Cross the two scores and you get three practical tiers.

Tier 1: high impact, high exposure. Test this every single release, no exceptions. This is usually a short list: core revenue flows, anything customer-facing, anything with an active integration that changes often.

Tier 2: high impact, low exposure. Test this conditionally. Check the release notes first. If nothing in this release actually touches that area, skip it this cycle, and say so in your test plan, rather than skipping it silently.

Tier 3: low impact, low exposure. Test this on its own schedule, quarterly or twice a year, decoupled entirely from the release calendar. It does not need to be in the room every time Salesforce ships something.

What this actually buys a team

The honest benefit here is not that this saves time, although it usually does. The real benefit is that coverage becomes something you can defend. When a stakeholder asks why a particular flow was not tested this cycle, the answer is a documented tier and a change-exposure score, not "we ran out of time and hoped for the best."

That distinction matters more than it sounds like it should. Untested and undocumented is a liability. Untested and explicitly deprioritized, on the record, with a reason, is a decision your team made on purpose. Auditors, new team leads, and your own future self all treat those two situations very differently.

Making it stick

Start small. Take your current regression suite and score every test case against the two axes above, even roughly, even in a spreadsheet to begin with. You will likely find that a large share of what gets full-sweep treatment today actually belongs in Tier 2 or Tier 3.

Re-score periodically, not just once. An area that was Tier 3 last year because nobody touched it can jump to Tier 1 the moment a new integration lands on top of it. The tiers should move with the org, not sit fixed in a document nobody revisits.

Three releases a year is not going away. What is worth changing is the assumption that thorough testing has to mean testing everything, every time. It does not. It means testing the right things, on purpose, and being able to say exactly why.

---

About the author

This piece comes from the Salesforce testing team at TechForce Services, which builds risk-based QA and test automation programs for teams running Salesforce across sales, service, and marketing.