Question 1

What does a Salesforce QA / Tester do day-to-day?

Accepted Answer

A Salesforce QA / Tester ensures the Salesforce solution works as designed and meets business requirements before production. Day-to-day: - Test planning : design test strategy, scope, plan. - Test case authoring : detailed test cases per requirement / user story. - Manual testing : execute test cases in sandboxes; identify defects. - Automated testing : build / maintain automated test scripts (Provar, Selenium, Cypress). - Defect management : log defects, retest fixes, verify resolution. - UAT support : assist business users during UAT; triage issues. - Regression testing : ensure new changes don't break existing functionality. - Performance / load testing : validate system handles expected volumes. - Documentation : test results, test summaries, sign-off documents. Skills required: - Salesforce platform knowledge (Sales/Service Cloud, common features). - Test methodology (manual, automated, integration, regression). - Tools (Provar, Selenium, Cypress, JIRA, qTest, etc.). - Some scripting (Apex, Jest, JavaScript). - Communication with business and developers. Career progression: - Junior Tester - QA Analyst - Senior QA - Test Lead - QA Manager. QA is critical: untested Salesforce

Question 2

What's the difference between manual and automated testing?

Accepted Answer

Manual testing : human executes test cases. Click through scenarios; observe results. Automated testing : scripts execute test cases. Faster, repeatable. Manual wins for: - Exploratory testing — try things, find unexpected behaviour. - UX evaluation — does it feel right? - One-off tests — too costly to automate. - Complex scenarios — automation hard to design. - Visual / accessibility — humans see things automation misses. Automation wins for: - Regression — re-run tests on every change. - High-volume — many records, many runs. - Integration — test cross-system. - CI/CD — runs on every commit. - Reproducibility — exact same test, every time. In practice: - Mix is typical. - Automate the repeatable — regression, smoke tests. - Manual for the new — initial test of new feature. - Manual for exploratory — discover surprises. Tools for Salesforce automation: - Apex unit tests (built-in). - Jest for LWC. - Provar — Salesforce-specific. - Tosca — enterprise. - Selenium / Cypress / Playwright — generic. Trade-offs: - Manual: cheaper to start; expensive to repeat. - Automated: expensive to start; cheap to repeat. Senior QA insight : automation pays back over many runs. Single-use tests can

Question 3

What's the difference between a test case and a test script?

Accepted Answer

Test case : human-readable description of what to test. Used for: manual testing, planning, sign-off, audit. Test script : code that executes the test case. Used for: automated execution. Relationship: - Test case is the design. - Test script is the implementation. - One test case can have one or more scripts (different tools). - Manual tests have only test cases; no scripts. Test case lifecycle: - Author - Review - Approve - Execute (manually or automated) - Update as system changes. Test script lifecycle: - Implement - Test - Run in CI/CD - Maintain as features change. Tools that manage them: - Test management : qTest, Zephyr, TestRail, Xray (Jira plugin). - Test automation : Provar, Tosca, Cypress, Selenium. Senior QA insight : good test cases survive automation tool changes. Tools come and go; well-written test cases endure.

Question 4

What is regression testing and why does it matter?

Accepted Answer

Regression testing : re-running tests after a change to confirm existing functionality still works. Why it matters: - Software changes break things. - New feature affects unrelated areas. - Bug fix accidentally re-introduces another bug. - Salesforce platform changes affect existing config. When to regression test: - After every release — full regression suite. - After Salesforce platform releases (3 times/year) — confirm nothing broke. - After integration changes — affected systems re-tested. - After bug fixes — confirm fix doesn't break elsewhere. - Continuously in CI/CD — every commit triggers smoke tests. Approach: 1. Build regression suite. - Comprehensive set of tests covering critical paths. - Smoke tests (fast subset for quick checks). - Full regression (deep coverage for major releases). 2. Automate where possible. - Manual regression for 1000-test suite is impractical. - Automation makes regression sustainable. 3. Maintain. - Update tests as features change. - Remove obsolete tests. - Add tests for new features. 4. Run strategically. - Smoke tests on every commit. - Full regression weekly / before releases. - After platform updates. 5. Triage failures. - Distinguish test

Question 5

What is User Acceptance Testing (UAT) and what is the QA role in it?

Accepted Answer

UAT (User Acceptance Testing) : business users test the system to confirm it meets their needs before go-live. Distinct from QA testing : QA tests against requirements (technical correctness). UAT tests against business needs (does it actually work for users?). QA role in UAT: 1. Plan UAT. - Test scenarios, sign-off criteria, schedule. - Identify UAT users. - Set up UAT sandbox with test data. 2. Train UAT users. - How to test, what to look for, how to log defects. 3. Support during UAT. - Field questions. - Triage defects vs feature requests. - Help users navigate. 4. Coordinate fixes. - Defects logged. - Dev triage. - Fixes deployed to UAT. - Re-test. 5. Sign-off. - Document UAT completion. - Track defects. - Determine readiness for go-live. Process: - UAT environment : typically Full Sandbox with realistic data. - Duration : 2-4 weeks typical. - Cadence : daily standup, UAT review meetings. - Defect triage : severity, owner, ETA. Sign-off criteria: - All Sev 1/2 defects resolved. - All UAT scenarios passed. - Stakeholder approval. Common pitfalls: - UAT done by wrong people — should be real users. - UAT too late — defects pile up; release delayed. - UAT environment not realistic

Question 6

Walk me through the bug / defect lifecycle.

Accepted Answer

Bug lifecycle : New - Triaged - Assigned - In Progress - Fixed - Verified - Closed. Stages: 1. New / Reported. - QA / user finds an issue. - Logs in tracking tool (Jira, Azure DevOps, etc.). - Includes: title, description, steps to reproduce, expected vs actual, environment, severity. 2. Triaged. - Reviewed by QA lead / dev lead / product owner. - Severity confirmed (Sev 1 critical, Sev 2 major, Sev 3 minor, Sev 4 cosmetic). - Priority assigned. - Routed to right team. 3. Assigned. - Developer assigned to fix. 4. In Progress. - Developer working on fix. - Branch created, code being written. 5. Fixed. - Developer commits fix; PR raised. - Code review. - Merged to develop / main. - Deployed to test environment. 6. Verification (QA retest). - QA retests with fix in test env. - Confirms fix works; no regression. 7. Verified. - QA marks as fixed. 8. Closed. - Defect closed in tracking system. - Audit log preserved. Other states: - Reopened : fix didn't work; defect reopened. - Won't Fix : decided not to fix; closed without resolution. - Cannot Reproduce : dev can't reproduce; QA provides more info or closes. - Duplicate : matches another defect; merged. Severity vs priority: - Severity

Question 7

What is Provar and what does it offer for Salesforce testing?

Accepted Answer

Provar is a Salesforce-specific test automation tool. Designed for Salesforce; understands its specifics. Capabilities: - Record-and-playback — capture actions in Salesforce; generate test scripts. - Object-aware — understands Salesforce metadata; tests survive UI changes better than generic Selenium. - Cross-browser / cross-device — tests run across configurations. - API testing — Salesforce REST/SOAP APIs. - Data-driven testing — parameterised tests. - CI/CD integration — Jenkins, GitHub Actions, etc. - Reporting — test results, screenshots, video. Why Salesforce-specific: - Lightning Component identifiers — Provar handles dynamic Salesforce DOM. - Sharing model awareness — tests can switch users. - Metadata-driven — tests reference Salesforce objects/fields, not hardcoded selectors. - Salesforce navigation patterns — built-in. Comparison with alternatives: - Selenium — generic; works with Salesforce but requires more maintenance as Salesforce evolves. - Cypress — modern JavaScript-based; works with Salesforce but limited Salesforce-aware features. - Tosca — enterprise; Salesforce among many supported platforms. - Provar — Salesforce-first; deep platform integration. When Provar

Question 8

What is Apex test coverage and why is 75% required?

Accepted Answer

Apex test coverage = percentage of Apex code lines exercised by unit tests. Salesforce requires 75% test coverage before deploying Apex code to production. Reasons: - Quality gate — untested code is high-risk. - Bulk-safety — tests exercise bulk patterns. - Regression — tests catch breaking changes. Coverage measurement: - Per Apex class: % of lines hit during test execution. - Triggers must have at least one test that touches them. - Test classes themselves don't count toward coverage (they're test code, not production). Salesforce's coverage rules: - Production deploy : org-wide coverage 75%+; individual triggers 1%+ (i.e., all triggers must be touched). - Sandbox deploy : less strict. Common coverage anti-patterns: - Coverage tests with no assertions — code lines exercised but behaviour unverified. - Tests that pass against any change — meaningless. - — tests depend on org data, fragile. Quality vs quantity: - 75% with assertions — meaningful. - 75% without assertions — meaningless. - 85%+ with assertions — strong. - Test code lines counted — write good tests, not just lines. Tools: - Apex Test Execution in Salesforce Setup. - VS Code Salesforce Extensions — coverage in IDE. - C

