82 Salesforce testing interview questions with answers

What they are assessing

Whether the candidate understands the platform constraint.

Model answer

Salesforce is a cloud CRM and application platform, delivered as software as a service and heavily configurable rather than custom built. Testing it differs because you do not own the whole stack: Salesforce updates the platform three times a year whether you are ready or not, you cannot test the vendor code itself, and much of the behaviour comes from configuration rather than code. So the testing focus shifts to configuration, data, security and integration rather than to algorithms, and regression against platform releases becomes a permanent commitment rather than a project activity.

Likely follow-up

What can you not test on the Salesforce platform?

What they are assessing

Basic data model vocabulary.

Model answer

Standard objects ship with the platform, such as Account, Contact, Opportunity, Lead and Case, and carry built-in behaviour and relationships. Custom objects are created for organisation-specific needs and are identified by the double underscore c suffix on their API name. For testing, the distinction matters because standard objects have platform behaviour you did not configure and may not expect, such as automatic field updates or validation the business never specified, so verifying the configured behaviour means knowing what the platform does on its own.

What they are assessing

A distinction that drives testing approach.

Model answer

Configuration is declarative work done through the interface: objects, fields, page layouts, validation rules, flows, reports and permissions, with no code. Customisation is code: Apex classes and triggers, Lightning Web Components, Visualforce. The testing implication is significant. Code can carry unit tests and Salesforce requires 75 percent coverage to deploy, so there is a safety net. Declarative configuration has no such requirement, and a validation rule or flow can be changed in production by an administrator with no test whatsoever, which is why configuration is often where the untested risk sits.

Trap to avoid

Assuming declarative means safe. The absence of a code deployment gate means configuration changes frequently reach production with less scrutiny than code does.

What they are assessing

Understanding the architectural consequence.

Model answer

Many customers share the same infrastructure and application code, with data separated logically rather than physically. The consequences for testing are concrete: governor limits exist precisely to stop one tenant consuming shared resources, so limit testing is mandatory rather than optional. You cannot change platform behaviour, so a platform defect is raised with Salesforce and worked around rather than fixed. And performance is partly outside your control, so a slow operation may be a shared resource issue rather than anything in your configuration.

What they are assessing

Breadth, and practical relevance.

Model answer

Sales Cloud for the lead to opportunity pipeline, Service Cloud for cases and support, Marketing Cloud, Commerce Cloud, Experience Cloud for external portals, and the underlying Platform for custom applications. It matters because each has its own objects, automation and behaviour: Service Cloud brings entitlements, milestones and omni-channel routing, Experience Cloud brings external user licences and a sharing model that behaves differently from internal users. A tester who knows the generic platform but not the specific cloud will miss the behaviour that cloud brings with it.

What they are assessing

Environment vocabulary, which is specific to the platform.

Model answer

A sandbox is a copy of a production org used for development and testing. Developer sandboxes copy configuration with a small data allowance. Developer Pro is the same with more. Partial Copy includes configuration plus a sample of production data defined by a template, and refreshes every five days. Full Copy includes configuration and all production data and refreshes every twenty-nine days. The refresh intervals matter a great deal for test planning, because a Full sandbox refreshed once a month cannot be refreshed again mid-release when something goes wrong.

Likely follow-up

Which sandbox type would you want for user acceptance testing, and why?

What they are assessing

A detail that costs teams dearly when misunderstood.

Model answer

The sandbox is replaced with a fresh copy of production, so anything that existed only in the sandbox is lost: test data, in-progress configuration not yet deployed, and any manual setup. User email addresses are also scrambled to prevent sending to real customers, and email deliverability defaults to system only, which is why email does not send after a refresh until someone changes it. The practical consequence is that test data must be scripted and reproducible rather than built by hand, because a hand-built data set is destroyed by every refresh.

Trap to avoid

Building test data manually in a sandbox. It is lost at the next refresh, and rebuilding it is the hidden cost that makes Salesforce test cycles slip.

What they are assessing

Modern Salesforce DX awareness.

Model answer

A scratch org is a temporary, disposable org created from a configuration definition file, used in source-driven development. It differs from a sandbox in that it is built from source rather than copied from production, it starts empty, and it expires after a set period up to thirty days. For testing it is excellent for isolated feature verification and continuous integration, because each build can create a clean org. It is poor for anything needing realistic data or the full complexity of the production org, which is why it complements rather than replaces sandboxes.

What they are assessing

Planning at a level above execution.

Model answer

I would work back from the constraint, which is usually Full Copy sandbox refresh frequency and licence count. A typical shape is developer sandboxes per stream, a shared integration sandbox where changes come together, a Full or Partial Copy for system and regression testing with realistic data, a separate UAT environment the business owns and that nobody deploys into mid-cycle, and a staging org matching production for final verification. The decisions that cause trouble later are sharing one environment between development and testing, and using the UAT org for anything else, because both destroy the stability the business needs to sign off.

What they are assessing

The most important data model distinction for testing.

Model answer

A lookup is a loose link where the child can exist without the parent and deleting the parent leaves the child, optionally clearing the field. Master-detail is a tight ownership relationship: the child cannot exist without its parent, deleting the parent deletes all children, the child inherits the parent sharing and security rather than having its own, and roll-up summary fields become available. For testing, master-detail demands explicit cascade delete testing and sharing verification, because the child record visibility is entirely determined by the parent.

