QA / Tester interview questions

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 code causes production incidents. Senior QAs are the safety net between dev and production.

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 stay manual. Everything else automate.

The senior framing: automation is leverage; use it for the right tasks.

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: technical impact (Sev 1 = system down, Sev 4 = cosmetic).
• Priority: business urgency (P1 = must fix now, P4 = next release).

A Sev 4 in customer-facing area might be P1; a Sev 1 in rarely-used area might be P3.

Senior QA insight: good defect reports are precise. Vague defects waste developer time. Reproducible steps + environment + expected vs actual save hours.

The senior framing: defect tracking is institutional memory. Future-you / future-team learns from past defects. Treat the tracker as a knowledge base.

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.
• `@isTest(SeeAllData=true)` — 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.
• CI/CD — automated coverage check.
• Apex Code Analyzer — quality + coverage analysis.

Beyond Apex:

• LWC testing with Jest — separate tool, separate coverage.
• Flow testing — limited tools.
• Manual / UAT testing — coverage of features, not just code.

Senior QA insight: 75% is a gate, not a goal. Aim higher. And coverage without assertions is meaningless. Quality of tests matters more than the number.

The senior framing: tests are documentation of expected behavior. Each test asserts: "given X, when Y, then Z." Run tests; behaviour is documented.

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:

Given a Lead with Status = Working
When user clicks Convert Lead
Then Account, Contact, Opportunity are created
And Lead Status = Converted

Readable for business stakeholders too.

Coverage strategy:

• Equivalence partitioning — group similar inputs.
• Boundary value analysis — test edges (0, 1, max-1, max).
• State transitions — test all stage transitions.
• Error guessing — based on experience.
• Use case scenarios — end-to-end paths.

Common pitfalls:

• Vague test cases — "test login" tells you nothing.
• Massive test cases — 50 steps, hard to debug.
• No expected results — "user does something" without expected outcome.
• Outdated test cases — system changed; test wasn't updated.

Senior QA insight: good test cases are documentation. Future testers should be able to execute without prior knowledge.

The senior framing: writing test cases is harder than executing them. Investment in good test cases pays back across many runs.

Triggers fire automatically; testing them requires deliberate setup.

Test class structure:

@isTest
private class AccountTriggerTest {
    
    @TestSetup
    static void setup() {
        // Create base test data
        Account a = new Account(Name='Test Account');
        insert a;
    }
    
    @isTest
    static void testInsertSetsIndustryDefault() {
        // Arrange
        Account a = new Account(Name='New Account');
        
        // Act
        Test.startTest();
        insert a;
        Test.stopTest();
        
        // Assert
        Account inserted = [SELECT Industry FROM Account WHERE Id=:a.Id];
        System.assertEquals('Technology', inserted.Industry);
    }
    
    @isTest
    static void testBulkInsert() {
        List<Account> accounts = new List<Account>();
        for (Integer i=0; i<200; i++) {
            accounts.add(new Account(Name='Bulk '+i));
        }
        Test.startTest();
        insert accounts;
        Test.stopTest();
        
        // Assert all 200 processed correctly
        List<Account> inserted = [SELECT Id FROM Account WHERE Name LIKE 'Bulk %'];
        System.assertEquals(200, inserted.size());
    }
    
    @isTest
    static void testUpdateTriggersFollowUp() {
        Account a = [SELECT Id FROM Account LIMIT 1];
        a.Status__c = 'Active';
        
        Test.startTest();
        update a;
        Test.stopTest();
        
        // Assert downstream effect
        Task[] tasks = [SELECT Id FROM Task WHERE WhatId=:a.Id];
        System.assertEquals(1, tasks.size());
    }
}

Key patterns:

1. Bulk testing. Always test with 200 records to confirm bulkification.

2. `Test.startTest()` / `Test.stopTest()`. 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 `@TestSetup`. 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. @isTest(SeeAllData=true) — 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.

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 visibility — pass rate over time.

8. Maintenance.

• Owners per test suite.
• Update process — when feature changes, tests change.
• Flaky test management — tag, fix, or retire.
• Periodic review — remove obsolete.

9. Test environments.

• Scratch orgs for isolated runs.
• Dedicated test sandbox for full suite.
• Stable test data across runs.

10. Skills.

• Test automation engineers — write framework.
• QA analysts — write test cases.
• Devs — write unit tests.

Common pitfalls:

• Over-investing in UI tests — slow, fragile.
• Under-investing in unit tests — bugs missed.
• No framework — every test reinvents wheel.
• No reporting — can't see what's working.
• Flaky tests ignored — erodes trust.

Senior QA insight: automation framework is QA infrastructure. Invest deliberately. Pays back over years.

The senior framing: the test pyramid is a cost optimization. Minimum slow tests; maximum fast tests. Everything in between.

Flaky test: passes sometimes, fails sometimes; same code, same input. Root cause: hidden non-determinism.

Common causes:

• Time-dependence — Date.today(), DateTime.now() — 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 — SeeAllData=true 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.

