The Admin User Is Lying to You
The First Step to Failure
If you open a test case or a Jira ticket and the first step reads:
"1. Log in as System Administrator"
...you have already failed. You are no longer testing the production system. You are testing a fantasy version of the application that only exists for a handful of people.
We all do it. We do it because it’s easy. We do it because we don’t want to be blocked by "Insufficient Privileges" errors while we are just trying to verify a page layout.
But in Salesforce, the System Administrator profile is not just a "Super User." It is a separate reality. And when you test inside that reality, you are being lied to.
Why Admin Feels Safe (And Why It’s Dangerous)
Testing as an Admin feels great.
- You see every record.
- You see every field.
- You can edit anything.
- You bypass Validation Rules that have
$Profile.Name <> 'System Administrator'exceptions.
It is frictionless. It is fast. It gives you that warm, fuzzy feeling of "everything is working."
But that friction you just avoided? That friction is the system.
Salesforce is primarily a platform of restrictions. It is built on Sharing Rules, Field-Level Security (FLS), and Profile permissions. When you test as an Admin, you turn all of those features off. You aren't testing the application; you are testing the database schema.
What "God Mode" Hides
When you test with "Modify All Data" and "View All Data" permissions, you are actively blinding yourself to the most common production defects.
1. The Case of the Invisible Record
You verify that the "Approvals" related list shows the correct data. It looks perfect.
In Production, the Sales Manager logs in and sees... nothing.
Why? Because the Sharing Settings for that object are set to Private, and the Admin forgot to create a Sharing Rule for the Manager's role. You saw it because you see everything. They see nothing because the system is working exactly as configured—just not how you tested it.
2. The Button That Wasn't There
You check the "Submit for Review" button on the Opportunity. It clicks, the Flow runs, the status updates.
In Production, the user screams that the button doesn't exist.
Why? Because the button action was added to the Page Layout, but the Permission Set assigned to the user doesn't grant access to the underlying Flow or the Record Type. Admin bypasses that check.
3. The Silent Save
You update a field to trigger an automation. It works.
In Production, the user gets a red error message.
Why? Because a Validation Rule was written to block changes unless the user has a specific Custom Permission. You have it (or bypass it). They don't.
The False Confidence Loop
Admin testing creates a dangerous feedback loop in Agile teams.
- QA tests as Admin to "move fast."
- The feature passes Functional Testing.
- Confidence increases ("The logic works!").
- Security testing is deferred to "later" or "UAT."
But "later" often means "never," or it means "during the panic of UAT." By the time you realize the security model is broken, the logic is already deployed.
The Production Surprise
This is why we have the classic "It worked for me" conversation.
User: "I can't edit the Start Date."
QA: "That's weird, it worked for me."
It worked for you because you are a god in the machine. It failed for them because they are mortals. The user isn't doing it wrong; your test setup was wrong.
The QA Correction: Embrace the Friction
We need to redefine the purpose of the System Administrator profile in QA.
Admin is for:
- Configuration
- Debugging (checking logs, inspecting hidden fields)
- Data setup
Admin is NOT for:
- Validation
- User Story acceptance
Real testing starts when you log in as the specific persona defined in the story. Real testing begins when:
- You can't see the record you aren't supposed to see.
- You can't click the button you shouldn't click.
- You can't save the data that violates the rule.
If your test user feels comfortable and powerful, you are probably not testing the right thing.
QA Takeaways
- Use
Login As: This is the most powerful button in Salesforce. Use it constantly. Test as the "Sales Rep," the "Service Agent," and the "Integration User." - Create "QA Only" Personas: If you can't log in as real users due to privacy, create dummy users with the exact same Profile and Permission Set assignments.
- Test Negative Access: Don't just test that a user can see X. Test that they cannot see Y.
- Audit the Bypass: Check your Validation Rules and Flows. If you see
Profile.Name <> 'System Administrator', that is a test case waiting to fail.
Admin is not a user. Admin is a microscope. Don't mistake the view through the lens for the world your users live in.
Do you have a rule in your team about when it's okay to test as Admin? (Hint: The answer should be "Almost never.")