Likely follow-up

What testing does a cascade delete require that a lookup does not?

What they are assessing

A common source of subtle defects.

Model answer

A field on a master record that aggregates child records in a master-detail relationship, supporting count, sum, min and max with an optional filter. The testing that matters is recalculation on every path that changes the children: creating, updating the summarised field, deleting, undeleting from the recycle bin, reparenting the child, and bulk operations. Undelete and reparenting are the two most often missed. Also worth verifying is behaviour when the filter criteria change on an existing record, which moves it in or out of the aggregate.

What they are assessing

A feature that multiplies test scope.

Model answer

Record types allow different business processes, page layouts and picklist values for the same object, so a Case can behave differently for support and for complaints. It complicates testing because every record type is effectively a variant: different layouts, different required fields, different picklist values and often different automation. Coverage must therefore span record types rather than testing the object once, and the combination with profiles is multiplicative, since layout assignment is by profile and record type together. This is one of the main reasons Salesforce test matrices grow quickly.

Trap to avoid

Testing one record type and assuming the others behave the same. Record type specific picklist values and layout assignments are a frequent source of defects found only in UAT.

What they are assessing

Depth on a declarative feature with real limits.

Model answer

Formula fields calculate their value at read time from other fields rather than storing data, so they are always current and never need recalculation. What to test: the calculation itself across boundary values, behaviour when a referenced field is null since null handling in formulas is a common defect, cross-object references through relationships and what happens when the parent is missing, and the treatment of currency and date arithmetic. There are also hard limits on formula size and on how many cross-object references a formula can chain, so a formula that works in a simple case can fail to save as it grows.

What they are assessing

The area with the highest defect impact.

Model answer

In layers. Object level permissions, through profiles and permission sets, control whether a user can create, read, edit or delete a type of record. Field level security controls visibility of individual fields. Record level sharing controls which specific records a user sees, through organisation-wide defaults, role hierarchy, sharing rules, manual sharing and team access. The layers combine restrictively for object and field access, and permissively for record sharing, meaning the most open sharing rule wins. Understanding that asymmetry is what the question is usually checking.

Likely follow-up

If organisation-wide default is private and a sharing rule grants read, what does the user see?

What they are assessing

Current best practice, which changed.

Model answer

A profile is assigned one per user and historically carried all permissions. A permission set grants additional permissions on top and a user can have many, so it is additive rather than exclusive. Current Salesforce guidance is to move toward minimal profiles with permissions granted through permission sets and permission set groups, because that avoids the proliferation of near-identical profiles. For testing it matters because a user’s effective permissions are the union of profile and all assigned permission sets, so testing against the profile alone gives the wrong answer.

What they are assessing

Approach to the most error-prone area of a Salesforce org.

Model answer

By persona rather than by permission. I would define the personas that matter, log in as each, and verify both what they can do and what they cannot, because negative verification is the part that gets skipped and is where breaches come from. For each persona: object access, field visibility on page layouts and in reports and API responses, record visibility across the sharing model, and access to the actions and buttons. The two gaps I would look for specifically are fields hidden on the layout but exposed through reports or the API, and sharing granted indirectly through role hierarchy that nobody intended.

Trap to avoid

Testing only that permitted users can do things. Security defects are almost always that someone can see something they should not, which only negative testing finds.

What they are assessing

A code-level security concept with serious implications.

Model answer

Apex runs in system context by default, meaning it ignores the sharing rules of the running user and can access any record. Declaring a class with sharing makes it respect the record sharing of the user. Importantly, with sharing enforces record level sharing but not object and field level security, which still needs explicit checks or the use of security-enforced queries. The testing consequence is that a feature correctly restricted in the interface can expose data through an Apex-backed component, so security testing has to cover the code paths rather than only the user interface.

Likely follow-up

Why is with sharing alone not enough to enforce field level security?

What they are assessing

The simplest declarative automation.

Model answer

A rule that prevents a record being saved when a condition evaluates to true, showing an error message. Testing means verifying it fires when it should, does not fire when it should not, shows the correct message on the correct field, and crucially that it applies through every entry path: the interface, the API, data loader imports and any automation that creates records. Validation rules firing during a bulk import is a very common cause of a migration failing partway, which is why the import path must be tested rather than assumed.

What they are assessing

Current platform direction.

Model answer

Flow is the declarative automation tool, covering record-triggered, screen, scheduled and autolaunched flows. It has replaced Workflow Rules and Process Builder, both of which Salesforce has retired for new creation and is migrating customers away from. The testing relevance is twofold: existing orgs usually contain all three, so you must know how they interact, and migrating from the older tools to Flow is a regression testing exercise in its own right, because the execution order and behaviour are not identical.

What they are assessing

The single most important Salesforce-specific knowledge for a tester.

Model answer

When a record is saved, Salesforce runs a defined sequence: validation of required fields and field formats, before-save flows, before triggers, system validation and validation rules, duplicate rules, after triggers, assignment rules, auto-response rules, workflow rules with their field updates which can re-fire triggers, escalation rules, roll-up summary recalculation on the parent, criteria-based sharing, and finally commit. A tester must know it because it explains the defects that look impossible: a field update appearing to be overwritten, a validation rule firing on a value the user never entered, or a trigger running twice. Without this knowledge those are reported as random behaviour.

Likely follow-up

Why can a workflow field update cause a trigger to run a second time?