public virtual class TimeService {
    public virtual DateTime getNow() { return DateTime.now(); }
}
// Test: provide mock TimeService

Async race: Add Test.startTest() / Test.stopTest() 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 Thread.sleep() with explicit conditional waits.

Quarantine:

• If can't fix immediately, mark as flaky.
• Skip in CI but track.
• Don't block releases on flaky tests.

Process:

1. Detect flaky tests.
2. Triage — quarantine if blocking, fix if possible.
3. Root cause systematically.
4. Fix properly.
5. Verify — re-run 100x.
6. Remove from quarantine.

Common pitfalls:

• Ignoring flaky tests — erodes trust in suite.
• Retrying — masks the issue.
• Disabling without quarantine — lost forever.
• No process — flakies accumulate.

Senior QA insight: flaky tests poison the well. They erode developer confidence in the suite. Aggressively address them.

The senior framing: a flaky test is a broken test. Treat with same urgency as a failing test.

Shift-left: move testing earlier in development cycle.

Old way: dev writes code; QA tests after; defects late, expensive.

New way (shift-left): testing happens during dev. Defects caught early; cheap.

Practices:

1. Test cases written before code.

• During requirements / Discovery.
• Forces clarity.
• Devs build to known criteria.

2. Pair dev + QA.

• Together for hard problems.
• Knowledge sharing.

3. Test-Driven Development (TDD).

• Write test; implement; refactor.

4. Continuous testing.

• CI/CD runs tests on every commit.
• Fast feedback to developers.

5. Devs write more tests.

• Apex unit tests by devs (mandatory).
• LWC Jest tests by devs.

6. Code review focuses on testability.

• Reviewers ask: "is this tested?"

7. Static analysis early.

• PMD, ESLint, security scanners.
• Issues identified pre-merge.

8. Lint rules in IDE.

• Issues caught while typing.

9. Pre-commit hooks.

• Tests run locally before commit.

Benefits:

• Earlier defects = cheaper to fix.
• Faster feedback = faster delivery.
• Quality culture = team-wide ownership.

Anti-patterns:

• QA at end — old waterfall mode.
• QA-only quality — devs disengaged.
• No automation — slow feedback.

Salesforce specifics:

• Apex tests mandatory at deploy.
• Jest for LWC.
• DX-driven testing — local + CI.

Senior QA insight: shift-left is a culture change. Tools matter; mindset matters more.

The senior framing: quality is everyone's job. Shift-left makes it real.

The single highest-leverage activity for QA: build trust through reliable, valuable testing.

Why trust matters:

When dev / product / stakeholders trust QA:

• They listen to defect findings.
• They invest in test infrastructure.
• They include QA early in design.
• They protect QA's recommendations.

When trust is absent:

• Findings dismissed.
• Investment scarce.
• QA at end of cycle.
• Recommendations ignored.

Building trust:

1. Reliable.

• Defects logged are real.
• Tests give consistent results.
• Predictable cadence.

2. Valuable.

• Find bugs others miss.
• Provide insights beyond pass/fail.
• Save time / money.

3. Specific.

• Defect reports concrete and reproducible.
• Status updates clear.
• Recommendations actionable.

4. Diplomatic.

• Push back without antagonising.
• Listen to concerns.
• Acknowledge constraints.

5. Continuous.

• Show value across many projects.
• Build track record.

Beyond trust:

• Continuous learning — stay current.
• Quality advocacy — champion org-wide.
• Mentorship — develop next generation.
• Process improvement — make QA better.

Senior QA insight: trust is QA's currency. Without it, work stalls.

The senior framing: the best QAs are sought out for their judgment. They earn this through reliability and value over time.

Career-defining habits: be the QA stakeholders want at every important meeting. They include you because your contribution improves outcomes.

That's senior QA.

Test case: human-readable description of what to test.

Test Case: TC-101 — Lead Conversion
Pre-condition: User logged in as Sales Rep; Lead exists with Status = Working.
Steps:
1. Open the Lead record.
2. Click Convert Lead button.
3. Confirm Account, Contact, Opportunity created.
4. Confirm Lead Status = Converted.
Expected: Lead converted; new Account, Contact, Opportunity records visible.

Used for: manual testing, planning, sign-off, audit.

Test script: code that executes the test case.

// Cypress / Provar / Selenium pseudocode
test('Lead conversion creates Account, Contact, Opportunity', async () => {
  await loginAs('Sales Rep');
  await navigateTo(`/leads/${leadId}`);
  await click('Convert Lead');
  await fillForm(...);
  await click('Save');
  expect(await accountExists()).toBe(true);
  expect(await contactExists()).toBe(true);
  expect(await opportunityExists()).toBe(true);
});

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.

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 bugs from product bugs.
• Fix product bugs; update test bugs.

Common pitfalls:

• No regression suite — bugs find production.
• Stale tests — tests don't match current product.
• Manual-only regression — too slow; gets skipped.
• Flaky tests — failing intermittently; teams ignore.

Senior QA insight: regression suite is QA infrastructure. Invest deliberately. Pays back across every release.

