Why Salesforce QA Is Not the Same as Manual Testing?
A short story about learning a platform that refuses to behave like normal software.
When I started working as a Salesforce tester, I was convinced I understood what I was getting into. Testing is testing — you click, compare expected vs actual, and report bugs. A normal job, just with Salesforce instead of a custom web app.
At least, that’s what I thought.
My first day on a Salesforce project quickly proved that Salesforce QA is like walking into a movie whose trailer looked familiar… until you realise nothing in the actual story resembles it at all.
„Can you check why this user can’t see the button?”
That was my first task.
Perfect, I thought. How hard can it be to locate one button?
And then the journey began.
- Page Layout → button exists
- Profile → permissions are there
- Field-Level Security → all good
- Lightning Page → also fine
- Automations → nothing removes it
- UI behaviour → unchanged
Yet the button was still missing.
After 40 minutes, someone casually asked:
“Did you check Record Type assignment?”
No.
No, I did not check Record Type assignment — because back then I didn’t even know it existed.
Click.
Button appears.
Everyone happy… except me, because all I could think was:
“This is not normal testing.”
Salesforce QA is testing… inside someone else’s system
When you test a typical application:
- developers can change anything,
- testers can verify anything,
- the team owns the system end-to-end.
In Salesforce, the rules change.
You are not testing the platform.
You are testing a solution built inside a platform that you cannot modify.
That means:
- you work within limits,
- your tests must respect what Salesforce allows you to see or do,
- some behaviours can never be changed,
- some bugs are actually “features,”
- and sometimes Salesforce wins no matter what you do.
Once you understand this, Salesforce QA becomes an entirely different discipline.
Everything in Salesforce looks simple… until you test it
The most dangerous phrase in Salesforce projects:
“It’s just a small flow.”
Flow calls another flow
Which updates a record.
Which triggers automation.
Which fires Apex.
Which updates something visible only for some users.
Which makes the button disappear.
What looks simple often sits on top of three layers of configuration, automation, and permission logic.
In “normal” manual testing you look for bugs.
In Salesforce QA you often look for why something works at all.
What makes this job genuinely great
Despite the steep learning curve, Salesforce QA brings real benefits:
- you think analytically all the time,
- you work close to business logic,
- you understand architecture and limits,
- you learn how to predict side effects,
- and you become the person who actually knows how the system behaves.
This is not checkbox testing.
It’s not “follow the steps, click save.”
This is about understanding how a human-built system behaves within a Salesforce-built platform.
And solving that puzzle every day is incredibly satisfying.
Back to the missing button…
Today, I would fix that problem in two minutes.
Back then, it took nearly an hour.
But maybe that’s exactly why Salesforce QA is such a powerful and rewarding path:
- it’s never boring,
- it forces growth,
- it rewards curiosity,
- it punishes assumptions,
- and once you “get it,” the platform finally starts to make sense.
Salesforce QA is not manual testing.
It’s investigative work inside a controlled ecosystem with strict rules and limited visibility — and that is what makes it both challenging and fun.
If you want more
This post is part of my larger project:
a complete Salesforce QA Consultant course built from real project experience.
Follow the blog to get new posts as soon as they’re published.