Trap to avoid

Not being able to explain recursion. Interviewers at senior level often follow this up specifically, because it is the practical reason the order matters.

What they are assessing

Real-world complexity.

Model answer

Conflicting updates, where two automations set the same field and the last one in the execution order wins, so behaviour depends on ordering nobody designed. Recursion, where a field update re-triggers automation and loops. Governor limit exhaustion from the cumulative work, particularly on bulk operations. And unpredictable behaviour that varies between single-record and bulk paths. Testing means exercising the combination rather than each in isolation, with particular attention to bulk operations, since automation that works on one record frequently fails at scale.

What they are assessing

A feature with many branches.

Model answer

A configured sequence of approval steps with criteria, approvers, and actions on submission, approval, rejection and recall. Testing covers the entry criteria, each step and its approver assignment including delegated and queue-based approvers, the field updates at each stage, record locking during approval and who can still edit, rejection and recall behaviour, and what happens if the approver is inactive or has left. The last of those is the one most often missed and most likely to appear in production when someone leaves the organisation.

What they are assessing

The defining platform constraint.

Model answer

Runtime limits Salesforce enforces per transaction to protect the shared infrastructure: a maximum number of SOQL queries, DML statements, records retrieved, CPU time, heap size and callouts. They exist because of multi tenancy, so one customer cannot degrade the platform for others. For testing, they are the reason bulk testing is mandatory: code that works perfectly on one record can exceed the query limit at two hundred, and the limits are hard failures rather than degradations, so the transaction fails outright.

Likely follow-up

What is the SOQL query limit in a synchronous transaction?

What they are assessing

The most common Apex defect pattern.

Model answer

Writing code to handle collections of records rather than one at a time, specifically by moving queries and DML outside loops. The classic defect is a SOQL query inside a for loop, which works for one record and hits the limit at the 101st. Testing for it means operating on volume rather than single records: load 200 records through data loader, which matches the standard batch size, and ideally more through the API, then verify both that it completes and that the results are correct for every record rather than just the first.

Trap to avoid

Testing only through the interface. The interface creates one record at a time, so it never exercises the bulk path where these defects live.

What they are assessing

Deployment knowledge.

Model answer

At least 75 percent of Apex code must be covered by tests to deploy to production, every trigger must have some coverage, and all tests must pass. The important caveat for a tester is that coverage is a deployment gate rather than a quality measure: a test that executes code without asserting anything satisfies the requirement completely while verifying nothing. Reviewing whether Apex tests actually assert meaningful outcomes, and whether they use realistic data rather than seeAllData, is a legitimate and valuable QA activity.

What they are assessing

A distinction that changes test design.

Model answer

Synchronous Apex runs within the transaction and the user waits. Asynchronous Apex, meaning future methods, Queueable, Batch and Scheduled Apex, runs later in a separate transaction with higher governor limits. For testing, the implications are that the result is not available immediately, so a test asserting straight after the trigger will fail intermittently, and that ordering is not guaranteed. Tests need to wait for completion or query the job status, and manual testing needs the tester to know that a missing update may simply not have run yet rather than being a defect.

Likely follow-up

How would you verify a Batch Apex job processed every record correctly?

What they are assessing

The practical problem every Salesforce automation engineer meets.

Model answer

Because the DOM is dynamic and the identifiers are not stable. Element ids are generated and change between sessions and releases, the markup is deeply nested, components render asynchronously so elements appear late, and Lightning Web Components use shadow DOM which ordinary CSS selectors cannot pierce. There is also no equivalent of adding test attributes to standard Salesforce pages, since you do not control that markup. The result is that naive recorded scripts break almost immediately, and robust automation needs a deliberate locator strategy.

Likely follow-up

What is your locator strategy given that ids are generated?

What they are assessing

A concrete answer to the previous problem.

Model answer

Anchor on things that are part of the business contract rather than the rendering. Field labels are the most stable anchor on standard pages, so locating an input by its associated label text works across releases. Lightning components expose meaningful attributes such as data-field-name on record detail fields, which is far more stable than generated ids. For custom Lightning Web Components, I would ask developers to add a stable data attribute, which is the one place you can control. And for shadow DOM, the tool matters: Playwright pierces shadow roots natively while Selenium needs explicit shadow root traversal, which is a genuine tool selection criterion here.

What they are assessing

Awareness that both may be in play.

Model answer

They are different interfaces over the same data and automation, with different markup, different navigation and some genuinely different behaviour, since certain features exist in one and not the other. Many organisations still run both, with some profiles on Classic. For testing that means the interface layer must be verified separately for each in use, while the underlying automation and security need testing once. Automation scripts written for one will not work on the other at all, which is a planning consideration rather than a technical surprise.

What they are assessing

Market awareness.

Model answer

Selenium and Playwright for general web automation, with Playwright increasingly preferred for its shadow DOM handling. Provar, Copado Robotic Testing, Tosca and Testim are commercial options with Salesforce-specific object recognition that reduces the locator problem substantially. Salesforce’s own tooling covers Apex unit tests and Jest for Lightning Web Components. For API-level testing, the REST and Bulk APIs with Postman or a code-based framework. Most mature programmes use a combination rather than one tool.

What they are assessing

Test placement judgement on a platform where it matters more than usual.

Model answer