The senior framing: without regression, every release is risky. With it, releases become routine.

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 — defects only show in production.
• UAT defects ignored — go-live with known issues.

Senior QA insight: UAT is the business validation step. Technical correctness ≠ business correctness. UAT catches the gap.

The senior framing: prepare UAT for success. Good UAT: clear scenarios, realistic data, engaged users, structured triage.

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 wins:

• Salesforce-heavy testing — most tests are Salesforce.
• Lightning UI — Provar handles updates well.
• Test maintenance burden — Provar reduces brittleness.
• Team familiar — Provar specialty.

Cost:

• Provar is licensed per concurrent user / runner.
• More expensive than open-source alternatives.
• Justified if Salesforce testing volume is high.

Trade-offs:

• Pros: faster Salesforce test creation, lower maintenance, deep platform integration.
• Cons: licensing cost, vendor-specific.

Senior QA insight: Provar is the Salesforce-specific automation choice for organisations doing serious Salesforce automation. For light testing, generic tools may suffice.

Provar tests should still be designed well — automation tool doesn't replace test design discipline.

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.

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.

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.

Mocking isolates code under test from real dependencies.

Mock callouts with Test.setMock(HttpCalloutMock.class, new MyMock()).

Mock external services via Stub API:

Test.createStub(MyService.class, new MyStub());

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:

jest.mock('@salesforce/apex/MyClass.method', () => ({
    default: jest.fn()
}), { virtual: true });

fflib_ApexMocks — sophisticated open-source mocking library.

Senior insight: mocking enables testing in isolation. Without mocks, tests are slow, flaky, dependent on external state.

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.

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.

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:

@isTest
static void testRuleFiresOnInvalid() {
    Account a = new Account(Name=null); // missing required
    try {
        insert a;
        System.assert(false, 'Should have thrown');
    } catch (DmlException e) {
        System.assert(e.getMessage().contains('Required'));
    }
}

@isTest
static void testRuleAllowsValid() {
    Account a = new Account(Name='Valid');
    insert a;
    System.assertNotEquals(null, a.Id);
}

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.

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:

@isTest
static void testApprovalSubmission() {
    Opportunity o = new Opportunity(Name='Test', StageName='Negotiation', Amount=10000, CloseDate=Date.today());
    insert o;
    
    Approval.ProcessSubmitRequest req = new Approval.ProcessSubmitRequest();
    req.setObjectId(o.Id);
    Approval.ProcessResult result = Approval.process(req);
    
    System.assert(result.isSuccess());
    System.assertEquals(1, [SELECT count() FROM ProcessInstance WHERE TargetObjectId=:o.Id]);
}

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.

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:

test('Sales Rep sees correct layout', async () => {
    await loginAs('sales-rep');
    await navigateTo('/account/recordType=B2B/123');
    await assertVisible('Account.Annual_Revenue__c');
    await assertVisible('Related: Opportunities');
    await assertNotVisible('Account.Internal_Notes__c'); // hidden for sales rep
});

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.

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.

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.

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.

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.

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.

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.

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.

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.

Visual regression: detect unintended UI changes by comparing screenshots before/after.

Process:

• Capture baseline screenshot.
• Make change.
• Capture new screenshot.
• Compare pixel-by-pixel.
• Flag differences.

Tools: Percy, Chromatic, BackstopJS, Applitools.

Use cases:

• Lightning page rendering.
• Custom LWC components.
• Email templates.
• Dashboard layouts.

Pros: catches visual bugs missed by functional tests.

Cons: brittle (false positives from minor renderings), expensive at scale.

Best for: visual-critical components, brand-sensitive UI.

Senior insight: visual regression complements but doesn't replace functional testing.

Field Service Mobile has unique testing needs — offline, mobile, dispatcher console.

Test areas:

• Dispatcher Console: scheduling, gantt, drag-drop assignments.
• Mobile App: offline work order access, photo capture, signature.
• Routing: appointment optimization.
• Schedules: technician availability, working hours.
• Inventory: track and consume parts.
• Sync: data flowing field <-> Salesforce.

Test environments:

• Sandbox + Field Service mobile app installed.
• Test technician users with mobile licences.
• Test crew configurations.

Approach:

• Real device testing for mobile.
• Cellular vs WiFi tests.
• Offline mode — disconnect, work, reconnect.
• Sync conflicts — same record changed offline + online.
• Dispatcher actions verified on technician device.

Common pitfalls:

• Skipping offline tests.
• One device only.
• No conflict tests.

Senior insight: Field Service is mobile-first. Test on actual phones.

MCE is separate platform; testing differs from Salesforce CRM.

Test areas:

• Email Studio: email rendering across clients.
• Journey Builder: journey paths, decisions.
• Mobile Studio: SMS / push delivery.
• Audience Builder: segmentation accuracy.
• Contact Builder: Data Extension structure.
• Marketing Cloud Connect: sync with Salesforce CRM.
• Personalisation: AmpScript / SSJS rendering.

Tools:

