The page is straightforward. Knowing which subset to run, how to read the results, and when to fall back to Developer Console or CLI is the operational knowledge.
- Open Apex Test Execution
Setup, Custom Code, Apex Test Execution. Click Select Tests to choose what to run.
- Select the right scope
For a quick validation, pick the specific test class for the code that changed. For pre-production validation, select all classes. Avoid running the whole suite for every small change; it wastes async capacity.
- Submit and watch progress
Click Run. The page polls and updates the pass/fail counts per class. Walking away is fine; the run continues asynchronously.
- Drill into failures
Click any failed class to see the failed method, the assertion message, and the stack trace. Cross-reference with Apex Jobs if the failure looks async-related.
- Check code coverage
After the run, open the Code Coverage page to confirm the org meets the 75 percent threshold before any production deploy.
- Test history retention is weeks, not forever. Long-term trend analysis requires exporting ApexTestResult rows.
- The 75 percent coverage rule applies at deploy time. Tests that exist but cover the wrong code do not help; coverage is per-class.
- Tests run async. Submitting a run does not block; come back later or watch the page.
- Parallel testing defaults to on. Tests that share data (a singleton account record, an in-memory counter) can fail intermittently. The fix is data isolation, not disabling parallel testing.