As much as possible through the API, because the interface is the least stable layer and the API is a versioned contract. Validation rules, flows, triggers, roll-up summaries, sharing and permissions can all be verified through the REST API with far more stability and speed than through Lightning. What genuinely needs the interface is the interface itself: page layouts, component rendering, Lightning page behaviour and the journeys a user performs. The ratio I aim for is a small set of interface tests over a substantial API layer, which is the only approach that survives three platform releases a year.

Likely follow-up

How would you test a validation rule through the API?

What they are assessing

A Salesforce-specific operational problem.

Model answer

By making everything reproducible from source. Test data is created by script through the API or data loader, not by hand. User credentials come from configuration rather than being hardcoded, since usernames are suffixed with the sandbox name and change on refresh. Any required configuration that is not deployed from version control is scripted as post-refresh setup, including email deliverability, which defaults to system only after every refresh. The test I apply is whether the suite can run successfully within an hour of a refresh with no manual intervention, and if not, the gap is the thing to automate next.

What they are assessing

Understanding where the developer tests fit.

Model answer

They verify Apex logic in isolation and are mandatory for deployment, so they exist in every org whether anyone values them or not. From a QA perspective they are the cheapest place to verify bulk behaviour and governor limit safety, since an Apex test can insert 200 records and assert on the result in seconds. What they do not cover is declarative automation, which is where much Salesforce behaviour lives, the interface, or the interaction between code and configuration. So they are a genuine layer in the strategy rather than something QA can rely on or ignore.

What they are assessing

Practical data handling.

Model answer

Data Loader for bulk operations from CSV, which handles the standard objects and relationships and is the usual choice. The Data Import Wizard for simpler cases through the interface. Salesforce Inspector or similar browser extensions for quick ad hoc work. The Bulk API directly for very large volumes. And SFDX commands for scripted, repeatable loading in a pipeline, which is what I would use for anything that must survive a sandbox refresh. The practical constraint is relationship order: parents before children, and external ids to resolve relationships without knowing internal record ids.

Likely follow-up

How do you load related records when you do not know the parent ids?

What they are assessing

A common project scenario with a wide failure surface.

Model answer

Test it as a process rather than as an outcome. Before migration: profile the source data for quality problems, since most migration failures are bad source data rather than bad mapping. Validate the field mapping including picklist values, which must exist in the target or the record fails. Verify the load order respects relationships. During: run a trial migration into a Full sandbox at realistic volume, measure duration, and check error handling since partial failures are the normal case. After: reconcile counts and values between source and target, verify relationships resolved correctly, and check that automation which fired during the load did not corrupt data. Deactivating triggers and validation rules during load is common and must itself be tested, since whatever they would have done now has to be done another way.

Trap to avoid

Migrating with automation active and no reconciliation. Validation rules and flows firing during a bulk load silently change or reject records, and without reconciliation nobody notices until a user does.

What they are assessing

A specific field property with practical consequences.

Model answer

A custom field marked as an external id holds a unique identifier from an outside system and can be used to look up or upsert records without knowing the Salesforce record id. It matters for testing because it is how integrations and data loads resolve relationships, so testing it means verifying uniqueness enforcement, upsert behaviour when the value matches an existing record, behaviour when it does not and a new record is created, and what happens when the value is null or duplicated. Duplicate external id values cause upserts to fail, which is a common integration defect.

What they are assessing

Integration vocabulary.

Model answer

REST API for most record operations and anything modern. SOAP API for enterprise integrations and some administrative operations. Bulk API for large volume loads, processing asynchronously in batches. Streaming API and Platform Events for push notifications and event-driven integration. Metadata API for configuration deployment. Composite API for combining several operations into one call to reduce round trips. For testing, REST is the one you will use most, and knowing Bulk exists matters because its error handling differs: it reports per-record failures rather than failing the whole operation.

What they are assessing

Integration test design.

Model answer

In layers. The contract first: field mapping, data types, required fields and transformation rules, which can be verified at API level without the interface. Then the happy path end to end. Then the failure modes, which is where the real risk sits: the external system down or slow, authentication expired, malformed responses, partial failures in a batch, duplicate messages, and ordering when messages arrive out of sequence. Then the recovery behaviour, meaning whether failed records are retried, queued or silently lost. Silent loss is the defect to hunt for, because it produces no error anywhere and is discovered weeks later when someone notices missing data.

Likely follow-up

How would you test that a failed callout is retried rather than dropped?

What they are assessing

Governor limits applied to integration.

Model answer

There is a limit on the number of callouts per transaction, a cumulative timeout across all callouts in a transaction, and callouts are not permitted after a DML operation in the same transaction without using an asynchronous method. They matter because an integration that works for one record fails when a bulk update triggers it for two hundred, and because the callout-after-DML restriction is a frequent cause of code being restructured into future or Queueable methods, which changes the timing and therefore how it must be tested.

What they are assessing

The defining operational commitment of Salesforce QA.

Model answer

Three times a year: Spring, Summer and Winter. The releases are applied to your org on a published schedule whether you are ready or not, so the regression burden is permanent rather than project-based. Salesforce provides a preview window where sandboxes are upgraded ahead of production, which is the opportunity to test. The practical implication is that a Salesforce programme needs an automated regression suite specifically to survive this, because manually regression testing a large org three times a year is not sustainable.

Likely follow-up

What do you do in the preview window?

What they are assessing

A process senior candidates should have run.

