Salesforce Quality Assurance Intern

Sign up for a free Developer Edition org and build a CRM with at least three objects, relationships, validation rules, one automation, and three user profiles.

This is your system under test.

Write the test strategy before any test cases.

State what you are testing, what you are deliberately not testing, what you consider a pass, and what a blocking defect means versus a minor one.

Now design the test cases.

Write at least thirty covering positive paths where everything is correct, negative paths where input is wrong, boundary cases at the edges of field limits and date ranges, and permission cases per profile.

Each case needs an identifier, a precondition, numbered steps, the expected result, and space for the actual result.

Pay particular attention to negative cases, which are where defects actually live.

For every validation rule, write the case proving it blocks bad data and the case proving it permits good data, since a rule blocking everything also passes a careless test.

Add boundary cases deliberately: the maximum characters a field accepts, a date at the limit of a range, zero and negative numbers where only positives make sense.

Then prioritise.

Mark which cases must pass before release and which can wait, because a plan with no priority is unusable under deadline.

Finally, review your own plan for what it misses and write that gap down honestly.

Submit the system under test documentation, the test strategy, the thirty cases, your negative and boundary reasoning, the prioritisation, and the coverage gap note.

Execute all thirty cases against your org, recording the actual result for each as pass or fail.

Resist adjusting a case when it fails, because a test bent to pass has no value.

Log every failure as a defect with the detail a developer needs: a title stating the problem, the exact steps to reproduce, what you expected, what happened, the user and profile involved, severity, and a screenshot.

A defect nobody can reproduce gets closed without a fix, so the steps must work for someone else.

Assign severity honestly, separating defects blocking core work from cosmetic issues, and justify each rating.

Then reproduce each one a second time to confirm it is real and not a one-off, and note any you could not reproduce.

Now fix them.

Work through your own defects, correct the configuration, and record what you changed for each.

Retest properly.

Re-execute the failed case to confirm the fix, then re-execute the related passing cases to confirm nothing else broke, which is where fixes most often cause new problems.

Record both results.

Then look for the pattern.

Review your defects and identify what kind of mistake you made most, writing what you would do differently when building next time.

Finally, produce a test summary report stating cases executed, passed, failed, defects by severity, what remains unfixed, and whether you would release.

Submit the executed test plan with results, the defect log, reproduction notes, the fixes, retest evidence including regression checks, the pattern analysis, and the summary report.

Access defects are the most serious kind on a CRM, because they expose data rather than merely inconveniencing someone.

Build the access matrix.

For every profile and object, record the intended create, read, edit, and delete permission, plus intended field-level and record-level access.

This matrix is your expected result.

Create one user per profile with an email address you control.

Now test from each seat.

Using Login As, enter the system as every user and work through the matrix.

For each cell, attempt the action and record what actually happened.

Test both directions: that permitted actions succeed and that forbidden actions are genuinely blocked, since only testing the allowed path is how access defects reach production.

Test record-level access specifically.

Confirm a user cannot see records owned by someone they should not see, then confirm the manager above them can.

Attempt access by direct record URL rather than through a list view, because object permissions and record visibility are separate layers and a URL bypasses navigation.

Test field-level security the same way, including whether a hidden field appears in reports or list views, which is a common leak.

Log every discrepancy as a security defect with its severity, fix the configuration, and retest.

Finally, write the finding that most concerned you and how it would have been exploited.

Submit the access matrix, the per-user test results, the URL and report leak tests, the defect log with fixes and retests, and the significant finding.

Every change risks breaking something unrelated, and a regression suite is how a team ships without fear.

Select the regression set.

From your test cases, choose the fifteen that must pass after any change, covering core record creation, critical automation, key validation, and essential permissions.

Justify each inclusion, since a suite containing everything never gets run.

Make it repeatable.

Rewrite each case so someone unfamiliar with your org can execute it, including the exact data to use and how to reset afterwards.

Ambiguity makes a suite unusable by anyone but its author.

Establish the baseline.

Run all fifteen and record the result, confirming a clean starting point.

Now introduce a real change.

Add a feature to your org, such as a new required field, an extra automation, or a tightened validation rule.

Run the regression suite again.

Record every case whose result changed, and determine for each whether the change is an intended consequence or an unintended break.

This distinction is the core of regression testing.

Fix the unintended breaks and rerun until clean.

Then plan the release verification.

Write the checks you would run immediately after deploying this change, and the rollback steps if verification fails.

Finally, write a note on the case your suite does not cover that you now wish it did, based on what the change revealed.

Submit the regression suite with inclusion reasoning, the baseline run, the change description, the post-change run with impact classification, fixes and clean rerun, the release verification plan, and the coverage note.