The testing problems every Salesforce SI runs into, the fixes that work with any tool, and how partners like 2Pace use TestZeus to deliver faster.
The short version
SI testing pain comes from three places: specs that drift from the build, data volume, and QA knowledge stuck in one person’s head.
2Pace turned about 25 Jira tickets into roughly 250 test cases on TestZeus for a B2B commerce build at a major French retailer.
On a health insurance build, a single test step went from about 25 minutes to under 3.
The fixes are simple: test the live app, start with a sharp smoke suite, push volume through APIs, and give clients evidence they can read.
TestZeus covers most of the regression and automation load. Here’s how.
Why SI partners feel Salesforce testing pain first
An end customer tests one org. An SI tests five, at once, on someone else’s deadline.
The SI writes the stories. Builds the flows. Owns the go-live. And testing is the line item that gets squeezed when the build runs late.
We work with a growing group of Salesforce partners. 2Pace in France. A health insurance specialist in the UK. An implementation shop in India. A US and India consultancy with a large QA bench. Different sizes, different clients, the same five problems.
This post is what those projects taught us. Apart from 2Pace, the partners stay unnamed.
Meet 2Pace
2Pace is a Salesforce SI in France. They signed on as a TestZeus partner in 2025 and have grown our footprint across Europe since.
Their first big TestZeus program is a B2B commerce site for a major French retail group. Two retail brands. One portal. Separate products and checkout flows for each.
The stakes were high. A new e-invoicing law was coming into force in September, and a billing regression simply wasn’t an option.
So when 2Pace pitched the program, they built TestZeus into the proposal, with the testing platform paid for by the client. Sofia Martins at 2Pace told us it raised their odds of winning. After the demo, the client’s team was very impressed. The program went ahead, and it became 2Pace’s first TestZeus client program.
That’s the dream for an SI. Testing stops being a cost you absorb. It becomes part of what you sell.
Here’s what that partnership looks like in numbers.
Problem 1: The Jira story is not the app anymore
Every SI knows this one. The story says “Save”. The screen says “Submit”. A field gets renamed in week three. A flow moves. Nobody updates the ticket.
A human tester reads past it. An automated test doesn’t.
The lesson: requirements are a claim. The live UI is the truth.
What to do, with any tool:
Before you write tests for a sprint, walk the live UI for 30 minutes. Note every label that differs from the story.
Record real user flows instead of writing them from tickets.
Split logged-in and logged-out cases. Put the right URL in each.
Write prompts and steps with the business acceptance criteria in them, not just the UI.
How 2Pace does it with TestZeus: 2Pace’s QA lead generated test cases straight from the Sprint 1 Jira tickets, around 10 per ticket. For the client demo, the team recorded key flows straight from the live portal, and TestZeus turned each recording into test steps. For Sprint 2, the QA lead writes prompts from the ticket and the live app together, and Sprint 2 testing now runs on TestZeus.
TestZeus also writes the tests in French when you ask. For a French client, that matters.
Problem 2: 250 tests is not the goal. The right 20 are.
Generation is the easy part now. Picking what to run on every release is the real skill.
When the client wanted a demo, 2Pace didn’t show all 250 cases. Their QA lead picked the 20 that mattered most. 2Pace and our team recorded them together from the live app. That became the smoke suite: small, fast, and focused on the flows the client cares about.
The lesson: coverage is not a count. It’s the right 30 tests running every release.
What to do, with any tool:
Start with risk-based testing. Ask the subject matter expert for the top three business areas. Write 5 to 10 tests for each.
That gives you a 20 to 40 test smoke suite. Run it on every deploy before you grow it.
In every prompt, state the functional goal, positive and negative paths, and how many cases you want.
Tag every test by sprint and business area, so you can run a slice, not the lot.
Where TestZeus fits: 2Pace asked to control how many cases each story generates. We shipped that within two weeks. You can now set the count per story, tag tests by sprint, and run up to 15 in parallel or the whole set in bulk for regression.
Problem 3: The math that kills UI-only testing
Our health insurance partner builds a group policy platform on Salesforce. One policy can carry up to 2,400 members in production, and they are heading toward 5,000.
Eight inputs drive each premium. Age, cover type, underwriting terms, product plan, excess, hospital level, member variations and commission overrides. Even at two values each, that’s 256 combinations.
Now do the UI math. About 30 seconds per screen, 5 screens a test. Call it 2 minutes. For 2,000 combinations, that’s over 66 hours for one regression run. Nobody runs that before a release.
The lesson: test logic through the UI, test volume through the back door.
What to do, with any tool:
Keep 1 to 5 end-to-end UI flows that prove the calculation logic works.
Load volume through Data Loader, the API, or Apex. Validate it with SOQL, not with clicks.
If you are migrating a calculation engine, compare old and new outputs field by field, per member. Flag every decimal mismatch.
Write each rule down as test data: inputs and expected outputs.
Where TestZeus fits: one test can mix UI steps, API calls, Apex and SOQL checks. Prove the screen once, then push the numbers through the data layer. Runs scale out in parallel, so 20 agents side by side do in hours what one runner does in days.
2Pace uses the same pattern. For a retail group whose shop orders flow into Salesforce in batches, we set up API tests and Apex batch tests in 2Pace’s demo org, right next to the UI tests.
Problem 4: One QA person, three projects
This one is normal at every SI. The person who knows the business rules is also on two other projects. Their calendar becomes the test plan.
The insurance partner fixed it by moving to Test Blocks: tests built step by step, with instant feedback on each step. A successful run replays fast and the same way every time.
Step | Early runs | AI mode | Test Blocks |
|---|---|---|---|
Create an intermediary | ~25 min | 10 to 15 min | under 3 min |
Create and approve a DCS | ~30 min | ~20 min | 2 to 3 min |
Within three days of switching, the client team built three new test cases on their own. Both of their use cases have now been reviewed by their clients.
The lesson: if your QA process depends on one person’s calendar, record it so anyone can run it.
What to do, with any tool:
Record a flow once, instead of writing it up. Thirty minutes of recording beats a day of documentation.
Store test data as key-value pairs, with secrets marked as secrets. Then anyone can run the test.
Show stakeholders the fastest path first.
Where TestZeus fits: Test Blocks and Fast mode turn a working AI run into a quick, repeatable replay. That’s where the jump from 25 minutes to under 3 came from.
Problem 5: The client can’t read your test suite
2Pace had to hand the client every Sprint 1 test case as an Excel file. The client wasn’t going to log into a test platform. And the cases used variables, like a store URL placeholder, that a business reader wouldn’t follow.
We wrote 2Pace a small export script. It pulled all the cases into Excel, with real values swapped in for every variable. Clean, readable, ready for the client.
The lesson: your client buys evidence, not test scripts.
What to do, with any tool:
Agree the deliverable format in week one. Excel, PDF, a dashboard, a sign-off sheet.
Export test cases with real values, in plain business language.
Give the client a pass/fail view with screenshots or video.
Write steps the way a business user would, with exact field labels.
Where TestZeus fits: every run comes with screenshots, video, and a plain-language root cause when something fails. Native export is on our roadmap, shaped by 2Pace’s request.
Problem 6: Access, environments and data rules
Some problems only show up when you’re a partner working inside a client’s world.
Logins and MFA. Scripted logins hit MFA walls, and sandbox refreshes break tokens. TestZeus connects to each Salesforce org once, so tests skip the login and no password lives in a test case.
Environments. Use one connection per sandbox: dev, QA, UAT, pre-prod.
The client’s own tools. 2Pace’s client works in the Microsoft suite, so SharePoint support mattered. TestZeus connects to SharePoint, Jira and Confluence, so tests pull from the documents the client already keeps.
Data rules. European clients ask about GDPR early. US healthcare clients ask about HIPAA. Have the answers ready on day one.
Most projects aren’t greenfield. Our India-based partner told us only about 30% of their projects are clean, new builds. The rest are change requests and existing orgs, where recorded flows beat writing tests from scratch.
Start small to win big. The same partner has a customer with 3,000 Salesforce flows. The pilot that opened the door is 15 test cases, with a two-year deal waiting on the other side.
What a good SI testing partnership looks like
The 2Pace partnership shows what happens when testing becomes part of the SI’s offer.
Clients pay for it. TestZeus is part of the retail proposal, paid for by the client, and it helped 2Pace win.
It sells the next deal. 2Pace has a second client in a TestZeus proof of concept, and a multi-year school enrolment program lined up where TestZeus will validate enrolment and the data reaching Salesforce.
It becomes the pre-sales kit. 2Pace keeps its own TestZeus environment for pre-sales, demos, proofs of concept and training.
It travels. A former 2Pace team member joined another European SI and recommended TestZeus there. That turned into a new partnership conversation.
The support is close. Weekly syncs, a shared Slack channel, and a named TestZeus engineer on the account.
Partners shape the product. 2Pace’s feedback shaped our test-count controls, our export roadmap and our partner pricing tiers.
The plan we agreed with another partner is just as simple. Don’t lead with a demo. Pick one client open to trying something new. Automate their first 5 to 10 real scenarios. Then let the results do the selling.
The problem-to-fix map
Problem | Fix you can do today | Where TestZeus helps |
|---|---|---|
Stories drift from the build | Walk and record the live UI before writing tests | Recorder and Test Blocks build steps from the real screens |
Too many tests, wrong ones | 20 to 40 test risk-based smoke suite first | Case count control, tags, bulk and parallel runs |
UI can’t carry volume | UI for logic, API and SOQL for volume | UI, API, Apex and SOQL in one test |
One person holds the knowledge | Record flows, store rules as test data | Anyone can rerun a recorded test |
Client can’t read the output | Agree the format, export real values | Screenshots, video and plain-language root cause per run |
Logins and environments | One connection per sandbox | Connect once, no passwords in tests |
Agentforce agents in scope | Test multi-turn, not just single questions | Adversarial multi-turn agent tests with SOQL and tool-call checks |
Where TestZeus fits for partners
TestZeus is an AI testing agent built for Salesforce. For SI partners, it covers most of the regression and automation load:
Write tests in plain English, from Jira, documents, or by recording the live app. In English, French and ten more languages.
Run UI, API, Apex and SOQL checks in one test.
Scale out to 500+ parallel runs, with no fixed cap.
Get screenshots, video and a root cause for every failure.
Test Agentforce agents with adversarial, multi-turn conversations, not just fixed question and answer pairs.
Keep client data safe: SOC 2 Type II, ISO 27001, GDPR and HIPAA compliant, with data masking before anything reaches an LLM. On-prem and air-gapped options exist for clients that need them.
Partners can refer clients or resell. Either way, our team helps you run the first pilot. Want numbers for a client conversation? Start with our Salesforce regression testing cost calculator or the UAT test plan generator.
FAQ
How should a Salesforce SI partner approach regression testing?
Start with a 20 to 40 test smoke suite built on the client’s top three business risks. Build it from the live UI, not just Jira. Run it on every deploy, then grow it.
Why do automated Salesforce tests break when the app works?
Usually because the requirements drifted from the build. Renamed fields, moved flows and changed labels break tests written from stale stories. Recording from the live app fixes it.
Should Salesforce bulk data be tested through the UI?
No. Use the UI for a few end-to-end flows that prove the logic. Load volume through Data Loader, the API or Apex, and validate it with SOQL.
What should an SI hand the client as test evidence?
A pass/fail view with screenshots or video, and test cases in plain language with real values. Agree the format in week one.
Can an AI testing agent replace a Salesforce QA team?
No. It takes the repetitive part: reruns, regression, volume checks. People still decide what to test and what “correct” means.
Does TestZeus work for Agentforce testing?
Yes. It runs adversarial multi-turn conversations against Agentforce agents and checks tool calls and SOQL, not just the reply text.
The bottom line
SIs don’t lose sleep over test tools. They lose sleep over go-live day, a client who can’t see the evidence, and the one tester who knows how premiums work.
Fix the process first. Test the live app. Keep the suite small and sharp. Push volume through the data layer. Then let an agent do the reruns.
2Pace made testing part of what they sell. Their client pays for it, and it’s helping them win the next deal.
If you’re a Salesforce partner and want to try this on one real client project, talk to us. Bring your messiest org.
// Start testing //