Model answer

Read the release notes against your org rather than generally, focusing on changes to features you actually use and anything marked as a behaviour change or a retirement. Check the critical updates and security alerts, which have enforcement dates and will apply whether tested or not. Then get a preview sandbox, run the automated regression suite against it, and manually test the areas the release notes flag. Where something breaks, there is usually a window to raise it with Salesforce or to adapt. The failure mode is treating the release as low risk because most of them are uneventful, and then being caught by the one that retires an API version you depend on.

What they are assessing

Deployment knowledge.

Model answer

A change set is the declarative way to move configuration between related orgs, assembled in the source org and deployed in the target. Its limitations are significant: not all metadata types are supported, so some changes must be made manually in each environment, there is no version control or audit history, deployments are slow, and it is error-prone because components must be added manually and a missing dependency fails the deployment. This is why mature programmes use SFDX and metadata source control instead, with change sets surviving mainly in smaller orgs.

What they are assessing

AppExchange awareness.

Model answer

An unmanaged package is a one-time copy of components into the target org, after which they are fully editable and no longer connected to the source. A managed package, typical of AppExchange products, is version-controlled by the publisher, its internal code is not visible or editable, and it can be upgraded in place. For testing, managed packages matter because you cannot see inside them, so you test their behaviour as a black box, their upgrades are a regression event you do not control, and their Apex tests do not count toward your coverage requirement.

What they are assessing

The question that most distinguishes experienced Salesforce testers.

Model answer

I would scope it by risk and build it at the lowest viable layer. The critical business processes first, end to end, since those are what the business cannot lose. Then the configuration that is easy to break and hard to notice: validation rules, flows, roll-up summaries, sharing and permissions, all of which I would verify through the API rather than the interface for stability. Then a thin layer of interface tests for the journeys users actually perform. I would deliberately not try to cover everything, because a Salesforce org has effectively unlimited surface and an unmaintainable suite provides less protection than a smaller trusted one.

Likely follow-up

How would you keep that suite working across three platform releases a year?

What they are assessing

Process judgement, not just technical reaction.

Model answer

Immediately, assess what it affects: which record types, which entry paths, and whether anything is now failing, particularly integrations and bulk loads which will fail silently from the user perspective. Then verify whether the change exists in lower environments, because if not, the next deployment will overwrite it and reintroduce the original problem. Longer term, the real issue is the process: production configuration changes without testing are a Salesforce-specific risk because the platform makes them so easy. I would push for change control on configuration rather than only on code, which is the gap most Salesforce programmes have.

What they are assessing

Scoping discipline on a platform with unlimited surface.

Model answer

I start from the position that platform functionality is Salesforce’s responsibility and we do not test it: standard object behaviour, the interface framework, and anything we have not configured. What we test is what we changed or configured, what depends on it, and what the business cannot afford to lose. Beyond that I use usage data where available, since many orgs carry configuration nobody has used in years, and defect history. The thing I would state explicitly in a plan is that full coverage of a mature Salesforce org is not achievable, so the plan is a risk allocation rather than a coverage claim.

What they are assessing

Systematic diagnosis on the platform.

Model answer

Work through the layers. Is the user permitted to edit that field, since field level security silently prevents the update rather than erroring. Is there automation that should set it, and did it run, which the debug log answers. Is something later in the order of execution overwriting it. Is the automation entry criteria actually met for this record. Is it asynchronous and simply has not run yet. And is there a validation rule causing a silent failure in a bulk path. Enabling a debug log for the user and reproducing is usually the fastest route, because it shows the full execution sequence.

Likely follow-up

How do you set up a debug log for a specific user?

What they are assessing

Core diagnostic tool.

Model answer

A detailed trace of what happened during a transaction for a specified user, with configurable levels for Apex, database, workflow and validation. I look for the sequence of automation that fired and in what order, the governor limit consumption which appears cumulatively, SOQL queries and their row counts for signs of loop problems, validation rule evaluation, and exceptions. The practical caution is that logs have a size limit and truncate, so for a complex transaction the useful part may be cut off, and lowering the log levels on categories you do not need is how you get a usable log.

What they are assessing

The single most common Salesforce defect pattern.

Model answer

Governor limits, almost certainly, from unbulkified code: a SOQL query or a DML statement inside a loop, so the operation that uses one query for one record uses two hundred for two hundred. Other candidates are a flow configured to run per record rather than being bulk-safe, cumulative CPU time across combined automation, and callout limits in an integration. The diagnosis is a debug log from the bulk operation, which shows the limit consumption directly, and the fix is almost always restructuring rather than raising anything, since the limits are not configurable.

What they are assessing

A specific platform error candidates meet in practice.

Model answer

An error raised when a single transaction performs DML on both setup objects, such as User, Group or PermissionSetAssignment, and non-setup objects such as Account or Contact. Salesforce does not permit this in one transaction. It appears most often in Apex tests that create a user and then create records owned by them. The resolution is to separate the operations, typically with System.runAs in a test or by moving one into an asynchronous method. It is worth knowing because the error message is opaque and the cause is not obvious from it.

What they are assessing

Ownership and routing concepts.

Model answer

A queue is a holding area for records awaiting assignment, where the queue owns the record until a user takes it. Queue members can view and claim records. A role is part of the hierarchy that determines record visibility through sharing. They solve different problems: queues handle work distribution, roles handle visibility. For testing, queues need verification of membership, assignment rules that route into them, visibility for members and non-members, and the behaviour when a record is accepted, which changes ownership and therefore sharing.

