20 Salesforce QA Interview Questions and Answers [Testing Experience]

This post is contributed by Morgan Chen, a Salesforce QA Engineer with 9 years of experience in functional testing, test automation, and release validation across enterprise CRM implementations.

I was laid off from a mid-sized SaaS company, where I had spent 5 years leading Salesforce quality assurance for a Sales Cloud and Service Cloud implementation. Over 3 months I went through 14 technical screens, including salesforce apex testing drills, Salesforce test automation exercises, and process-focused panel discussions. The 20 questions below come directly from those interviews, with the answers I gave and my honest read on what each interviewer was testing.

Top 10 Most Frequently Asked Salesforce QA Interview Questions

These Salesforce QA interview questions came up in at least 9 of my 14 screens. Salesforce quality assurance interview panels test some version of these 10 topics. Know them cold.

Q1. What types of testing do you perform on a Salesforce project?

Unit testing at the Apex level (75% coverage required), functional testing of objects, flows, and validation rules from the user perspective, integration testing for REST/SOAP API exchanges, regression testing after every release, and UAT with business stakeholders in a staging sandbox.

From my point of view, the interviewer wants Apex unit testing and functional testing named as separate disciplines. Candidates who blur the two signal limited production depth.

Q2. How do you write and structure Apex test classes?

Apex test classes use @isTest. Data is created in a @testSetup method shared across all test methods, or in a separate TestDataFactory with @isTest(SeeAllData=false). Test methods assert with System.assertEquals and similar. Coverage must reach 75% org-wide to deploy.

The way I see it, the interviewer wants @testSetup and TestDataFactory named. Mentioning SeeAllData=false signals multi-developer org experience.

Q3. What is the difference between a sandbox and production for Salesforce testing?

Four types: Developer (no data, small storage), Developer Pro (no data, larger storage), Partial Copy (subset of production data), Full Copy (exact mirror, used for UAT and performance). Changes move through the pipeline via Change Sets, Salesforce DX, or a DevOps tool.

My take here is that naming all four types with their data characteristics distinguishes structured release experience from informal testing. Salesforce sandbox testing fluency is visible immediately.

Q4. How do you test Salesforce validation rules?

Cover both the positive path (record saves) and negative path (record is blocked with the correct error message). In Apex, call DML on records that violate the rule and assert a DmlException with the expected message. Also test through the UI to confirm field-level error display.

I would flag that testing through Apex DML matters because API inserts can bypass UI-only guards. Knowing DmlException by name demonstrates code-level QA experience.

Q5. How do you perform regression testing after a Salesforce release?

Three phases: impact analysis (map release changes to affected features and test cases), execution (affected cases plus a core smoke suite), and documentation (log results, escalate regressions before the release window closes). Automated suites run via Provar or Selenium in the CI/CD pipeline.

For me, impact analysis is what matters. ‘I run the full regression suite every time’ is weak. Scoping by affected area shows engineering discipline.

Q6. What tools do you use for Salesforce test automation?

Provar for UI automation (Lightning-native, handles shadow DOM and dynamic IDs), Selenium with custom wrappers for teams with existing frameworks, Apex test classes for code-layer automation, and Postman for REST and Bulk API validation.

I would name Provar explicitly for UI roles. Mentioning Selenium without acknowledging the shadow DOM challenge signals no Lightning production experience.

Q7. How do you test Salesforce flows and process automations?

Map every decision node and branch, then write test scenarios for each: happy path, boundary conditions, error branches. Trigger record-triggered flows through Apex DML and assert downstream changes. Test screen flows through the UI. Use Flow Test Coverage (Summer ’23+) for automated coverage checks.

My check here is branch coverage thinking, not just clicking through, separates QA engineers from casual testers.

Q8. How do you test Salesforce integrations with external systems?

Three layers: Apex callout testing with Test.setMock and HttpCalloutMock (live callouts are blocked in test context), end-to-end functional testing in a sandbox connected to a staging external environment, and negative testing simulating timeouts and error responses.

The signal here is Test.setMock and HttpCalloutMock by name. Candidates without Apex mock experience are visible immediately.

Q9. How do you approach UAT in Salesforce projects?

Three stages: preparation (convert user stories to plain-language test scripts, provision sandbox access), execution (business users run scripts, I observe and triage defects in real time), sign-off (formal sign-off per user story; defects reproduced, fixed, and retested before sign-off).

My focus here is the re-test cycle before sign-off. Describing UAT as ‘hand off to business and collect feedback’ misses it.

Q10. What is bulkification and why does it matter for testing?

Apex code must handle up to 200 records per transaction. Governor limits: 100 SOQL queries and 150 DML operations per transaction. Any trigger with queries or DML inside a loop will fail at scale. I always write test methods inserting 200 records in one DML call.

I would watch for the most common Salesforce QA engineer interview gap: bulk scenarios. Know the 200/100/150 numbers. Vague references to ‘limits’ without specifics signal no production debugging experience.

5 Uncommon Salesforce Testing Interview Questions That Surprised Me

These came up in 1 or 2 of my 14 screens, with senior panels or complex architectures. Knowing them signals production depth.

Q1. How do you test Salesforce CPQ configuration and pricing logic?

Test product configuration rules (feature dependencies, option constraints), the full pricing waterfall (list price, discount schedules, partner discounts in sequence), subscription and amendment logic, and quote PDF generation. CPQ introduces additional governor limit pressure per quote save.

What I have seen is that this is uncommon because most QA engineers have not touched CPQ. If it is in the job description, expect the full CPQ lifecycle. The pricing waterfall is the most common defect area.

Q2. How do you validate a data migration into Salesforce from a legacy CRM?