• MCE Email Preview — client rendering.
• Litmus / Email on Acid — across email clients.
• Manual testing for journey flows.
• API testing with Postman.

Approach:

• Send test emails through journey.
• Verify templates render correctly.
• Check logs for delivery success.
• Validate decisions — paths taken correctly.
• Manual approval before mass send.

Common pitfalls:

• Skipping email client testing.
• No Marketing Cloud Connect verification.
• Personalisation untested.

Senior insight: MCE testing is different from CRM testing. Tooling, approach distinct.

Pardot/MCAE lives inside Salesforce; testing leverages Salesforce + Pardot UI.

Test areas:

• Form submissions create Prospects.
• Lead scoring computed correctly.
• Engagement Studio flows execute.
• Dynamic content renders based on rules.
• Salesforce sync — Prospect ↔ Lead/Contact.
• Email templates render and deliver.
• Landing pages render and convert.
• Files / assets track engagement.

Approach:

• Submit form → verify Prospect created.
• Trigger engagement → verify steps execute.
• Sync → verify Lead in Salesforce.
• Score change → verify trigger fires.

Test data:

• Test prospect lists.
• Email-safe domains for testing.

Common pitfalls:

• Email sends going to real customers.
• Sync testing skipped.
• Edge cases (existing prospect, dupes) untested.

Senior insight: Pardot tests email infrastructure. Mistakes hit real users.

CPQ adds quoting complexity to Sales Cloud; testing is detailed.

Test areas:

• Product configuration: bundles, options, dependent products.
• Pricing: tiered, contracted, dynamic.
• Discount approvals: workflow gates non-standard discounts.
• Quote document generation: PDF rendering.
• Quote-to-Order: data flow.
• Subscriptions: renewal, amendment.
• Multi-currency: conversions correct.

Test scenarios:

• Standard quote: simple product.
• Bundle quote: configurable products.
• Discount within threshold: auto-approved.
• Discount over threshold: routed for approval.
• Renewal: existing subscription becomes opportunity.
• Amendment: mid-term changes.

Approach:

• Apex unit tests for CPQ calculations.
• UI testing for quote configuration flow.
• PDF verification — content correct.
• End-to-end: quote → order → fulfilment.

Common pitfalls:

• Calculations: complex, easy to break.
• Approval routing: many paths.
• Currency conversion: edge cases.

Senior insight: CPQ is calculation-heavy; tests are critical. Bugs cost money directly.

LWC has dedicated testing via Jest.

Setup:

• sf force lightning lwc test setup — generates Jest config and setup.
• Tests live in __tests__ folder beside component.

Anatomy:

import { createElement } from 'lwc';
import MyComponent from 'c/myComponent';

describe('c-my-component', () => {
    afterEach(() => {
        // Reset DOM between tests
        while (document.body.firstChild) {
            document.body.removeChild(document.body.firstChild);
        }
    });

    it('renders a header with the title prop', () => {
        const element = createElement('c-my-component', { is: MyComponent });
        element.title = 'Hello World';
        document.body.appendChild(element);

        const h1 = element.shadowRoot.querySelector('h1');
        expect(h1.textContent).toBe('Hello World');
    });

    it('dispatches userselected event on click', () => {
        const element = createElement('c-my-component', { is: MyComponent });
        document.body.appendChild(element);

        const handler = jest.fn();
        element.addEventListener('userselected', handler);

        const button = element.shadowRoot.querySelector('button');
        button.click();

        expect(handler).toHaveBeenCalled();
        expect(handler.mock.calls[0][0].detail.userId).toBe('001x');
    });
});

Patterns:

1. Test public API only.

• @api properties + dispatched events.
• Don't test private state.

2. Mock Apex calls.

import getRecord from '@salesforce/apex/AccountController.getRecord';
jest.mock('@salesforce/apex/AccountController.getRecord', () => ({
    default: jest.fn()
}), { virtual: true });

it('renders data from Apex', async () => {
    getRecord.mockResolvedValue({ Id: '001x', Name: 'Acme' });
    // ... render component, assert
});

3. Mock Lightning Data Service.

Use @salesforce/sfdx-lwc-jest mocks.

4. Async resolution.

@wire resolves on next microtask. Use await Promise.resolve() 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.

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.

@isTest
static void testRecordTriggeredFlow() {
    Account a = new Account(Name='Test', Status__c='Active');
    
    Test.startTest();
    insert a;
    Test.stopTest();
    
    // Flow should have created a Task
    List<Task> tasks = [SELECT Id FROM Task WHERE WhatId=:a.Id];
    System.assertEquals(1, tasks.size());
}

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.

Common pitfalls:

• No flow tests — flow changes go untested.
• Manual-only testing — slow, error-prone.
• No bulk testing — flow fails at scale.
• Fault paths untested — error handling broken.

Senior QA insight: flow testing is challenging but increasingly mature. Salesforce investing in better flow testing tools.

The senior framing: don't skip flow testing because tooling is harder. Find approaches that work for your context.

Test data is the input that exercises tests. Strategy matters.