What they are assessing

The foundation of record visibility.

Model answer

The organisation-wide default sets the baseline access to records a user does not own, per object: private, public read only, public read write, or controlled by parent. The role hierarchy then grants users access to records owned by people below them, provided grant access using hierarchies is enabled for that object. The important property is that sharing is additive and only ever opens access, never restricts it, so the organisation-wide default must be the most restrictive setting you want and everything else widens it. Testing therefore has to start from the default and verify each widening mechanism separately.

Likely follow-up

Why can you not use a sharing rule to restrict access?

What they are assessing

Many-to-many modelling.

Model answer

A custom object with two master-detail relationships, used to create a many-to-many relationship between two objects, such as linking Students and Courses through an Enrolment object. For testing, the significant points are that deleting either parent deletes the junction records, the sharing is determined by the primary master-detail relationship which is the first one created, and the record is only visible to users who can see that primary parent. That sharing behaviour surprises people and is worth verifying explicitly.

What they are assessing

Current Flow knowledge with a performance angle.

Model answer

A before-save flow runs before the record is committed and can modify fields on the triggering record directly without a further DML operation, which makes it substantially faster. An after-save flow runs after commit and can access the record id, create related records and send the record to other systems, but updating the triggering record from it causes an additional save and re-fires the automation. The testing relevance is that moving logic from after-save to before-save is a common optimisation, and it changes behaviour: the record id is not available, and related records cannot be created.

What they are assessing

A practical automation detail.

Model answer

Not through the login form for every test, because it is slow and because Salesforce applies login protections that interfere. The better approaches are to authenticate through OAuth or the SOAP login call to obtain a session id and set it directly, which is fast and stable, or to use SFDX to generate an authenticated session URL. The complications to plan for are IP restrictions and verification challenges for new locations, which is why automation users are typically given a profile with trusted IP ranges configured. Hardcoding credentials is the thing to avoid, since usernames change on every sandbox refresh.

What they are assessing

Event-driven architecture on the platform.

Model answer

Platform Events are the publish and subscribe messaging layer, where a publisher fires an event and subscribers, which may be Apex triggers, flows or external systems, react asynchronously. Testing them means verifying publication occurs under the right conditions, that each subscriber handles the event correctly, and the harder parts: delivery is asynchronous so timing matters, events can be replayed from the event bus within the retention window, and a failing subscriber does not stop others. The specific risk to test is duplicate processing, since delivery is at-least-once rather than exactly-once, so subscribers must be idempotent.

Likely follow-up

Why does at-least-once delivery mean subscribers must be idempotent?

What they are assessing

A practical detail that wastes a lot of tester time.

Model answer

Because email deliverability is set to System email only after a sandbox is created or refreshed, which blocks all email except password resets. It is deliberate, preventing a sandbox full of production data from emailing real customers. To test email, an administrator sets deliverability to All email, and ideally the sandbox user email addresses are updated too, since they are scrambled during refresh. It is worth knowing because the symptom looks like a defect in the notification logic, and testers frequently raise it as one.

What they are assessing

An area frequently left untested.

Model answer

Reports need verification that the filter logic returns the correct record set, that totals and groupings calculate correctly, and crucially that the results respect the running user’s sharing, since a report shown to a manager and to an agent should legitimately differ. Dashboards add the running user setting, which can expose data broadly if set to a privileged user, and that is a genuine security risk worth testing deliberately. Date filters using relative ranges need boundary testing. The test I would not skip is comparing report output to a direct query of the same criteria, because a mismatch there usually means the filter logic is subtly wrong.

What they are assessing

Test isolation on the platform.

Model answer

By default Apex tests cannot see org data and must create their own, which keeps them isolated and reproducible. Annotating a test with seeAllData true lets it access existing org data. It matters because tests written that way pass in one org and fail in another, and break when the data they silently depend on changes. It is considered poor practice and I would flag it in review. There are narrow legitimate cases, such as objects that cannot be created in a test context, but the default position should be that a test creates its own data.

What they are assessing

A compliance obligation on a platform that makes copying easy.

Model answer

With a data mask applied after the refresh, before anyone has access. Salesforce offers a Data Mask product for this, and third-party tools exist. The fields that matter are names, email addresses, phone numbers, addresses and any identification or financial data. Email in particular must be masked or deliverability must stay off, because a Full sandbox with real addresses and email enabled will contact real customers. The requirement that trips people up is preserving referential integrity and realistic distributions, since masking that replaces everything with the same value makes the sandbox useless for testing.

Trap to avoid

Treating a Full Copy sandbox as a test environment rather than as a copy of production personal data. It carries the same obligations as production under GDPR and equivalent regimes.

What they are assessing

Current component model.

Model answer

The modern component framework, built on web standards, which replaced the older Aura components though both still coexist in many orgs. For a tester the practical points are that LWC uses shadow DOM, which affects how automation locates elements and how CSS applies, that components can be tested in isolation with Jest which is the developer-side layer, and that components communicate through events and wire adapters, so a component may appear broken when the real defect is in the data it was given. Knowing whether a page is built from LWC, Aura or Visualforce changes both the automation approach and where to look when something fails.

What they are assessing

Systematic diagnosis of the most common support issue.