Question 9

How do you write effective test cases?

Accepted Answer

Effective test cases are clear, comprehensive, and maintainable. Structure: - ID : unique identifier (TC-101). - Title : brief description. - Module / feature : what's being tested. - Pre-conditions : state before testing. - Test data : specific values needed. - Steps : numbered, specific actions. - Expected results : what should happen. - Actual results : filled during execution. - Status : Pass / Fail / Blocked. - Severity / Priority : importance. Principles: 1. Specific and observable. - "User clicks Save button" — clear. - "User makes changes" — vague. 2. One thing per test. - Single objective. - Easier to debug failures. 3. Cover happy path AND edge cases. - Standard flow. - Boundaries (max field length, zero values). - Negative cases (invalid input). - Concurrency (multiple users). - Error scenarios. 4. Independent. - Tests don't depend on each other. - Each can run in isolation. 5. Repeatable. - Same input - same output. - Test data created/cleaned within test. 6. Maintainable. - Use shared resources (test data factories). - Don't duplicate logic. - Update as features evolve. 7. Use Gherkin / Given-When-Then format for behavior: Readable for business stakeholders too. Covera

Question 10

How do you test an Apex trigger?

Accepted Answer

Triggers fire automatically; testing them requires deliberate setup. Test class structure: Key patterns: 1. Bulk testing. Always test with 200 records to confirm bulkification. 2. / . Reset governor limits; flush async. 3. Cover all DML events. Insert, update, delete (where applicable). 4. Cover all paths. Happy path, edge cases, error scenarios. 5. Use . Shared data setup; runs once per class. 6. Assert behavior , not just coverage. 7. Mock dependencies if trigger has callouts or relies on async. 8. Test recursion handling. If trigger has recursion guard, test it works. Common pitfalls: - Single-record tests only. Doesn't catch bulk issues. - No bulk test. Trigger fails at 200 records in production. - Coverage tests, no assertions. Useless. - Fragile dependencies. — bad practice. Senior QA insight : trigger tests are critical . Production code paths fail at scale; tests must catch this. Bulk testing is mandatory. The senior framing: tests document trigger behavior. Future devs read tests to understand what trigger does.

Question 11

How do you test a Lightning Web Component?

Accepted Answer

LWC has dedicated testing via Jest . Setup: - — generates Jest config and setup. - Tests live in folder beside component. Anatomy: Patterns: 1. Test public API only. - properties + dispatched events. - Don't test private state. 2. Mock Apex calls. 3. Mock Lightning Data Service. Use mocks. 4. Async resolution. resolves on next microtask. Use between actions and assertions. 5. Snapshot tests sparingly. - Tempting but fragile. - Better: explicit assertions on key elements. 6. CI integration. - Jest runs in PR validation. - Coverage reported. - Failures block merge. Common pitfalls: - Testing implementation details. Private methods, internal state. Brittle. - Real Apex calls. Tests slow, fragile. Mock instead. - No cleanup. Tests interfere with each other. - Coverage without assertions. Same as Apex problem. Senior QA insight : LWC tests are JavaScript tests. Use JS testing patterns: AAA (Arrange/Act/Assert), mocking, async handling. The senior framing: LWC test coverage complements Apex coverage. Together they validate the full stack.

Question 12

How do you test Salesforce Flows?

Accepted Answer

Flows have less mature testing than Apex. Multiple approaches. 1. Manual testing in Flow Builder. - Debug Run — execute flow with controlled input. - Step through each element. - Inspect variables. - Validate decision paths. Best for: feature development, ad-hoc testing. 2. UAT. - Business users execute scenarios. - Manual verification of outcomes. - Time-consuming for complex flows. 3. Apex tests for invocable / record-triggered flows. - Trigger flow via Apex DML. - Assert resulting changes. 4. UI automation (Provar / Selenium / Cypress). - Test screen flows end-to-end. - Click through flow screens. - Validate final state. 5. Bulk testing. - Insert 200 records that trigger flow. - Confirm all process correctly. - Watch for governor limits. 6. Regression testing. - After flow changes, re-test affected scenarios. Salesforce Flow Test (newer feature): - Apex-style tests for autolaunched flows. - Salesforce's evolving testing capability. - Limited but growing. Common patterns: - Test each branch — every Decision element path. - Test failure handling — Fault Connector paths. - Test bulkification — flows can fail at 200 records. - Test permissions — flow runs in different user contexts.

Question 13

How do you manage test data for Salesforce testing?

Accepted Answer

Test data is the input that exercises tests. Strategy matters. Approaches: 1. Apex test data factories. Used by all Apex tests. Centralised; reusable. 2. . Class-level setup that runs once per test class. Shared data; rolled back at end. 3. Manual sandbox data for UAT. - Real-looking data for business user testing. - Curated; representative of production. - Refreshed periodically. 4. Anonymised production data. - Sensitive fields masked. - Realistic distributions, scale. - For performance testing, UAT. Tools: OwnBackup Sandbox Seeding, Gearset Compare, custom scripts. 5. Synthetic data generation. - Tools generate volume data. - Faker library for realistic-looking values. - For performance / load testing. 6. CSV / JSON files. - For data-driven tests (Provar, custom). - Same data across test runs. Architecture: - Factory class for unit tests. - Anonymised data set for UAT. - Synthetic data for performance. Common pitfalls: - tests — depend on org data; fragile. - Inline data setup — duplicated across tests. - Production data in sandboxes unmasked — compliance risk. - Stale UAT data — doesn't represent current production. Senior QA insight : test data is QA infrastructure. Invest in

Question 14

How do you test integrations between Salesforce and external systems?

Accepted Answer

Integration testing requires coordinating both sides. Levels: 1. Unit tests of integration code. - Apex tests with for outbound. - Mock external responses. - Test happy / error paths. 2. Component tests. - Salesforce side: Apex callout to mock external. - External side: receive Salesforce calls; respond. 3. End-to-end integration tests. - Salesforce + external system live. - Trigger real flow; observe both sides. - Often manual or UI automation. 4. Contract testing. - Define API contract. - Both sides test against contract. - Tools: Pact, Postman. 5. UAT. - Real users; real data; real systems. Test environments: - Salesforce sandbox + external test system . - Mock services for external when test instance unavailable. - Contract servers for contract testing. Test scenarios: - Success path — happy data, normal flow. - Failure of external — external down; Salesforce should handle gracefully. - Slow response — timeout handling. - Invalid data — external returns malformed data. - Authentication failure — token expired. - Rate limiting — external throttles. - Eventual consistency — async flows. Common pitfalls: - Only testing happy path — failures are common in production; not tested. -

Question 15

How does Apex test data isolation work?

Accepted Answer

Test data isolation : Apex tests don't see existing org data by default. Each test starts with a clean slate. Why: - Tests should be deterministic. - Tests should not depend on org-specific data. - Predictable across environments (dev, sandbox, production). for shared data: Runs once per class; data available to all test methods; rolled back at end. Disable isolation: — sees real org data. Strongly discouraged. Tests then depend on data that changes; flaky. When might be needed: - Legacy code that's hard to refactor. - Standard objects with data — Profiles, Permission Sets are referenced even with SeeAllData=false (always visible). - Specific Salesforce features that don't honor isolation. Bypass: build all data in test: Test data factory pattern: Reusable; reduces boilerplate. Common pitfalls: - — fragile tests. - Hardcoded IDs — tests work in dev, fail in another org. - Order-dependent tests — pass run together, fail in isolation. Senior QA insight : isolation makes tests durable. Invest in factories; avoid . The senior framing: tests should describe expected behavior independent of environment. Isolation enables that.

Question 16

How do you test something that depends on Salesforce's Order of Execution?

Accepted Answer

Order of Execution (OoE) : predictable sequence of operations on record save (validation, before-save flows, before triggers, save, after triggers, after-save flows, workflow rules, etc.). When testing, you need to know: - Which step fires first? - Re-entry : does workflow update re-trigger anything? - Field state at different points in execution. Test patterns: 1. Test before vs after triggers. Before triggers can modify Trigger.new directly without DML. 2. Test after-trigger side effects. After triggers run after database insert (record has Id). Test for child record creation, follow-up tasks, etc. 3. Test workflow re-entry. Workflow field updates re-fire before/after triggers and validation rules. Confirm logic handles this: 4. Test validation rules. 5. Test order between competing triggers. When multiple triggers (or trigger + flow) fire on same object, order is undefined. Best practice: one trigger per object. If multiple exist, test that the right one wins. 6. Test async after commit. Outbound Messages, async Apex ( , Queueable) fire AFTER commit-2. Use to flush. Common pitfalls: - Assuming order without testing. - Race conditions in multiple triggers. - Forgetting workflow r

Question 17

How do you test sharing rules and permissions?

Accepted Answer