Approaches:

1. Apex test data factories.

public class TestDataFactory {
    public static List<Account> createAccounts(Integer n) {
        List<Account> accs = new List<Account>();
        for (Integer i = 0; i < n; i++) {
            accs.add(new Account(Name='Test Account '+i));
        }
        insert accs;
        return accs;
    }
}

Used by all Apex tests. Centralised; reusable.

2. `@TestSetup`.

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:

• `SeeAllData=true` 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 factories, anonymisation tools, synthetic data generation.

The senior framing: bad test data = bad tests. Garbage in, garbage out.

Integration testing requires coordinating both sides.

Levels:

1. Unit tests of integration code.

• Apex tests with Test.setMock(HttpCalloutMock.class) 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.
• No mocking — tests dependent on external availability; flaky.
• Manual integration tests — slow, skipped under deadline pressure.
• No contract — Salesforce + external diverge; integration breaks silently.

Architecture for testability:

• Wrap external dependencies in interfaces / Apex classes.
• Mockable via dependency injection.
• Configurable via Custom Metadata for endpoint switching.
• Logging all integration events for forensics.

Senior QA insight: integrations break in production — they're a top source of incidents. Comprehensive integration testing pays back.

The senior framing: integrations are the most fragile parts of Salesforce systems. Test them most carefully.

Test data isolation: Apex tests don't see existing org data by default. Each test starts with a clean slate.

@isTest
private class MyTest {
    @isTest
    static void testSomething() {
        // [SELECT Id FROM Account] returns 0 even if production has 1000
    }
}

Why:

• Tests should be deterministic.
• Tests should not depend on org-specific data.
• Predictable across environments (dev, sandbox, production).

`@TestSetup` for shared data:

@TestSetup
static void setup() {
    Account a = new Account(Name='Test');
    insert a;
}

Runs once per class; data available to all test methods; rolled back at end.

Disable isolation:

@isTest(SeeAllData=true) — sees real org data.

Strongly discouraged. Tests then depend on data that changes; flaky.

When SeeAllData=true 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:

@isTest
static void testCorrectly() {
    Account a = new Account(Name='Test');
    insert a;
    
    Contact c = new Contact(LastName='Test', AccountId=a.Id);
    insert c;
    
    // Now test
}

Test data factory pattern:

public class TestDataFactory {
    public static Account createAccount(String name) {
        Account a = new Account(Name=name);
        insert a;
        return a;
    }
}

Reusable; reduces boilerplate.

Common pitfalls:

• `SeeAllData=true` — 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 SeeAllData=true.

The senior framing: tests should describe expected behavior independent of environment. Isolation enables that.

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.

@isTest
static void testBeforeTriggerUpdatesField() {
    Account a = new Account(Name='Test');
    
    Test.startTest();
    insert a;
    Test.stopTest();
    
    // Before trigger should have set Industry
    Account inserted = [SELECT Industry FROM Account WHERE Id=:a.Id];
    System.assertEquals('Default', inserted.Industry);
}

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:

@isTest
static void testWorkflowRefireGotcha() {
    Account a = new Account(Name='Test', Status__c='Active');
    insert a;
    
    // Confirm the field update from Workflow didn't cause unexpected behavior
}

4. Test validation rules.

@isTest
static void testValidationRuleBlocks() {
    Account a = new Account(Name=null); // Required field missing
    
    try {
        insert a;
        System.assert(false, 'Should have thrown');
    } catch (DmlException e) {
        System.assert(e.getMessage().contains('Required'));
    }
}

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 (@future, Queueable) fire AFTER commit-2. Use Test.startTest()/stopTest() to flush.

Common pitfalls:

• Assuming order without testing.
• Race conditions in multiple triggers.
• Forgetting workflow re-entry.
• Not flushing async in tests.

Senior QA insight: OoE bugs are subtle. Tests must explicitly cover the orderings expected. Most production bugs are timing / order issues.

The senior framing: Salesforce's OoE is well-defined; your code must respect it. Tests verify both.

Testing sharing requires running tests as different users.

`System.runAs()`:

@isTest
static void testSharingForSalesUser() {
    // Setup data as System Admin (not in runAs)
    Account a = new Account(Name='Sales-Owned');
    a.OwnerId = createSalesUser().Id;
    insert a;
    
    // Now run as a different user
    User otherSalesUser = createSalesUser();
    System.runAs(otherSalesUser) {
        // What does this user see?
        List<Account> visible = [SELECT Id FROM Account];
        System.assert(visible.isEmpty() || !visible[0].Id.equals(a.Id),
            'Other Sales User should NOT see private Account');
    }
}

Patterns:

1. Create test users with specific profiles / permission sets.

private static User createSalesUser() {
    Profile p = [SELECT Id FROM Profile WHERE Name='Sales Rep'];
    User u = new User(
        Username='test'+System.now().getTime()+'@example.com',
        Email='test@example.com',
        FirstName='Test', LastName='Sales',
        ProfileId=p.Id,
        Alias='tsls', TimeZoneSidKey='America/New_York',
        LocaleSidKey='en_US', EmailEncodingKey='UTF-8',
        LanguageLocaleKey='en_US'
    );
    insert u;
    return u;
}