Model answer

Through the sharing layers in order. Does their profile or permission set grant read on the object at all. Does the organisation-wide default make it private, and if so, do they own it, are they above the owner in the role hierarchy, is there a sharing rule, a manual share, a team membership, or territory assignment. Is it a detail record whose access comes from a master they cannot see. Salesforce provides a sharing button on the record showing who has access and why, which usually answers it directly, and the Setup user detail page shows effective permissions. The common surprise is access granted indirectly through role hierarchy that nobody intended.

What they are assessing

A specific platform mechanism with a deadline.

Model answer

A platform change that may affect existing functionality, which Salesforce makes available to test and then auto-enables on a published date. They appear in Setup with a description and an enforcement date. They matter because they will be applied whether or not you have tested, so treating them as optional is how an org breaks on a date nobody had in the calendar. The right handling is to review each one against the org, enable it in a sandbox, test the affected areas, and plan the production enablement ahead of the deadline rather than on it.

What they are assessing

A specific area with a distinct risk profile.

Model answer

Experience Cloud builds external-facing sites and portals on top of the org, used for customer and partner communities. The extra testing it needs is substantial and mostly security: external user licences have a different sharing model, guest user access is a known and repeatedly exploited risk area where object and field permissions must be verified as restrictive, and sharing sets and sharing rules behave differently for community users. Beyond security, there is public-facing concern: responsive behaviour, SEO where the site is indexed, and accessibility, since an external site carries obligations an internal org does not.

Likely follow-up

Why is the guest user profile a particular risk?

What they are assessing

Cascade behaviour.

Model answer

It depends on the relationship. Master-detail children are deleted with the parent, cascading down through further master-detail levels. Lookup children are retained, with the lookup field cleared, unless the lookup is configured to prevent deletion of the parent or to cascade. Deleted records go to the recycle bin for fifteen days and can be undeleted, which restores cascaded children too. The testing points are the cascade depth, which can be surprising in a deep hierarchy, roll-up summaries recalculating on delete and on undelete, and automation that fires on delete.

What they are assessing

The maintenance question specific to this platform.

Model answer

By minimising the surface exposed to platform change. Most verification happens through the API, which is versioned and stable, so a release does not affect it. Interface tests use label-based and semantic locators rather than generated ids. The suite runs against the preview sandbox during the release window, so breakage is found before production and there is time to adapt. And the suite is deliberately small at the interface layer, because every interface test is a maintenance liability three times a year. Teams that automate heavily through the interface spend most of their capacity on repair rather than on new coverage.

What they are assessing

A distinction with security consequences.

Model answer

Field level security controls whether a user can see or edit a field at all, enforced across the interface, reports, list views, search and the API. Page layout controls whether a field appears on a particular layout, which is a presentation decision only. The critical difference is that removing a field from a layout does not secure it: the user can still reach it through reports, list views or the API. Teams routinely hide sensitive fields by removing them from layouts, which is a security defect, and verifying through a report or an API call is how a tester catches it.

Trap to avoid

Confirming a field is hidden by checking the record page only. It must be verified through reports and the API, which is where layout-only hiding fails.

What they are assessing

Code architecture awareness.

Model answer

A pattern where each object has one trigger that delegates to handler classes, rather than several triggers on the same object. It matters to QA because multiple triggers on one object have no guaranteed execution order, so behaviour becomes unpredictable and defects appear intermittently. A framework also typically provides recursion control, which prevents the trigger re-firing when a field update causes another save. When reviewing an org, several triggers on the same object is a finding worth raising, because it makes the behaviour untestable in any rigorous sense.

What they are assessing

Standard automation on Leads and Cases.

Model answer

Rules that automatically assign ownership of a Lead or Case based on criteria, evaluated in order with the first match winning. Testing covers each rule entry in order including the default when nothing matches, assignment to both users and queues, the interaction with the assign using active assignment rule checkbox which determines whether the rules run at all on a given path, and what happens when the target user is inactive. The checkbox is important: records created through the API or data loader do not fire assignment rules unless the header is set, which is a frequent cause of unassigned records in production.

What they are assessing

Getting oriented in a complex org.

Model answer

I would map before testing. Start with the object model and the automation inventory, since tools can list every flow, trigger, validation rule and workflow per object, and the volume of that list tells you a great deal about the risk. Then the security model by persona. Then the integrations, which are usually the least documented and highest risk. Then usage data, since mature orgs carry a great deal of configuration nobody uses. From that I would produce a risk ranked view and build regression coverage on the critical processes first. What I would avoid is attempting comprehensive coverage, because the surface of an inherited org is effectively unbounded.

What they are assessing

A specific error with a structural cause.

Model answer

That two transactions tried to lock the same record simultaneously, so one failed. The usual cause is concurrent updates to records sharing a parent, since updating a detail record locks its master, so parallel bulk loads touching children of the same account contend on that account. It appears most in data loads running in parallel mode and in integrations firing concurrently. The fixes are to load in serial mode, to sort the data so records sharing a parent are in the same batch, or to reduce batch size. It is worth recognising because it looks intermittent and is actually deterministic given the data ordering.

What they are assessing

The operational discipline that defines Salesforce test maturity.

Model answer

