16 Salesforce QA Interview Questions With Answers

Ask which business rule changed, who uses it, which records are affected and what constitutes success. Identify permissions, automation and integrations that touch the same process. Convert the requirement into observable acceptance criteria before choosing test cases. A field appearing on a page is not proof that the workflow works.

Create representative users with and without access, then test the interfaces used by the business, including records, reports and relevant API operations. Verify both read and edit restrictions. A hidden page-layout field alone does not establish that the data is protected.

Salesforce: control access to objects

Build a small ownership and role matrix, with users inside and outside the expected sharing scope. Verify required access and prohibited access against organisation-wide defaults and configured sharing. Use known records so a report filter cannot disguise a permissions defect.

Salesforce: control access to records

Cover the exact entry condition, a near miss, repeated updates and any changed-field condition. Test expected record updates, related actions and fault behaviour. Include realistic bulk activity where relevant. Confirm which flow version is active and check interactions with other automation on the same records.

Capture the existing business behaviour and compare it with the proposed Flow implementation, including exceptions and ordering dependencies. Salesforce ended support for Workflow Rules and Process Builder on 31 December 2025, but migration still needs regression evidence. Test the agreed intended behaviour instead of preserving an accidental defect without discussion.

Salesforce: Workflow Rules and Process Builder support ended

Reproduce with the affected permission set and record access, then inspect the failure and execution context. Check access to required objects, fields and related records. Determine whether the design or permission assignment is wrong. Do not treat running every test as an administrator as sufficient coverage.

Test valid data, each invalid condition, blank values, boundary values and any authorised exception. Include updates to older records and writes through imports or integrations when those paths are supported. Record the expected error message and confirm that an unsuccessful save does not leave an unintended partial business outcome.

Use a controlled file containing valid, duplicate, missing-key and invalid rows. Verify field mapping, matching behaviour and permissions, then reconcile input counts with successful and failed outcomes. Inspect the resulting records, not just the completion message. Test how corrected rows are retried without duplicating successful ones.

Use suitable mocks or stubs to exercise success, malformed responses, errors and timeouts in automated tests. Verify the application’s handling of each result. Then run a controlled integration check in a representative environment, because mocks cannot prove that real endpoints, credentials and contracts are configured correctly.

Confirm the intended business action occurs only as many times as the contract permits. Use a stable identifier to replay the same event, then inspect related records and side effects such as notifications. A deduplicated database row does not prove that an email or payment request was also deduplicated.

No. Coverage shows that code was executed, not that the tests asserted the right outcomes. Review meaningful assertions, negative cases, user contexts and business workflows. Salesforce has deployment-specific testing requirements; consult the rules for the chosen deployment process rather than treating a coverage percentage as a quality score.

Salesforce: Apex testing

Prioritise critical user journeys and the dependencies of the changed component. Include previously fixed high-impact defects and relevant permissions. Keep a smaller reliable smoke suite for rapid feedback, with broader regression where risk warrants it. Review obsolete cases rather than adding every past test forever.

Dependence on incidental markup, unstable timing or shared mutable data can cause failures unrelated to the business behaviour. Use stable interaction strategies supported by the test framework, isolated data and explicit observable conditions. Investigate flaky failures rather than repeatedly rerunning them until one passes.

State the user context, environment, test data, steps, expected result and actual result. Add safe evidence and describe the business impact. For example, specify that an agent can edit a closed case when the acceptance criteria forbid it. Separate a reproducible observation from a suspected technical cause.

Explain the failed workflow, affected users, reproducibility and available workaround. Recommend a release decision based on that impact, not the overall pass percentage. Identify what evidence would change the recommendation and who owns the decision. A high pass rate can conceal a single release-blocking defect.

Confirm the intended configuration and active automation versions, run agreed smoke journeys with representative permissions, and inspect integration or flow failures. Verify that test artefacts did not pollute business data. Compare results with the release acceptance criteria and use the agreed recovery process if a critical path fails.