2. Run code as that user via `System.runAs(user) { ... }`.

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 `System.runAs` — 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: `System.runAs` 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.

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:

• Compliance untested.
• Documentation insufficient.
• Encryption configured but not validated.

Senior insight: compliance is a binary outcome — passes or fails audit. Testing protects.

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.

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 content.

Senior insight: localization affects everything. UI, data, automation, reports.

Some code depends on data that exists outside test isolation: User records, Profiles, Custom Metadata.

User records:

• Tests can create test users.
• System.runAs(user) to test under that user.

Profiles:

• Profile records EXIST in test context (not isolated).
• Reference profile by name: [SELECT Id FROM Profile WHERE Name = 'Standard User'].

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 @TestSetup if needed.

Custom Permissions:

• Visible in tests (metadata).

Picklist values:

• Defined in metadata; visible in tests.

Test patterns:

@TestSetup
static void setup() {
    // For Custom Settings:
    My_Settings__c s = new My_Settings__c(Threshold__c=100);
    insert s;
}

@isTest
static void testWithCMDT() {
    // CMDT visible without setup
    My_Type__mdt config = My_Type__mdt.getInstance('Default');
    System.assertNotEquals(null, config);
}

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.

Async Apex needs special test patterns.

Pattern: wrap async operation in Test.startTest() / Test.stopTest(). Async runs synchronously when stopTest() called.

@isTest
static void testAsyncProcess() {
    Account a = new Account(Name='Test');
    insert a;
    
    Test.startTest();
    AsyncProcessor.processAsync(a.Id);  // queues async work
    Test.stopTest();  // <-- async runs here, synchronously
    
    Account refreshed = [SELECT Status__c FROM Account WHERE Id=:a.Id];
    System.assertEquals('Processed', refreshed.Status__c);
}

Specifics:

`@future`:

• Method must be static.
• Can't accept sObjects (only IDs).
• One future call per test method.

Queueable:

• Implement Queueable.
• System.enqueueJob(myJob) queues.
• One Queueable runs per Test.stopTest().
• Chained Queueables: only first runs in test.

Batch:

• Execute via Database.executeBatch(myBatch).
• Test data goes through one batch chunk.
• start(), execute(), finish() all run.

Schedulable:

• System.schedule(jobName, cronString, new MyJob()) queues.
• Test.stopTest() runs it.

Common pitfalls:

• Forgetting Test.stopTest() — async never runs.
• Querying before Test.stopTest() — 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.

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 cases reveal architectural decisions. Test cases that boundary-test help validate the design.

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 depend on org data — break in scratch orgs.
• No quality gates — broken code reaches main.

Senior insight: DX enables modern QA practices. Without DX, you're constrained.

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 — testing without focus.

Senior insight: risk-based testing maximizes ROI of test effort. Critical at scale.

The senior framing: testing budget is limited; risk-based allocation maximizes value.

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.
• Industry knowledge gaps in QA team.
• Audit unprepared — testing didn't cover compliance.

Senior QA insight: vertical orgs need vertical-aware QAs. Domain knowledge multiplies test effectiveness.

The senior framing: Salesforce QA in regulated industries is its own specialty.

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.
• No shared metrics — different goals.

Senior QA insight: QA and dev are partners, not adversaries. Quality is a team outcome.

The senior framing: the best QAs make devs better; the best devs make QAs more effective. Mutual elevation.

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.
• Stopping under pressure without risk assessment.

Senior QA insight: stopping is a deliberate decision based on risk. Document the decision.

The senior framing: define done before starting; revisit if circumstances change. Without a target, testing never ends.

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 that no PII remains.
5. Document for compliance.

Common pitfalls:

• Production data in sandbox unmasked — compliance violation.
• Inadequate anonymisation — reverse-engineerable.
• Field mismatch — anonymise some fields, leave others sensitive.

Senior QA insight: anonymisation is mandatory in regulated industries. Test environments shouldn't carry PII.

The senior framing: trust no one with production data; anonymise.

Test pyramid: shape of test investment by type.

        /\
       /  \      Few end-to-end tests (slow, expensive, brittle)
      /----\
     /      \    Some integration tests (moderate speed)
    /--------\
   /          \  Many unit tests (fast, cheap, focused)
  /____________\

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 enables more unit tests.
• Page object models keep UI tests maintainable.

Senior QA insight: test pyramid is cost optimization. Most tests should be cheap and fast.

The senior framing: invest in unit tests; restrain UI tests. That's the pyramid.

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 / Agentforce capabilities.

Common pitfalls:

• Skipping pre-release testing — defects in production.
• No release notes review — surprised by changes.
• Insufficient regression — silent breakages.

Senior QA insight: Salesforce releases are predictable but consequential. Treat them as quarterly testing events.