Pre-migration: data profiling for duplicates, nulls, and type mismatches. Execution: sample batch load via Data Loader or Bulk API, verify record counts and relationship integrity. Post-migration: reconcile source vs. destination counts. Business validation: SME spot-checks on sampled records.

I usually see this as uncommon because migration is often seen as a developer task. The reconciliation step is what interviewers care about when it comes up.

Q3. How do you test Salesforce Shield Platform Encryption?

Verify encrypted fields return correct values to authorized users via SOQL and that reports reflect the configured encrypted state. Then regression-test all searches, filters, and formulas that use the field, because encrypted fields cannot be filtered in SOQL the same way as unencrypted ones.

In the orgs I have worked with, Shield is not present in most orgs. The SOQL filter restriction on encrypted fields is the practical QA concern interviewers care about.

Q4. How do you test Salesforce Experience Cloud (Community) sites?

Three areas: persona-based access testing (confirm each external user sees only authorized records), component rendering (LWCs can behave differently in community context around FLS and permissions), and performance testing for page load under external network conditions.

My experience with this one is that access control is the angle that differentiates candidates. Testing that external users cannot reach internal records is a security-adjacent concern few raise unprompted.

Q5. How do you handle Salesforce testing in a DevOps pipeline?

Unit tests run automatically on every PR via Copado, Gearset, or AutoRABIT. Coverage failures block deployment. Functional tests run against a validation org. Provar CLI runs UI suites as pipeline steps and outputs JUnit results. QA gates are stricter for production pipelines than for dev branch validation.

The reality I have seen is that many teams still use Change Sets. Knowing Salesforce DX CLI commands (sfdx force:apex:test:run) and per-environment gates distinguishes DevOps-experienced engineers from manual-only ones.

5 Tricky Salesforce QA Interview Questions

These have correct answers that differ from instinct. Even experienced QA engineers get at least 2 wrong under interview pressure.

Q1. Can Apex test classes make live callouts to external systems?

No. Salesforce blocks live callouts unconditionally in test context. Use Test.setMock with HttpCalloutMock (HTTP) or WebServiceMock (SOAP). Attempting a live callout without a mock throws a CalloutException.

My warning here: the instinctive wrong answer is ‘yes, in a connected sandbox.’ Live callouts are blocked unconditionally. Getting this backwards signals no Apex integration test experience.

Q2. If a @testSetup method creates 10 records and one test method deletes all 10, what does the next test method see?

The original 10 records. Salesforce automatically rolls back all DML from each test method before the next one runs. @testSetup data is restored to its initial state between every test method.

My note here: most candidates assume shared state and answer ‘zero records.’ The rollback is automatic. Interviewers check whether you know @testSetup isolation, not just that it exists.

Q3. If tests pass in a Full Copy sandbox with 100% coverage, does that guarantee a clean production deployment?

No. Production metadata absent from sandbox (custom fields, profiles, record types) can cause test failures. Production data volumes can expose governor limit violations invisible in sandbox. Managed package versions may differ if the sandbox was refreshed at a different cycle.

I would be careful here: ‘yes’ is wrong. Interviewers who ask this have been burned by a metadata mismatch. If you have seen it in practice, say so.

Q4. Does System.runAs() in an Apex test enforce field-level security (FLS)?

No. System.runAs() switches user context for sharing and record visibility only. Apex inside it still runs in system mode. To test FLS, use WITH SECURITY_ENFORCED in SOQL or call Security.stripInaccessible().

My caution on this one: almost everyone gets this wrong the first time. The sharing versus FLS distinction is the key. Knowing Security.stripInaccessible() by name signals you have written security-model tests beyond the basics.

Q5. Can two test methods in the same Apex test class run at the same time?

No. Methods within a class run sequentially. Different test classes can run in parallel when queued asynchronously, which causes data conflicts if classes share state. SeeAllData=false and isolated data patterns prevent this. You can disable parallel execution org-wide in Test Settings.

My reminder here: ‘yes, Salesforce runs tests in parallel’ is wrong at the method level. Intermittent test failures that cannot be reproduced consistently are the symptom of parallel class execution conflicts.

Final Recommendations for Your Salesforce QA Interview

From my personal experience, the differentiator is whether you can describe a real defect you found and what it would have cost in production. Prepare two specific defect stories with Salesforce features named. Spend a few hours in a Developer Edition org writing @testSetup methods, HttpCalloutMock implementations, and 200-record bulk tests. Know your governor limits: 100 SOQL queries, 150 DML operations, 200 records per bulk DML.

If your target roles include Apex development alongside QA, reviewing Salesforce Apex interview questions covers the developer side that often overlaps at the senior level.

Before the interview, use this short checklist to make sure your preparation is practical, specific, and easy to defend in follow-up questions:

• Know governor limits by number: 100 SOQL, 150 DML, 200 records per bulk DML.
• Be honest about tool gaps. Provar experience you do not have is easy to expose in a 10-minute drill.
• Prepare a release-gone-wrong story. Follow-up questions reveal more QA maturity than any direct technical question.

These Salesforce QA interview questions and answers are based on 14 real screening rounds. Across every Salesforce testing interview, the core expectation was the same: can your testing process catch defects before they reach production?

Prepare real project examples, practice writing Apex test cases, and be ready to explain how you work within Salesforce limits.

Svitlana Chepilko

Svitlana is a Communications Manager with extensive experience in outreach and content strategy. She has developed a strong ability to create high-quality, engaging materials that inform and connect professionals. Her expertise lies in creating content that drives engagement and strengthens brand presence within the Salesforce ecosystem. What started as a deep interest in Salesforce later transformed into a passion at SFApps.info where she uses her skills to provide valuable insights to the community. At SFApps.info, she manages communications, ensuring the platform remains a go-to source for industry updates, expert perspectives, and career opportunities. Always full of ideas, she looks for new ways to engage the audience and create valuable connections.