Testing sharing requires running tests as different users. : Patterns: 1. Create test users with specific profiles / permission sets. 2. Run code as that user via . 3. Assert what they can / can't see. Test scenarios: - OWD enforcement : with Private OWD, owner sees, non-owner doesn't. - Role hierarchy : manager sees subordinate's records. - Sharing rule grants : criteria-based access works. - Manual sharing : per-record share works. - Apex Managed Sharing : programmatic shares work. - External user access : HVPU, Sharing Sets. Common pitfalls: - Tests run as System Admin — doesn't catch sharing issues. - No — tests don't validate sharing. - Ignoring user setup — test users must have appropriate profiles. Senior QA insight : sharing tests catch security regressions. Most sharing bugs surface in production because tests didn't run as right user. The senior framing: is the security-testing tool. Use deliberately for any sharing-sensitive code. Permission tests follow same pattern: create user with specific permission set; runAs them; assert they can/can't do what they should/shouldn't.

Question 18

How do you architect a test automation framework for Salesforce?

Accepted Answer

Architecture for test automation framework: tools + structure + practices. Components: 1. Tool selection. - Apex unit tests (mandatory for code coverage). - Jest for LWC. - Provar / Tosca / Selenium / Cypress for UI / end-to-end. - Postman / Newman for API. - JMeter / Gatling / k6 for performance. 2. Test pyramid. - Many unit tests (Apex, Jest) — fast, cheap. - Some integration tests — moderate. - Few end-to-end — slow, expensive. This shape minimises overall cost. 3. Test organisation. - Naming conventions — predictable. - Folder structure — by feature / module. - Test data factories — centralised. - Page objects / object repositories — for UI tests. 4. Reusability. - Common helpers for login, navigation, data setup. - Page object models for UI. - Custom assertions for Salesforce-specific. 5. Configuration. - Environment configs — sandbox URLs, credentials, feature flags. - Test data configs — test data per env. - Browser configs for UI. 6. CI/CD integration. - Tests run on every commit / PR. - Quality gates — coverage, pass rate. - Reporting — visible to team. 7. Reporting. - Dashboard — test results, trends. - Failure diagnostics — screenshots, logs, videos. - Stakeholder visibi

Question 19

How would you test a complex sharing model in Salesforce?

Accepted Answer

Complex sharing: multi-region OWD, role hierarchy, dozens of sharing rules, Apex managed sharing, Communities. Strategy: 1. Map the sharing model. - Document expected behavior per persona. - "Sales Rep in EMEA region sees own + team's opportunities." - "Service Manager sees all cases regardless of region." - "Partner Community user sees only their account's records." 2. Define test users per persona. - Create users with each profile / permission set / role / region combination. - Maintain in test data setup. 3. Test matrix. For each user × each record type × expected access (Read/Edit/None): | User Persona | Record Type | Expected Access | |---|---|---| | EMEA Sales Rep | Their own Opp | Read/Edit | | EMEA Sales Rep | Other EMEA Opp | Read | | EMEA Sales Rep | NA Opp | None | | Service Manager | Any Case | Read | | Partner Community | Account's Cases | Read | 4. Automated tests. Repeat per persona × scenario. 5. UI tests. - Login as each persona. - Navigate to records. - Verify what's visible / accessible. - Provar / Selenium / Cypress. 6. Sharing rule testing. - Create sharing rule. - Test data hits / misses rule criteria. - Confirm grant works. 7. Apex Managed Sharing testing. -

Question 20

Walk me through testing a major Salesforce release.

Accepted Answer