The senior framing: release testing is preventive. Catches issues before they affect users.

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 QA insight: measure outcomes, not activity. Production stability is the goal.

The senior framing: DORA-style metrics adapted for Salesforce QA: deploy frequency, lead time, change failure rate, MTTR.

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.
• Blameless incident reviews.
• Career investment.

Common pitfalls:

• QA undervalued — dev-heavy decisions.
• No career path — talent leaves.
• No tooling investment — manual everything.

Senior QA insight: a strong QA team prevents production incidents that would otherwise cost much more than the team. ROI is high if invested in.

The senior framing: QA is risk management. Investment proportional to risk.

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.

The senior framing: right environment for right test type. Don't test in wrong sandbox.

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.

Senior insight: Test Strategy is a coordination tool. Aligns team on approach.

The senior framing: without strategy, testing is random. With it, deliberate.

Test-Driven Development (TDD): write test first; implement code to pass; refactor.

// 1. Write failing test
@isTest
static void testCalculateScore() {
    Decimal score = ScoreCalculator.calculate(100);
    System.assertEquals(50, score);
}

// 2. Implement to pass
public class ScoreCalculator {
    public static Decimal calculate(Decimal input) {
        return input / 2;
    }
}

// 3. Refactor; tests still pass.

Behavior-Driven Development (BDD): describe behavior in natural language; auto-generated tests.

Given a Lead with Status = Working
When user clicks Convert Lead
Then Account, Contact, Opportunity created

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.

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 erodes test trust. When tests aren't reliable, everyone ignores failures.

The senior framing: healthy test suite is QA infrastructure investment. Without ongoing maintenance, it decays.

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 features break.
• No UAT — features don't fit users.
• Inadequate edge case coverage.

Senior insight: large features need structured testing. Without phases, chaos.

The senior framing: good testing prevents production incidents. Investment justified.

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 change. Embraces continuous testing; rejects batch testing.

Flakiness erodes test trust. Manage at team level.

Process:

1. Detect.

• Track flake rate per test.
• Rerun failing tests automatically; if pass, mark as flaky.
• CI tools support this.

2. Quarantine.

• Mark flaky tests as skipped.
• Don't block merges on them.
• Track in dedicated dashboard.

3. Root cause.

• Each flaky test gets investigation.
• Fix or retire.

4. Fix.

• Address root cause (not retry-loop).
• Re-run 100x to verify.
• Remove from quarantine.

5. Retire.

• If can't fix, remove.
• Don't keep dead weight.

Cultural elements:

• Flakiness is broken — same urgency as failures.
• No blame — flakies happen; fix them.
• Owner per flaky test — accountability.

Tools:

• Pytest-flaky for Python tests.
• Jest --retries for LWC.
• Custom CI logic for Apex.

Anti-patterns:

• Ignoring flakies — develops habit of ignoring failures.
• Retry-and-pray — mask not fix.
• Flakies accumulate — eventually unsustainable.

Senior QA insight: flaky tests are technical debt. Manage like code debt.

The senior framing: address aggressively before they normalize ignoring failures.

Both test under volume; goals differ.

Load testing: behavior under expected normal-to-peak load.

• "Can system handle 1000 concurrent users?"
• "Can it process 10,000 records/hour?"
• Pass: targets met.
• Fail: not.

Used for: validation pre-production.

Stress testing: behavior under extreme load to identify breaking point.

• "What happens at 10,000 concurrent users?"
• "What happens at 1M records?"
• Identify failure modes.
• Confirm graceful degradation.

Used for: understanding limits, capacity planning.

Other related:

• Endurance testing: sustained load over hours/days. Catches slow leaks (memory leaks, accumulating data).
• Spike testing: rapid increase then decrease. Tests elasticity.
• Soak testing: sustained moderate load over days. Reliability.

Salesforce considerations:

• Salesforce-managed infrastructure — load tests confirm your customisations don't break, not the platform.
• Governor limits — load tests reveal limit issues.
• Sandbox — performance differs from production.
• Realistic data — required for meaningful tests.

Tools:

• Apache JMeter — generic.
• Gatling, k6 — modern.
• Custom Apex for in-platform load.
• Browser tools for client-side performance.

Common pitfalls:

• Load test in tiny sandbox — meaningless.
• No realistic data — different from production.
• No baseline — can't compare.

Senior QA insight: load and stress complement each other. Load validates; stress reveals.

The senior framing: plan capacity from stress test results.

Permission tests verify users have what they need; nothing more.

Test scenarios:

• Without permission: user can't do.
• With permission via profile: user can do.
• With permission via permission set: user can do.
• With permission via permission set group: user can do.
• Without permission set licence (PSL): feature unavailable.
• System permissions: View All Data, Modify All Data work as expected.

Apex test pattern:

@isTest
static void testStandardUserCantViewAll() {
    Profile p = [SELECT Id FROM Profile WHERE Name='Standard User'];
    User u = new User(...ProfileId=p.Id);
    insert u;
    
    Account ownedByOthers = [SELECT Id FROM Account LIMIT 1];
    
    System.runAs(u) {
        try {
            Account a = [SELECT Id FROM Account WHERE Id=:ownedByOthers.Id];
            // If sharing model is Private, this should fail
            System.assert(false, 'User should not see this Account');
        } catch (QueryException e) {
            // Expected
        }
    }
}