By treating data creation as code. A scripted set of API calls or SFDX data tree files held in version control, creating the full hierarchy from accounts down to the records under test, with external ids so relationships resolve without knowing record ids. The script is idempotent so it can be rerun. Post-refresh steps are included: email deliverability, user setup, and any configuration not covered by deployment. The outcome I aim for is a single command that takes a freshly refreshed sandbox to a testable state, because any manual step in that process is the one that will be forgotten.

What they are assessing

Risk communication at lead level.

Model answer

I would not argue for delay on principle, I would make the ongoing cost explicit. Going live without automated regression is possible, and many orgs do, but it commits the organisation to manual regression three times a year for every seasonal release plus every change, which is a permanent staffing cost rather than a one-off. I would scope the minimum viable automation, which is usually the critical business processes at API level, and show what that costs against the recurring manual alternative. Then I would make sure the decision is recorded, because the first seasonal release after go-live is when the absence becomes visible and the conversation is better had in advance.

What they are assessing

Practical query skill.

Model answer

Salesforce Object Query Language, used to retrieve records, similar to SQL but restricted to relationships defined in the data model rather than arbitrary joins. A tester uses it constantly: verifying the state of records after an operation, checking what automation actually did, confirming a report matches the underlying data, and building test data queries. It is available through the developer console, Salesforce Inspector and the API. Being able to write a query with a relationship traversal and a filter is a reasonable expectation for a Salesforce tester at mid level.

What they are assessing

Record access mechanics.

Model answer

A rule that extends record access beyond the organisation-wide default and role hierarchy. Owner-based rules share records owned by one group with another. Criteria-based rules share records matching field conditions regardless of owner, and these are recalculated when the record changes, which can be a performance consideration on large volumes. Both can grant read only or read write. The testing points are that criteria-based rules re-evaluate on edit, so a record can move in or out of visibility when a field changes, and that sharing is additive, so overlapping rules grant the most permissive access.

What they are assessing

Tool selection with reasons.

Model answer

Provar is a test automation tool built specifically for Salesforce, with metadata-aware object recognition that resolves fields by API name rather than by DOM locator, so it survives Lightning markup changes that break generic tools. Teams choose a Salesforce-specific tool when the suite is largely interface-driven, when the team lacks engineering capacity to maintain a code framework, and when the maintenance cost of generic automation across three seasonal releases has become visible. The trade is licence cost and tool lock-in against substantially lower maintenance, and that calculation usually favours the specialist tool on large Salesforce programmes.

What they are assessing

Inbound integration, which behaves differently from outbound.

Model answer

The critical point is that inbound writes trigger all the same automation as a user action: validation rules, flows, triggers, assignment rules and roll-up summaries. So the testing must verify that the integration payload satisfies every validation rule, that required fields are populated, and that picklist values exist. Then the failure behaviour: what the external system receives when a record is rejected, whether it retries, and whether a partial batch failure leaves consistent data. Bulk API behaviour differs here because it reports per-record results rather than failing wholesale, so error handling must actually read those results.

What they are assessing

Tooling for repeatable work.

Model answer

A command line tool for interacting with orgs: authenticating, deploying and retrieving metadata, creating scratch orgs, running Apex tests, executing anonymous Apex, and importing and exporting data trees. For a tester it is the route to anything repeatable: seeding test data after a refresh, running Apex tests in a pipeline, querying records to verify state, and capturing the configuration of an org for comparison. Being able to use it separates a tester who can set up their own environment from one who waits for an administrator.

What they are assessing

Technique applied to declarative logic.

Model answer

As a decision table or a state model rather than by clicking through it. I would map the decision elements and their conditions, enumerate the paths, and identify which combinations are genuinely distinct, which usually collapses a daunting diagram into a manageable set. Then test each path with data that satisfies exactly that branch, including the default and error paths which are routinely unimplemented. Flow has a debug mode that shows the path taken with variable values at each step, which is the fastest way to confirm a specific branch executed. For record-triggered flows I would also test the bulk path, since flows have their own limits.

What they are assessing

A defensive pattern with testing implications.

Model answer

A mechanism, usually a static boolean in a handler class, that prevents a trigger running a second time within the same transaction when a field update causes another save. A tester cares because recursion produces two distinct symptoms: either a limit exception in a deep loop, or automation running twice and producing doubled values in roll-ups and duplicated related records. The second is the dangerous one, because it does not error, it just produces wrong data. Testing for it means asserting on the number of records created and the final field values rather than only that the operation succeeded.

What they are assessing

Organisational design.

Model answer

With the platform specifics in mind. The team needs genuine Salesforce knowledge rather than general testing skill alone, because the order of execution, the sharing model and governor limits are not learnable from a test plan. I would want automation capability focused at API level rather than a large interface suite, ownership of the seasonal release regression cycle as a standing commitment in the calendar, and involvement in configuration change control, which is the gap most Salesforce programmes have. I would also push for testers to have administrator-level access in lower environments, because a tester who cannot read Setup is working blind on this platform.

What they are assessing

A closing question revealing depth of experience.

Model answer

Testing the org as if it were a web application: everything through the interface, one record at a time, with no attention to the platform underneath. That approach misses the three things that actually break Salesforce implementations. Bulk behaviour, because the interface never exercises it and governor limits only bite at volume. Security, because the sharing model is layered and the defects are what people can see rather than what they cannot do. And the seasonal releases, because an org with no regression strategy discovers its gaps three times a year on a date Salesforce chose. All three require knowing the platform rather than only knowing testing.