Major release = significant new feature, deployed to production. QA testing is critical. Pre-release planning: 1. Test strategy. - Scope of testing (features in release). - Types of testing (functional, integration, performance, UAT). - Resource plan (QA team, business users). - Timeline aligned with release schedule. 2. Test plan document. - Detailed test approach. - Test cases per feature. - Acceptance criteria. - Sign-off requirements. 3. Environment prep. - Test sandbox refreshed with current production. - Test data populated. - Integrations connected to test endpoints. Testing phases: 1. Unit testing (developer-led). - Apex unit tests. - LWC Jest tests. - Coverage 75%+. - All passing. 2. Component testing (QA-led). - Per-feature functional tests. - Test cases against requirements. - Manual + automated mix. 3. Integration testing (QA-led). - Cross-feature, cross-system. - End-to-end scenarios. 4. System testing (QA-led). - Full system in test environment. - All features together. 5. Performance testing. - Load tests, stress tests. - Identify bottlenecks. 6. Security testing. - Penetration test (often external). - Permission audit. - FLS / sharing validation. 7. UAT (business-le

Question 21

How do you handle flaky tests?

Accepted Answer

Flaky test : passes sometimes, fails sometimes; same code, same input. Root cause: hidden non-determinism. Common causes: - Time-dependence — , — same input on different days = different results. - Race conditions — multiple async operations; order varies. - External dependencies — test depends on network, external service availability. - Order dependence — tests pass together but fail in isolation (or vice versa). - Shared state — static variables persist between tests. - Insufficient waits — UI test acts before page ready. - Test data drift — tests depend on org data. Detection: - Run tests 100x in CI ; record failure rate. - Compare passing vs failing logs to find difference. Root cause analysis: For each flaky test, ask: - Time-dependent? - Async / race condition? - External dependency? - Order-dependent? - Shared state? Fix patterns: Time-dependent: Inject TimeService; mock current time. Async race: Add / to flush. For UI tests, explicit waits. External dependency: Mock instead of real call. Order dependence: Each test sets up own data; no shared state. Shared state: Reset static variables between tests. Insufficient waits: Replace with explicit conditional waits. Quarantine:

Question 22

How do you do performance and load testing for Salesforce?

Accepted Answer

Performance testing : how fast under normal conditions. Load testing : how it behaves under expected load. Stress testing : how it fails under extreme load. Tools: - Apache JMeter — generic; widely used. - Gatling — high-throughput, scriptable. - k6 — modern, JavaScript-based. - Salesforce-specific : Provar, Tosca with performance modules. - Browser-based : Lighthouse, WebPageTest for Lightning page performance. Test scenarios: 1. Page load time. - Lightning Record Pages. - Dashboard loading. - Search results. - Reports. Target: < 3 seconds for 95th percentile. 2. Bulk operations. - Mass record updates. - Large data loads (Bulk API). - Sharing recalculation. - Roll-up summary recomputation. 3. API integration. - Inbound webhook handling. - Outbound callouts. - High-volume integrations. 4. Concurrent users. - Simulate 100s, 1000s concurrent. - Record creation, search, navigation. - Identify contention. 5. Apex execution. - Trigger time per record. - Flow execution time. - Async job throughput. Approach: 1. Baseline measurement. - Current state performance. - Establish what's "normal". 2. Define targets. - Page load < X seconds. - Bulk operation < Y minutes. - N concurrent users with

Question 23

How do you do security and penetration testing for Salesforce?

Accepted Answer

Security testing identifies vulnerabilities. Penetration testing actively exploits to validate defenses. Salesforce platform security: - Salesforce-managed — multi-tenant security; you don't test the platform. - Your responsibility — your customisations: code, sharing, FLS, integrations. Areas to test: 1. Permissions. - Profiles, permission sets. - Object / field / system permissions. - Audit who has elevated access (View All, Modify All). - Test that least-privilege is enforced. 2. Sharing model. - OWD enforcement. - Sharing rules accurate. - No unintended cross-team access. 3. Field-Level Security. - Sensitive fields hidden from unauthorized profiles. - Encrypted fields properly encrypted. 4. Integration security. - Connected Apps with appropriate scopes. - API tokens properly secured. - HTTPS / TLS in transit. 5. SOQL injection. - Dynamic SOQL using bind variables. - User input properly escaped. - No SOQL concatenation with raw input. 6. XSS / CSRF. - Custom UI properly escapes output. - Visualforce uses encoders. - LWC handles input safely. 7. Authentication. - MFA enforced. - SSO properly configured. - Session settings appropriate. 8. Data protection. - Encryption for Restrict

Question 24

How do you test Salesforce Mobile?

Accepted Answer

Mobile testing is its own discipline. Mobile testing scope: - Salesforce Mobile App (most users). - Field Service Mobile App (field technicians). - Custom mobile apps (Mobile SDK). - Mobile web access (browser). Approaches: 1. Manual device testing. - Real devices: iPhone, Android, various models, sizes. - iOS / Android versions: latest + 1-2 prior. - Different network conditions: WiFi, 4G, offline. 2. Emulator / simulator testing. - iOS Simulator (Xcode). - Android Emulator. - Cheaper than real devices for breadth. - Limited for some features. 3. Cloud device labs. - BrowserStack, Sauce Labs, AWS Device Farm. - Hundreds of device-OS combinations. - Automated test runs. 4. Automated mobile testing. - Appium — generic mobile automation. - Provar / Tosca — Salesforce-aware mobile testing. - Detox — for custom React Native apps. Test scenarios: 1. Layout and rendering. - Lightning Record Pages adapt to phone form factor. - Compact Layouts render correctly. - Touch targets large enough. 2. Navigation. - Tab switching, swipes, gestures. - Deep linking. - Back-button behavior. 3. Data entry. - Forms, picklists, lookups. - Date/time pickers. - Camera / photo upload. 4. Performance. - Page

Question 25

How do you test AI / Agentforce features?

Accepted Answer

AI testing differs from deterministic testing. Same input may produce different outputs; need different approach. Challenges: - Non-deterministic — LLM responses vary. - Quality is subjective — "good answer" hard to define exactly. - Cost — every test call costs money. - Latency — LLM calls slow. - Bias — needs detection. - Hallucination — AI can confidently wrong. Test approaches: 1. Functional correctness. - For deterministic outputs (classification, score), traditional tests apply. - "Does this case classify as 'Billing' correctly?" 2. Quality assessment. - Sample AI outputs. - Rate against criteria (accuracy, helpfulness, tone). - Either human-graded or auto-graded against rubric. 3. Regression on tone / style. - AI output may shift over model updates. - Compare new outputs vs baseline. 4. Bias and fairness. - Test outputs across demographics. - Detect disparate treatment. 5. Hallucination detection. - Compare AI output against ground truth. - Flag inaccuracies. 6. Edge cases. - Adversarial inputs. - Edge of training distribution. - Out-of-scope queries. 7. Cost monitoring. - LLM tokens consumed per test. - Total test cost. 8. Performance. - Latency under load. - Concurrency. T

Question 26

How do you manage test environments for Salesforce?

Accepted Answer

Multiple environments serve different testing purposes. - Developer sandboxes — feature dev; metadata only. - Developer Pro — feature dev with sample data. - Partial Copy — UAT with subset of production data. - Full Sandbox — staging, performance, full UAT. - Production — live; not for testing. Refresh discipline : - Refresh kills in-flight changes; coordinate. - Frequent refresh keeps environment current. Per-environment data : - Test data factories for unit tests. - Anonymised production data for UAT. - Synthetic high-volume for performance. Common pitfalls : - One shared sandbox — collisions. - Refresh during UAT — destroys progress. - No refresh strategy — environments drift. Senior insight: environments are infrastructure . Plan thoughtfully.

Question 27

How do you do API testing for Salesforce?

Accepted Answer

Salesforce APIs (REST, SOAP, Bulk, Streaming, Pub/Sub) need testing like any other API. Tools : Postman, Insomnia, Newman (CLI), curl, custom scripts. Test scenarios : - Authentication (OAuth flows). - CRUD operations on standard / custom objects. - Bulk API job submissions. - SOQL queries. - Custom REST endpoints. - Error handling (invalid input, rate limits). Patterns : - Postman collections per API. - Newman for CI/CD execution. - Schema validation. - Performance under load. Salesforce-specific : - API versioning. - Connected App / OAuth setup. - Daily API call limits. - Bulk API job lifecycle. Senior insight: API tests are part of integration testing. Critical for integration-heavy orgs.

Question 28

How do you integrate testing into CI/CD?

Accepted Answer

Tests must run automatically on every change. Pipeline stages : - PR validation : scratch org, deploy, run tests, delete. Fast feedback. - Pre-deploy : validate-only deploy with full tests. - Post-deploy : smoke tests confirm working. Quality gates : - Apex coverage 75%+. - Test pass rate 100%. - PMD findings under threshold. Tools : GitHub Actions, GitLab CI, DevOps Center, Gearset, Copado. Test types in CI : - Apex unit tests (always). - Jest LWC tests (always). - API tests (Postman/Newman). - UI tests (selectively; slow). - Performance tests (periodically; not on every commit). Common pitfalls : - Slow pipeline — devs bypass. - Flaky tests — CI unreliable. - No quality gates — broken code reaches prod. Senior insight: CI is QA infrastructure. Investment pays back over years.

Question 29

What are common mocking patterns in Apex tests?

Accepted Answer

Mocking isolates code under test from real dependencies. Mock callouts with . Mock external services via Stub API: Mock SOQL via dependency injection: - Define interface for selector. - Production class queries; test class returns mock data. Mock Custom Metadata by injecting test instances. Mock current time by wrapping in TimeService. Mock Apex callouts in LWC tests via Jest: fflib ApexMocks — sophisticated open-source mocking library. Senior insight: mocking enables testing in isolation. Without mocks, tests are slow, flaky, dependent on external state.

Question 30

How do you architect test reporting?

Accepted Answer

Test reports communicate quality to stakeholders. Report types : - Daily test results — automated runs. - Coverage reports — code coverage trend. - Defect dashboards — open / closed by severity. - Release readiness — sign-off checklist. - Performance trends — latency over time. Audiences : - Developers : detailed logs, stack traces. - QA : pass/fail rates, coverage gaps. - Project managers : sign-off readiness, risk. - Executives : green/yellow/red status. Tools : - Jira / Azure DevOps — defect tracking. - TestRail / qTest / Zephyr — test case management. - Jenkins / GitHub Actions — CI test reports. - Custom dashboards — Tableau, Power BI on test data. Visualisation : - Pass rate trends. - Coverage by module. - Defect density. - Release health metrics. Senior insight: good reports drive action. Without reporting, quality is invisible.

Question 31

What's the difference between smoke, sanity, and exploratory testing?

Accepted Answer

Smoke testing : fast verification of core functionality after a build. "Does the basic stuff work?" - 5-15 minute test suite. - Critical paths only. - Run after every build / deploy. - Pass / fail quickly. Sanity testing : verification of specific feature after a fix or change. "Does this specific thing work?" - Targeted to recent changes. - More detail than smoke. - After fix or feature. Exploratory testing : unscripted exploration to discover unexpected issues. "What if I do this?" - No predefined script. - Tester explores intuitively. - Catches issues automation misses. - Hard to systematise. When to use : - Smoke : every build, automatically. - Sanity : when verifying specific changes. - Exploratory : throughout, especially for new features. Comparison : - Smoke / sanity = automation-friendly. - Exploratory = manual; human creativity. Senior insight: all three matter. Exploratory finds the bugs automation misses; smoke catches breakage; sanity verifies fixes.

Question 32

How do you test validation rules?

Accepted Answer

Validation rules must fire when expected and not fire when not. Test cases : - Should fire : invalid record save attempt; expect error. - Should not fire : valid record save; expect success. - Edge cases : boundary values, null handling. Apex test pattern : Manual / UI testing : - Try invalid input in UI. - Confirm error message shown. - Try valid input; confirm save. Common pitfalls : - Only testing happy path. - Not testing the error message text. - Validation rules with complex logic insufficiently tested. Senior insight: validation rules are easy to break. Tests catch regressions.

Question 33

How do you test an approval process?

Accepted Answer

Approval processes have multiple paths: submit, approve, reject, recall. Test cases : - Submit : triggered correctly when entry criteria met. - Step approver : correctly routed. - Approve at step : advances to next. - Reject at step : triggers rejection actions. - Final approval : triggers final actions. - Final rejection : triggers rejection. - Recall : triggers recall actions. Apex test : UI testing : Provar / Selenium drives submit / approve / reject manually. Common pitfalls : - Testing only submission, not approval. - No test for skipped steps. - Not testing recall. Senior insight: approval processes have many states. Comprehensive coverage required.

Question 34

How do you test page layout assignments?

Accepted Answer

Page layouts vary by profile + record type. Testing confirms users see right layout. Approach : - Login as each affected profile. - Navigate to records of each record type. - Verify expected fields visible. - Verify expected related lists. - Verify expected buttons. For Lightning Record Pages : - Confirm right Lightning Record Page renders for App + Record Type + Profile combination. Apex tests : limited — page layouts are config, not code. Use UI tests. Provar / Cypress : Common pitfalls : - Not testing per-profile. - Not testing per-record-type. - Lightning Record Page assignments overlooked. Senior insight: layout assignments break silently. Periodic verification matters.

Question 35

How do you test compliance requirements (GDPR, HIPAA, PCI)?

Accepted Answer

Compliance testing verifies regulatory requirements. GDPR scenarios : - Right to access : user requests data; system provides. - Right to be forgotten : user requests deletion; system anonymises / deletes. - Lawful basis : consent tracked; processing only with consent. - Breach notification : 72-hour process verified. HIPAA scenarios : - PHI encryption : sensitive fields encrypted. - Audit logging : every PHI access logged. - Authorisation : only approved roles access PHI. - Business Associate Agreement in place. PCI scenarios : - Tokenisation : card numbers tokenised, never stored full. - Encryption : in transit and at rest. - Access controls : PCI data access logged and restricted. Tests : - Permission tests : only approved roles see sensitive data. - Audit tests : every access logged. - Encryption tests : data encrypted at rest verified. - Workflow tests : right-to-be-forgotten works end-to-end. Documentation : - Compliance posture document. - Audit trail evidence . - Annual reviews / pentests . Tools : - Privacy Center for GDPR workflows. - Field Audit Trail / Event Monitoring for audit verification. - External pentest firms for compliance certification. Common pitfalls : - Com

Question 36

How do you do accessibility testing?

Accepted Answer

Accessibility = software usable by people with disabilities. Often legally required (Section 508 US, EAA EU). Standards : - WCAG 2.1 AA (most common). - WCAG 2.2 AAA (highest). - Section 508 (US federal). Test areas : - Keyboard navigation : all features accessible without mouse. - Screen reader : VoiceOver, NVDA, JAWS announce content correctly. - Color contrast : text legible. - Focus indicators : visible when tabbing. - Alt text : images described. - ARIA labels : dynamic content labeled. - Form labels : every input labeled. Tools : - axe DevTools — browser extension. - WAVE — accessibility checker. - Lighthouse — Chrome built-in. - Cypress + axe-core — automated. - Manual : real users with assistive tech. Salesforce specific : - Lightning components built on accessible primitives. - Custom components must follow WCAG. - Lightning Design System components are accessible by default. Common pitfalls : - Skipping accessibility — legal risk. - Custom components inaccessible. - Color-only conveying information. - No keyboard support. Senior insight: accessibility is good design. Helps everyone, mandatory for some.

Question 37

How do you test localization (multi-language, multi-currency)?

Accepted Answer

Localization testing verifies system works in different languages, currencies, regions. Test scenarios : Language : - UI labels translated. - Validation messages translated. - Error messages translated. - Date / time formats locale-aware. - Number / currency formats locale-aware. - Right-to-left languages (Arabic, Hebrew) — text mirrors. Currency : - Multi-currency conversions correct. - Reports show correct currency. - Currency display formats per locale. - Historical rates correct (with ACM). Regions : - Time zones handled correctly. - Business Hours per region. - Holidays per region. - Address formats per country. Test approach : - Switch user locale in test user record. - Test in each language systematically. - Native speakers preferred for translation quality. - UI tests with locale parameters. Common pitfalls : - English-only design — labels don't fit longer translations. - Hardcoded date formats — break in EU locale. - No translation review — machine-translated text awkward. - Currency calculations wrong — ACM not enabled. Tools : - Salesforce Translation Workbench — official translations. - Custom Labels — for code-driven strings. - Knowledge translation workflow — for cont

Question 38

How do you test code that depends on shared org-wide data (e.g., user settings, custom metadata)?

Accepted Answer

Some code depends on data that exists outside test isolation: User records, Profiles, Custom Metadata. User records : - Tests can create test users. - to test under that user. Profiles : - Profile records EXIST in test context (not isolated). - Reference profile by name: . Custom Metadata Type : - CMDT records ARE visible in tests (treated like metadata, not data). - No need to create in tests. Custom Settings : - Custom Setting records NOT visible in tests by default. - Create in if needed. Custom Permissions : - Visible in tests (metadata). Picklist values : - Defined in metadata; visible in tests. Test patterns : Common pitfalls : - Forgetting Custom Settings need explicit setup. - Hardcoded Profile IDs (varies per org). - Assuming all metadata visible (some isn't). Senior insight: understand what's visible vs not in tests. Patterns vary.

Question 39

How do you test asynchronous Apex (@future, Queueable, Batch)?

Accepted Answer

Async Apex needs special test patterns. Pattern : wrap async operation in / . Async runs synchronously when called. Specifics : : - Method must be static. - Can't accept sObjects (only IDs). - One future call per test method. Queueable : - Implement Queueable. - queues. - One Queueable runs per . - Chained Queueables: only first runs in test. Batch : - Execute via . - Test data goes through one batch chunk. - , , all run. Schedulable : - queues. - runs it. Common pitfalls : - Forgetting — async never runs. - Querying before — stale data. - Trying to test deep chain of Queueables — only first runs. Senior insight: async testing is critical but tooling has limits. Test what you can; manual for chained scenarios.

Question 40

How do you identify edge cases for testing?

Accepted Answer

Edge cases are the boundaries — where bugs hide. Categories : 1. Boundary values : - Min, max, zero, negative. - Field length limits. - Date range edges. 2. Empty / null : - Empty list, empty string, null reference. - Many code bugs are NPEs. 3. Special values : - Single quote in text fields. - Backslash, semicolon, special chars. - Unicode, emoji. - Very long strings. 4. Concurrency : - Two users editing same record. - Race conditions. - Stale data. 5. Permissions : - User without expected access. - User with extra access. 6. Dates and times : - Year-end, month-end. - Time zone boundaries. - Daylight saving. - Leap year. - Very old / very future dates. 7. Bulk : - 1 record vs 200. - 200 records. - Above 200 (governor limits). 8. Network : - Offline. - Slow network. - Timeout. 9. Localization : - Different locales, currencies, languages. 10. Error conditions : - Required field missing. - Validation failure. - External service down. Techniques : - Equivalence partitioning : group similar inputs. - Boundary value analysis : test edges. - Error guessing : from experience. - State transitions : all valid transitions. - Use case coverage : end-to-end paths. Senior QA insight : edge case

Question 41

How does Salesforce DX change testing practices?

Accepted Answer

Salesforce DX (Developer Experience) brings modern dev practices to Salesforce. Affects testing: Scratch orgs for testing : - Spin up disposable orgs. - Each test run in fresh environment. - Reproducible. - Isolated. Source-driven : - Code in Git; tests in Git. - Branch per feature. - Test in feature branch before merge. CI/CD : - Tests run automatically on PR. - Quality gates. - Fast feedback. Tooling : - VS Code Salesforce Extensions — run tests inline. - Salesforce CLI — scripted test execution. - Apex Replay Debugger — debug from logs. - Jest — LWC testing locally. Differences from old way : Old : tests run in shared sandbox; manual triggers; flaky. New : tests run in scratch orgs; automated; reproducible. Test-driven development possible : - Write test first. - Run locally; sees failure. - Implement code; run again; sees pass. Continuous integration normal : - Every commit triggers tests. - Coverage tracked over time. - Trends visible. Architecture : - Sources of truth: Git (metadata + code), Salesforce (runtime). - Tests version-controlled. - Test data in factories, not org-specific. Common pitfalls : - DX adoption without test discipline — opportunity wasted. - Tests that de

Question 42

What is risk-based testing and how do you apply it?

Accepted Answer

Risk-based testing : prioritise testing based on risk (probability × impact). Steps : 1. Identify risks . For each feature / module: - Probability of failure : likely / moderate / unlikely. - Impact if it fails : critical / major / minor. 2. Score : Risk = Probability × Impact. 3. Prioritise : - High risk : comprehensive testing. - Medium risk : standard testing. - Low risk : smoke testing only. Examples : - Payment processing — high impact (money). High risk; thorough testing. - User profile photo — low impact. Low risk; light testing. - New feature replacing critical workflow — high impact. High risk; thorough. - Cosmetic UI tweak — low impact. Low risk; minimal. Risk factors : - Complexity of code. - Recent changes. - Past defect density. - Business-critical paths. - Customer-facing. - Compliance-relevant. Application : For a release: - Identify what changed. - Score risks. - Allocate testing effort accordingly. - Don't test everything equally. For a feature : - Critical paths = comprehensive. - Edge cases = limited. Common pitfalls : - Equal effort across all features — wastes time on low risk. - Skipping risk assessment — random prioritization. - Ignoring risk for thoroughness

Question 43

How does Salesforce testing differ for industry verticals (Health, Financial, Public Sector)?

Accepted Answer

Industry verticals add specific testing dimensions. Health Cloud : - HIPAA compliance — PHI protected, encrypted. - Patient data — accuracy, privacy. - Care plans — treatment workflow. - EMR integration — accurate sync. Financial Services Cloud : - Regulatory compliance — FINRA, SEC, GDPR. - Financial accuracy — calculations exact. - Householding — relationship logic correct. - Insurance policy lifecycle — accurate state transitions. Public Sector : - FedRAMP / Section 508 — accessibility mandatory. - Citizen-facing portals — public access. - Records retention — long-term archival. - Open records / FOIA — data export. Manufacturing : - Account-based selling — complex hierarchies. - Inventory management — accurate counts. - CPQ accuracy — quote calculations. Industry-specific testing additions : - Compliance audits — regular. - Vertical workflows — specific to industry. - Vertical integrations — to industry systems. - Vertical UX — built for the persona. Talent : - Industry-specific QAs — knowledge of regulations + workflows. - Specialised certifications — Health Cloud, Financial Services Cloud certs. Common pitfalls : - Generic testing for vertical org — misses compliance. - Indust

Question 44

How does QA collaborate effectively with developers?

Accepted Answer

Strong dev-QA collaboration multiplies team effectiveness. Practices : 1. Shared understanding of requirements. QA reviews user stories. Asks clarifying questions. Identifies test scenarios. Catches ambiguities. 2. Test cases written before / during dev. Not after. Dev sees test cases; builds to pass them. TDD-adjacent. 3. Pair sessions. Dev + QA work together on hard problems. 4. Regular triage. Defects triaged daily. Both teams agree on priority. 5. Knowledge sharing. Dev explains technical context. QA explains business context. Both grow. 6. Avoid antagonism. QA isn't out to find bugs to embarrass devs. Devs aren't dismissing QA findings. 7. Joint definition of "done". Includes tests passing, coverage met, UAT confirmed. 8. Co-ownership of quality. Quality isn't just QA's job. Devs own quality of their code; QA owns process. 9. Mutual respect for expertise. QA knows business / quality patterns. Devs know technical depth. Combine. 10. Communication. Regular standups, sprint reviews, retros. Same room. Anti-patterns : - Throw it over the wall — dev finishes; QA finds defects late. - Adversarial relationship — finger pointing. - QA after dev — testing as cleanup, not concurrent. -

Question 45

When do you decide to stop testing?

Accepted Answer

Testing has diminishing returns. Knowing when to stop is judgement. Indicators it's time : 1. Test coverage targets met. - Apex coverage 75%+. - Test cases for all requirements. 2. Known critical paths verified. - Smoke tests pass. - High-risk scenarios passed. 3. Stakeholder sign-off. - UAT signed off. - Business stakeholders accept. 4. Defect rate trending down. - Few new defects in recent runs. - Most defects are minor. 5. Schedule pressure. - Release date approaching. - Cost of further delay cost of remaining defects. 6. Risk acceptable. - Remaining risks documented. - Stakeholders accept residual risk. Indicators it's NOT time : - High defect discovery rate continues. - Unverified critical paths. - Untested edge cases. - Stakeholder concerns unaddressed. - Performance / security concerns. Decision factors : - Cost of bug in production vs cost of testing more. - Available time before release . - Confidence level in current test results. Risk-adjusted decision : - High-risk system (banking, healthcare): test more. - Low-risk system (internal tool): test less, accept risk. Common pitfalls : - Testing forever — perfect is enemy of good. - Stopping too early — defects in production

Question 46

How do you anonymise production data for non-production use?

Accepted Answer

Production data in sandboxes is risky (compliance, privacy). Anonymise before use. What needs anonymising : - PII : names, emails, phones, addresses, SSN. - PCI : payment card data. - PHI : health records. - Other sensitive : salary, performance reviews, etc. Approaches : 1. Mask values . Replace with realistic-looking but fake data: - "John Doe" - "Anonymous-1" - "john@example.com" - "user-1@example.com" - "555-123-4567" - "555-000-0001" 2. Hash values . Replace with hash; same input - same output. Preserves uniqueness without revealing real values. 3. Tokenise . Replace with token; map kept secure for de-tokenisation if needed (rare in test contexts). 4. Delete . Remove fields entirely. 5. Anonymise in place . Apply transformations to existing records. 6. Sample . Take subset of production; anonymise only that subset. Tools : - OwnBackup Sandbox Seeding — automated anonymisation. - Gearset Compare — selective deploy with masking. - Custom Apex for one-off anonymisation. - DataPrivacyManager — third-party. Process : 1. Identify sensitive fields — data classification. 2. Define anonymisation rules per field. 3. Apply during sandbox refresh or post-refresh. 4. Verify — spot-check th

Question 47

Walk me through the test pyramid for Salesforce.

Accepted Answer

Test pyramid : shape of test investment by type. Bottom: Unit tests (most). - Apex unit tests — code-level. - Jest tests — LWC. - Fast — milliseconds. - Reliable — deterministic. - Cheap — runs on every commit. Aim: 70-80% of total test count. Middle: Integration tests. - Component tests — multi-class flows. - API tests — Salesforce APIs. - Mock external calls — controlled environment. - Moderate speed — seconds. Aim: 15-20% of test count. Top: End-to-end tests. - UI automation — Provar / Selenium / Cypress. - Full system — frontend + backend + integrations. - Slow — minutes. - Brittle — UI changes break. - Expensive to maintain. Aim: 5-10% of test count. Why pyramid shape : - Cost — top-of-pyramid tests cost more per test (writing, running, maintaining). - Speed — top tests slower; CI cycles. - Reliability — top tests more flaky. Anti-pattern: Inverted pyramid. - Many UI tests, few unit tests. - Slow CI, brittle, expensive. - Common in immature QA practices. Anti-pattern: Hourglass (no integration tests). - Unit + UI but no integration. - Integration bugs missed. Architectural decisions : - Code structure matters — more unit-testable if classes have clear boundaries. - Mocking ena

Question 48

How do you test Salesforce platform releases (Spring, Summer, Winter)?

Accepted Answer

Salesforce releases 3 times/year. New features, behavior changes, deprecations affect orgs. Approach : 1. Pre-release sandbox. - Sandboxes upgraded to new release before production. - Test for 4-8 weeks. 2. Read release notes. - Identify changes affecting your org. - Categorize: new features, behavior changes, deprecations, fixes. 3. Inventory affected code. - Apex classes / triggers using deprecated patterns. - LWC / Aura affected by Lightning Web Security changes. - Integrations affected by API changes. 4. Run regression suite. - Automated tests against new release sandbox. - Identify breakages. 5. Manual exploration. - Focus on new features. - Verify compatibility. 6. Performance comparison. - Are pages still as fast? - Bulk operations still meeting targets? 7. Defect log. - Track release-induced defects. - Coordinate fixes before production rolls. 8. Production rollout. - Salesforce releases to production on its own schedule. - Re-verify after production update. Specific things to check each release : - Trigger frameworks against new platform. - Lightning Locker - LWS compatibility. - API version impacts. - Picklist value changes. - Deprecated feature behavior. - New AI / Agent

Question 49

What QA metrics and KPIs matter at architect level?

Accepted Answer

Quality is measurable. Right metrics drive the right behaviors. Test metrics : - Test coverage (Apex 75%+; LWC; UI). - Test pass rate in CI. - Test execution time — how long to run full suite. - Test maintenance cost — time fixing broken tests. Defect metrics : - Defect density — defects per feature / KLOC. - Defect leakage — defects found in production vs caught in QA. - Time to fix — by severity. - Reopen rate — fixes that didn't work. Velocity metrics : - Time to market — feature idea to production. - Release frequency — how often you ship. - Cycle time — start of feature to production. Quality outcomes : - Production incident rate — quality reaching users. - Mean time to recovery — when things break. - Customer satisfaction with quality. Process metrics : - Sprint commitment vs delivery . - Testing automation rate — % automated. - Code review feedback rate . Reporting : - Daily : pass rate, blockers. - Weekly : trends, defect status. - Monthly : deeper analysis. - Quarterly : strategic review. Anti-patterns : - Vanity metrics — count of tests without coverage. - Coverage-only — without quality. - Defect count as success metric — misleading; depends on testing intensity. Senior

Question 50

How do you build a Salesforce QA team?

Accepted Answer

Building QA teams: hiring, structure, skills, growth. Team structure : - QA Engineer — manual + light automation. - Test Automation Engineer — automation focus. - Performance Engineer — load / performance. - Security Tester — pentesting. - QA Lead — strategy, coordination. - QA Manager — across teams. Skill mix : - Salesforce platform knowledge. - Testing methodologies. - Tools (Provar, Selenium, JIRA). - Some scripting (Apex, JS, SQL). - Communication with devs and business. Hiring : - External hire : existing Salesforce QA experience. - Internal transfer : train Salesforce admin - QA. - Mix : balance experience with platform knowledge. Sizing : - Ratio of devs to QAs varies (1:1 to 4:1). - Mature orgs : more shift-left to dev unit testing; fewer dedicated QAs. - Manual-heavy orgs : more QAs. Growth path : - Junior QA - Senior QA - Test Lead - QA Manager - Director QA . - Specialist tracks : Performance, Security, Automation Architect. Training : - Trailhead for Salesforce. - Certifications : Admin, Platform App Builder. - Test methodology training (ISTQB). - Tool-specific training (Provar Academy). Culture : - Quality is everyone's job — not QA-only. - Continuous improvement. - B

Question 51

What is continuous testing?

Accepted Answer

Continuous testing : tests running automatically throughout the dev pipeline, providing constant quality feedback. Touchpoints : - Pre-commit (developer machine). - On commit (CI fast tests). - On PR (full validation suite). - Pre-merge (quality gates). - Post-deploy (smoke / monitoring tests). Tools : GitHub Actions, GitLab CI, Jenkins; integrated with Salesforce DX. Quality gates : - Coverage 75%+. - All tests pass. - PMD findings under threshold. - Code review approved. Result : bugs caught early, fast feedback, consistent quality. Anti-patterns : tests run weekly, manual triggers, broken tests ignored, slow pipelines. Senior insight: continuous testing requires investment but pays back through prevented production issues.

Question 52

How do you test Omni-Channel routing?

Accepted Answer

Omni-Channel routes work to agents based on capacity and skills. Test scenarios : - Routing rules : case routes to right queue / agent based on criteria. - Skill-based routing : case routes to skilled agent. - Capacity : agent at capacity skipped; next agent gets work. - Presence statuses : agent unavailable - skipped. - Decline behavior : agent declines - next agent. - Fallback : no eligible agent - overflow queue. Setup : - Test users with different skills, presence configurations. - Test cases / leads with various criteria. Run : - Submit work via Omni-Channel. - Verify it lands with expected agent. - Check queue behavior. - Test edge cases (full capacity, all unavailable). UI testing with Provar / Cypress for end-to-end agent experience. Common pitfalls : - Skipping multi-agent scenarios. - Not testing capacity overflow. - No declined-routing test. Senior insight: Omni-Channel is rules-driven; test all rules paths.

Question 53

How do you test Experience Cloud (Communities)?

Accepted Answer

Experience Cloud has external users; testing differs from internal. External user setup : - Create test community user. - Different licenses (Customer Community, Customer Community Plus, Partner). - Access via "Login As" or actual login. Test scenarios : - Self-service portal : customer searches Knowledge, submits Case. - Sharing : external user sees only their data + Sharing Set grants. - Authentication : SSO + Salesforce-managed login. - Branding : theme renders correctly. - Mobile responsiveness . - Performance under external user load. Specific testing : - Sharing Sets — rules grant correctly. - HVPU users — limited access verified. - Public read — data visible to guest users. - Knowledge — articles accessible. Tools : Selenium / Cypress / Provar against community URL. Browser-based. Common pitfalls : - Internal-user testing only — external behavior different. - Not testing on mobile. - Auth flows untested. - Performance tested only with internal users. Senior insight: Experience Cloud is the public face. Testing matters more for customer experience.

Question 54

How do you test a data migration?

Accepted Answer

Migration testing verifies data moved correctly from source to target. Test scenarios : 1. Volume : - All source records migrated. - Row counts match. 2. Mapping : - Source field - target field correct. - Transformations applied correctly. 3. Relationships : - Lookups / master-detail pointing right. - No orphaned children. 4. Quality : - No nulls in required fields. - Picklist values valid. - Date formats correct. 5. Sample reconciliation : - Spot-check 100+ records source vs target. - Confirm content preserved. 6. Reports : - Critical reports work post-migration. - Aggregates match source. 7. Sharing : - Owners set correctly. - Sharing rules apply correctly. 8. Edge cases : - Records with attachments. - Special characters. - Long text fields. - Records with deleted parents. Approach : - Multiple test passes — small sample, partial volume, full volume. - Reconciliation reports — automated comparison. - Manual spot checks . - Test in Full Sandbox before production. Common pitfalls : - Insufficient test passes. - Not testing edge cases. - No reconciliation reports. Senior insight: migration testing is high-stakes . Production cutover happens once; defects expensive to fix.

Question 55

How do you test a Lightning Record Page?

Accepted Answer

Lightning Record Pages are configured per object + record type + profile + app combo. Test scenarios : - Right page renders for user / record type / app. - Components visible as expected. - Conditional visibility rules work. - Highlights panel shows expected fields. - Tabs render with right content. - Custom components function. - Mobile vs desktop form factors. - Performance — page load time. Approach : - Login as each test persona. - Navigate to records of each type. - Visually confirm layout. - Check Components for functionality. - Mobile preview in App Builder. Tools : - Manual visual inspection. - UI automation (Provar) for repeated checks. - Browser DevTools for performance. Common pitfalls : - Testing with one user / record type only. - Skipping mobile. - Not testing conditional visibility paths. Senior insight: Lightning Record Pages are user experience. Test the actual experience, not just config existence.

Question 56

How do you test Einstein features (lead scoring, opportunity insights)?

Accepted Answer

Einstein features are AI-driven; testing differs. Pre-conditions : - Einstein enabled in org. - Sufficient data for AI to learn (typically 1000+ records). - Time for model training. Test scenarios : 1. Configuration . - Einstein feature enabled correctly. - Permission to access feature. - Right users see right insights. 2. Functionality . - Score / insight populates on records. - Updated periodically. - Visible in expected UI components. 3. Data quality . - Score range plausible. - Insights make sense (sanity check). - Doesn't update for trivial changes. 4. Performance . - Score computation doesn't slow page load. - Bulk operations not affected. Limits to expect : - Non-deterministic — same data may produce slightly different scores. - Lag — model updates periodically, not real-time. - Trust Layer intervenes for sensitive data. Common pitfalls : - Testing too early — before model trained. - Insufficient data — model can't produce meaningful scores. - Testing as deterministic — failures from variation. Senior insight: Einstein testing requires patience and statistical thinking. Not 100% deterministic.

Question 57

How do you test cross-org integrations (multi-org Salesforce)?

Accepted Answer

Multi-org integrations: data flowing between separate Salesforce orgs. Test scenarios : - Outbound from Source org : change in Source triggers sync to Target. - Inbound to Target org : data arrives correctly. - Identity federation : SSO works across orgs. - Consistency : same data eventually in both. - Conflict resolution : simultaneous updates handled. - Failure modes : source down, target down, network issue. Setup : - Test sandbox per org. - Same identity / SSO setup. - Test integration backbone (Mulesoft) configured. Approach : - Trigger source change. - Verify event published. - Verify Mulesoft processes. - Verify target updates. - Check timing (eventual consistency). - Check edge cases. Tools : - Postman for API tests. - Apex tests on each side. - End-to-end with manual coordination. Common pitfalls : - Testing one direction only . - No conflict tests . - Network resilience untested . Senior insight: cross-org tests require multi-org coordination . More complex than single-org. The senior framing: multi-org architectures need multi-org testing .

Question 58

How do you continuously improve QA processes?

Accepted Answer

QA processes age. Continuous improvement keeps them effective. Mechanisms : 1. Retrospectives . - After releases. - After incidents. - What worked / didn't / change. 2. Metrics review . - Defect leakage trending up? - Test pass rate dropping? - Cycle time growing? Drives action. 3. Feedback loops . - Devs frustrated with QA process? Listen. - Stakeholders unhappy? Adjust. 4. Tool evaluation . - New tools emerging. - Existing tools' alternatives. 5. Training . - New methodologies (BDD, exploratory). - Salesforce platform updates. - Tool-specific certifications. 6. Pilot new approaches . - Small experiments. - Measure impact. - Roll out if successful. 7. Industry engagement . - Conferences (Trailhead Live, Dreamforce). - Communities (Trailblazer Slack). - Blogs and podcasts. Common patterns : - Quarterly process review. - Annual major changes. - Continuous small improvements. Anti-patterns : - Frozen processes — no improvement. - Random changes — without data. - Reactive only — wait for crisis. Senior insight: process improvement is QA's improvement responsibility. Without it, processes degrade. The senior framing: deliberate retrospectives + metrics drive sustainable improvement.

Question 59

How do you architect a sandbox strategy for testing?

Accepted Answer

Sandboxes serve different testing purposes; strategy matters. Tier strategy : - Developer sandboxes : per-developer; rapid iteration; daily refresh. - Integration : shared by team; weekly refresh. - UAT : business user testing; less frequent refresh during UAT. - Performance / staging : Full Sandbox; mirrors production. - Hotfix : dedicated for emergency fixes. Refresh discipline : - Refreshing destroys in-flight work. - Coordinate; communicate. - Pre-refresh: export anything to preserve. - Post-refresh: redeploy any custom data. Source-control alignment : - Each sandbox = a Git branch. - Deploy from Git via CLI / DevOps platform. - Avoid editing in sandbox UI; commit first. Test data per sandbox : - Dev: minimal sample data. - Integration: test data factories. - UAT: anonymised production-like. - Performance: synthetic high-volume. - Staging: production-mirror. Cost considerations : - Full Sandbox is expensive. - Plan budget; right-size. - Don't over-provision; don't under-provision. Common pitfalls : - One shared sandbox — collisions. - Refreshing during testing — destroys progress. - No test data strategy. Senior insight: sandbox strategy is QA infrastructure . Plan deliberately

Question 60

What goes in a Test Strategy document?

Accepted Answer

Test Strategy guides project testing. Distinct from Test Plan (project-specific). Sections : 1. Scope and objectives. - What's in scope; what's out. - Test goals. - Success criteria. 2. Test approach. - Test levels (unit, integration, system, UAT). - Test types (functional, non-functional). - Manual vs automated mix. 3. Test environment. - Sandbox tiers. - Data strategy. - Tools. 4. Resources. - Team composition. - Skills needed. - External resources (vendors). 5. Schedule. - High-level testing timeline. - Milestones. - Dependencies. 6. Risk management. - Top risks with mitigation. - Contingencies. 7. Quality gates. - Coverage thresholds. - Defect severity tolerances. - Sign-off criteria. 8. Reporting and communication. - Cadence. - Audiences. - Format. 9. Tools and infrastructure. - Test management. - Automation tools. - CI/CD. 10. Standards and conventions. - Test case format. - Naming. - Documentation. Audience : project sponsor, project manager, dev lead, QA team, stakeholders. Maintenance : living document; review quarterly. Common pitfalls : - No strategy — ad-hoc testing. - Strategy too generic — doesn't guide actual decisions. - Strategy ignored — written, never read. Senio

Question 61

What are TDD and BDD and when do you apply them in Salesforce?

Accepted Answer

Test-Driven Development (TDD) : write test first; implement code to pass; refactor. Behavior-Driven Development (BDD) : describe behavior in natural language; auto-generated tests. Tools: Cucumber , Gauge . TDD applied in Salesforce : - Apex code: write test first; implement. - Forces design clarity. - Drives modularity. - Most senior dev practice. BDD applied in Salesforce : - Better for collaboration with business. - Tests double as documentation. - Used in some agile teams. - Tooling more limited than TDD. Realistic adoption : - TDD partial adoption common — write tests soon after code, not strictly first. - BDD rare in pure form — Gherkin syntax used for documentation, not always automation. Benefits : - Cleaner code — easier to test. - Confidence in changes — tests catch regressions. - Documentation — tests describe expected behavior. Common pitfalls : - TDD without discipline — write code, then write tests retroactively. - BDD without tooling — manual translation defeats purpose. Senior insight: TDD/BDD are practices, not just tools . Discipline matters. The senior framing: adopt elements of TDD/BDD where they add value; don't religiously apply.

Question 62

How do you manage test debt?

Accepted Answer

Test debt : outdated, missing, or low-quality tests. Like tech debt for tests. Types of test debt : - Missing tests for features. - Stale tests for changed features. - Flaky tests that don't reliably pass. - Slow tests that bog down CI. - Coverage gaps — areas without tests. - Bad test data that breaks tests. Identification : - Test coverage report — see gaps. - CI failure analysis — flaky tests obvious. - Test execution time — slow tests cumulative. - Pass rate trend — increasing failures = debt. Strategies : 1. Test debt sprints. - Quarterly dedicated time. - Pay down accumulated debt. - Fix flaky, add missing. 2. Per-feature commitment. - Every new feature includes tests. - Cleanup of related debt. 3. Quality gates. - Coverage threshold. - Pass rate requirement. - Blocks new debt. 4. Continuous improvement. - Each retrospective: identify test debt. - Plan to address. Prioritization : - High-value debt first — tests for critical paths. - Quick wins — flaky test fixes. - High-cost debt later — comprehensive rewrite. Common pitfalls : - Ignoring debt — accumulates. - All-at-once cleanup — disruption. - No measurement — can't improve what you can't see. Senior QA insight : test debt

Question 63

Walk me through testing a large new feature.

Accepted Answer

Large feature = significant complexity, multiple components, many edge cases. Phase 1: Discovery participation. - Attend Discovery sessions. - Understand requirements. - Identify test scenarios early. - Estimate testing effort. Phase 2: Test planning. - Test plan document. - Test cases (functional, non-functional). - Test data needs. - Resource plan. Phase 3: Test development. - Apex unit tests written alongside code (ideally TDD). - LWC Jest tests. - Integration tests. - UI test automation. Phase 4: Component testing. - Each component tested in isolation. - Bugs surfaced and fixed. Phase 5: Integration testing. - Components together. - Cross-component flows. - End-to-end scenarios. Phase 6: System testing. - Full feature in system context. - Performance under expected load. - Security validated. Phase 7: UAT. - Business users test. - Sign-off criteria. Phase 8: Regression. - Automated regression on existing functionality. - Confirm no breakage. Phase 9: Release readiness. - All gates met. - Sign-off. Phase 10: Post-release. - Monitor production. - Gather feedback. - Address surfaced issues. Common pitfalls : - Testing too late — defects pile up. - Insufficient regression — old fea

Question 64

How does QA work in agile / Scrum?

Accepted Answer

Agile changes QA from end-of-cycle to continuous. Within sprint : - Sprint planning : QA participates; estimates testing effort. - Story refinement : QA contributes acceptance criteria. - Daily standups : testing progress / blockers. - Mid-sprint testing : as code merges, tests run. - Sprint review / demo : tested features shown. - Sprint retro : process improvements. Test approach : - Tests in same sprint as feature — not deferred. - Continuous testing — CI/CD-driven. - Definition of Done includes tests passing, coverage met. Sprint length implications : - 2-week sprint : ambitious; tests + feature in 2 weeks. - 3-4-week sprint : more time for thorough testing. Roles : - QAs embedded in dev teams — not separate. - Pairing with devs on hard tests. - Joint ownership of quality . Anti-patterns : - QA at end — defeats agile. - QA in separate team — coordination friction. - Tests in next sprint — debt accumulates. Specific Salesforce considerations : - Sprint 0 for initial setup. - Discovery before sprints. - UAT spans multiple sprints typically. Senior QA insight : agile requires shift-left . QA earlier, more continuous, more collaborative. The senior framing: agile QA is a lifestyle

Salesforce QA / Tester interview questions

Top 10 must-know

All 100 questions

Easy

Medium

Hard

Top 10 must-know

1What does a Salesforce QA / Tester do day-to-day?easy

2What's the difference between manual and automated testing?easy

3Walk me through the bug / defect lifecycle.easy

4What is Apex test coverage and why is 75% required?easy

5How do you write effective test cases?medium

6How do you test an Apex trigger?medium

7How do you architect a test automation framework for Salesforce?hard

8How do you handle flaky tests?hard

9What is shift-left testing and how do you implement it?medium

10What's the most important thing a Salesforce QA can do to be effective?hard

All 100 questions

Easy

What does a Salesforce QA / Tester do day-to-day?easy

What's the difference between manual and automated testing?easy

What's the difference between a test case and a test script?easy

What is regression testing and why does it matter?easy

What is User Acceptance Testing (UAT) and what is the QA role in it?easy

Walk me through the bug / defect lifecycle.easy

What is Provar and what does it offer for Salesforce testing?easy

What is Apex test coverage and why is 75% required?easy

How do you manage test environments for Salesforce?easy

How do you do API testing for Salesforce?easy

How do you integrate testing into CI/CD?easy

What are common mocking patterns in Apex tests?easy

How do you architect test reporting?easy

What's the difference between smoke, sanity, and exploratory testing?easy

How do you test validation rules?easy

How do you test an approval process?easy

How do you test page layout assignments?easy

What is continuous testing?easy

How do you test Omni-Channel routing?easy

How do you test Experience Cloud (Communities)?easy

How do you test a data migration?easy

How do you test a Lightning Record Page?easy

How do you test Einstein features (lead scoring, opportunity insights)?easy

How do you test cross-org integrations (multi-org Salesforce)?easy

How do you continuously improve QA processes?easy

What is visual regression testing?easy

How do you test Field Service Mobile?easy

How do you test Marketing Cloud Engagement (MCE)?easy

How do you test Pardot / Marketing Cloud Account Engagement?easy

How do you test Salesforce CPQ?easy

Medium

How do you write effective test cases?medium

How do you test an Apex trigger?medium

How do you test a Lightning Web Component?medium

How do you test Salesforce Flows?medium

How do you manage test data for Salesforce testing?medium

How do you test integrations between Salesforce and external systems?medium

How does Apex test data isolation work?medium

How do you test something that depends on Salesforce's Order of Execution?medium

How do you test sharing rules and permissions?medium

How do you test compliance requirements (GDPR, HIPAA, PCI)?medium

How do you do accessibility testing?medium

How do you test localization (multi-language, multi-currency)?medium

How do you test code that depends on shared org-wide data (e.g., user settings, custom metadata)?medium

How do you test asynchronous Apex (@future, Queueable, Batch)?medium

How do you identify edge cases for testing?medium

How does Salesforce DX change testing practices?medium

What is risk-based testing and how do you apply it?medium

How does Salesforce testing differ for industry verticals (Health, Financial, Public Sector)?medium

How does QA collaborate effectively with developers?medium

When do you decide to stop testing?medium

How do you anonymise production data for non-production use?medium

Walk me through the test pyramid for Salesforce.medium

How do you test Salesforce platform releases (Spring, Summer, Winter)?medium

What QA metrics and KPIs matter at architect level?medium

How do you build a Salesforce QA team?medium

How do you architect a sandbox strategy for testing?medium

What goes in a Test Strategy document?medium

What are TDD and BDD and when do you apply them in Salesforce?medium

How do you manage test debt?medium

Walk me through testing a large new feature.medium

How does QA work in agile / Scrum?medium

How do you manage test flakiness organisationally?medium

What's the difference between load and stress testing?medium

How do you test permissions and permission sets?medium

What's the role of a QA leader?medium

What's the ROI of investing in QA?medium