Manual / UI testing:

• Login as test user.
• Navigate; click; verify what's accessible.
• Verify what's NOT accessible.
• Try API calls; verify FLS / sharing enforcement.

Common pitfalls:

• Testing only as System Admin — bypasses everything.
• No permission set assignment tests.
• PSL ignored.

Senior QA insight: permission tests are security tests. Production permission gaps = security incidents.

The senior framing: comprehensive permission testing matters at scale.

QA Lead / Manager directs the QA function.

Responsibilities:

1. Strategy.

• Test strategy across projects.
• Tools / methodologies.
• Standards.

2. Team management.

• Hiring, growth, performance reviews.
• Career development.
• Resource allocation.

3. Process.

• QA processes work end-to-end.
• Improvement cadence.
• Metrics / reporting.

4. Stakeholder management.

• Business / project stakeholders.
• Devs / dev leadership.
• Executive reporting.

5. Coordination.

• Across multiple projects.
• Across teams (dev, biz, infrastructure).

6. Quality advocacy.

• Champion quality.
• Push back on bad practices.
• Educate.

7. Mentor.

• Develop junior QAs.
• Share expertise.

8. Continuous improvement.

• Industry trends.
• New methodologies.
• Tool evaluation.

Skills:

• Technical depth.
• Leadership / people management.
• Communication.
• Strategic thinking.

Career path:

QA Engineer -> Senior QA -> QA Lead -> QA Manager -> Director QA -> VP Quality.

Senior insight: QA leaders set the quality bar for the organisation. Without strong leadership, quality drifts.

The senior framing: the best QA leaders are technical AND strategic. Both.

Quality investment returns through prevented defects, faster delivery, customer satisfaction.

Costs of inadequate QA:

• Production defects — incidents cost time, reputation, money.
• Rework — fixing late costs more than catching early.
• Customer churn — bad experience.
• Compliance violations — fines.
• Lost productivity — fixing bugs vs new features.

Returns from good QA:

• Fewer production incidents.
• Faster releases — confidence to ship.
• Higher customer satisfaction.
• Compliance posture.
• Developer productivity — fewer bugs to chase.

Quantifying:

• Defect leakage rate — defects in production / total defects.
• Mean time to recovery — incident duration.
• Customer-reported defects — leading indicator.
• Cost per defect by phase (early defects cheaper).

Industry benchmarks:

• Cost of fixing bug in dev = $X.
• Cost of fixing in QA = ~5X.
• Cost of fixing in production = ~30X.
• Cost of customer-found bug = ~100X.

Investment areas:

• Test automation — pays back across releases.
• Tooling — scales the team.
• Training — multiplier on team capability.
• Quality gates — prevent bad merges.

Common arguments:

• "QA is overhead" — true short-term; benefit long-term.
• "Just test in production" — expensive when defects happen.

Senior QA insight: QA ROI is hard to measure but real. Mature orgs invest deliberately.

The senior framing: the cost of poor quality is hidden but enormous. Good QA reveals and prevents it.

Comparison helps select right tool.

Provar:

• Salesforce-specific — designed for it.
• Pros: deep Salesforce integration, low maintenance, good for non-developers.
• Cons: licensed; specialty skill.
• Best for: Salesforce-heavy testing teams.

Tosca:

• Enterprise model-based testing.
• Pros: cross-platform, model-based generation, mature.
• Cons: licensing cost, learning curve.
• Best for: large enterprises with multi-platform testing.

Selenium:

• Open-source generic UI automation.
• Pros: free, large community, flexible.
• Cons: brittle for Salesforce (Lightning DOM changes), maintenance heavy.
• Best for: technical teams; cost-sensitive.

Cypress:

• Modern JavaScript-based.
• Pros: fast, dev-friendly, free.
• Cons: less Salesforce-specific awareness.
• Best for: dev-led testing.

Playwright:

• Newer Microsoft-backed.
• Pros: cross-browser, multiple language bindings.
• Cons: still maturing for Salesforce.
• Best for: cross-platform.

Appium:

• Mobile-focused.
• Best for: mobile testing.

Decision factors:

• Salesforce specificity needed? → Provar or Tosca.
• Generic platform support needed? → Selenium / Cypress / Playwright.
• Team skills? Match.
• Budget? Open-source cheaper.
• Maintenance burden — Provar least; Selenium most.

Hybrid strategies:

• Provar for Salesforce-specific tests.
• Cypress for non-Salesforce parts.
• Selenium for legacy.

Senior QA insight: tool choice depends on org maturity, skills, and tooling budget. No tool is universally best.

The senior framing: standardise; don't sprawl. One Salesforce tool + one general-purpose is usually enough.

Data Cloud is hyperscale data layer; testing focuses on data flows + identity resolution.