TEST-162 Update Smarter Testing onboarding docs (#10164)

This change addresses feedback from onboarding sessions.

- Add verification step after pushing to CI in getting started.
- Clarify that `discover` and `run` are still required for TIA.
- Fix the locally generated impact data file name.
- Clarify how to validate TIA locally.
- Add verification step after pushing to CI in TIA.
- Move "Next Steps" above setup examples to better show those examples
are optional and TIA is now setup.

Author: liamclarkedev

docs/guides/modules/test/pages/getting-started-with-smarter-testing.adoc

@@ -422,6 +422,14 @@ jobs:
 
 Commit both `.circleci/test-suites.yml` and `.circleci/config.yml` to your feature branch and push to your VCS.
 
+=== Verify in CI
+
+After your pipeline runs, verify the test job is behaving as expected before merging.
+
+. In the CircleCI web app, navigate to your pipeline and open the test job.
+. Check the *Tests* tab and confirm the number of test results matches what you see when running tests without the `testsuite` command. A difference in test results could be a misconfiguration in your `discover` command.
+. Compare the job duration to a recent run without the `testsuite` command. The runtime should be similar - a significant difference may indicate a misconfiguration in your `test-suites.yml`.
+
 == Next steps
 
 At this stage, all of your tests should successfully run locally and in CI using the `testsuite` command.

docs/guides/modules/test/pages/set-up-test-impact-analysis.adoc

@@ -64,7 +64,7 @@ Before enabling test impact analysis, ensure you have completed the xref:getting
 
 == 1. Enable test impact analysis option in your `.circleci/test-suites.yml` file
 
-Update the testsuite from the getting started to include an `analysis` command and `test-impact-analysis` option.
+Update the testsuite from the getting started to include an `analysis` command and `test-impact-analysis` option, keep the `discover` and `run` commands in the config.
 
 Some starter configs are shown below. Choose the one for your test runner and copy/paste the `analysis: ...` line into `.circleci/test-suites.yml`.
 
@@ -220,7 +220,7 @@ Remove the `--doctor` flag and add the following flags: `--local --select-tests=
 $ circleci run testsuite "ci tests" --verbose --local --select-tests=none --analyze-tests=impacted
 ----
 
-Then inspect the locally stored impact data in `.circleci/impact-ci\ tests.json` to see the mapping between tests and files. This is a JSON file with a form like:
+Then inspect the locally stored impact data in `.circleci/ci tests-impact.json` to see the mapping between tests and files. This is a JSON file with a form like:
 [source,json]
 ----
 {
@@ -230,6 +230,10 @@ Then inspect the locally stored impact data in `.circleci/impact-ci\ tests.json`
       "path": ".circleci/test-suites.yml",
       "hash": "c9684be83632a628"
     },
+    "2": {
+      "path": "src/foo.ts",
+      "hash": "c9684be83632a628"
+    },
     ...
   },
   "edges": {
@@ -238,13 +242,33 @@ Then inspect the locally stored impact data in `.circleci/impact-ci\ tests.json`
 }
 ----
 
-Try modifying a source file whose ID appears in the list for a test atom and then run test selection to verify only impacted test atoms are selected.
+* `files` are a map of IDs to files with the `path` relative to the working directory and a `hash` of the contents.
+* `edges` are a map of test atoms with an array of file IDs that impact this test atom.
+
+Try modifying a source file whose ID appears in the `edges`, then run test selection to verify only impacted test atoms are selected.
 
 [source,console]
 ----
 $ circleci run testsuite "ci tests" --verbose --local --select-tests=impacted
 ----
 
+Look for the "Selecting tests..." section in output to see why a test was selected.
+
+[source,console]
+----
+==> Selecting tests...
+--> Selecting 'test-atom-one' due to modified file: 'src/foo.ts'
+==> - 0 new test atoms
+==> - 0 test atoms impacted by new files
+==> - 1 test atoms impacted by modified files
+==> - 0 test atoms impacted by removed files
+==> - 0 test atoms failed previously
+==> - 0 test atoms with no source file mappings in impact data
+==> - 0 test atoms impacted by include rule
+==> - 0 test atoms impacted by full test run paths
+==> Selected 1 test atoms, Skipped 123 test atoms in 168ms
+----
+
 === Local flags
 
 [#local-cli-flags]
@@ -352,12 +376,27 @@ jobs:
           path: test-reports
 ----
 
-Commit both `.circleci/test-suites.yml` and `.circleci/config.yml` to your feature branch and push to your VCS. Follow your usual process to merge to your default branch.
+Commit the restored `.circleci/config.yml` to your feature branch and push to your VCS. Follow your usual process to merge to your default branch.
+
+NOTE: The local impact JSON files generated from running the local CLI should not be checked in to VCS.
+
+=== Verify in CI
+
+After analysis completes on your feature branch, verify test impact analysis is working correctly.
+
+. In the CircleCI web app, navigate to your pipeline and open the test job.
+. Check the job was successful and analyzed all tests. A successful analysis run will output "Found n files impacting tests" for each test atom.
+. Modify a source file that appears in the impact data, then push. Only the tests that cover the modified file should be selected to run. Look for the "Selecting tests..." output in the job to confirm the correct tests were selected and the reason for selection.
 
 *Test impact analysis is now set up for your test suite*. Feature branches will run the tests impacted by code changes, and your default branch will first run all tests and then analyze the tests impacted by code changes.
 
 There are xref:#set-up-examples[other options] available if these defaults don't suit your project.
 
+== Next steps
+
+* xref:use-dynamic-test-splitting.adoc[Use Dynamic Test Splitting] to evenly split tests across parallel nodes.
+* xref:auto-rerun-failed-tests.adoc[Auto Rerun Failed Tests] to automatically retry flaky tests.
+
 [#set-up-examples]
 == Common setup examples
 
@@ -487,7 +526,3 @@ jobs:
           path: test-reports
 ----
 
-== Next steps
-
-* xref:use-dynamic-test-splitting.adoc[Use Dynamic Test Splitting] to evenly split tests across parallel nodes.
-* xref:auto-rerun-failed-tests.adoc[Auto Rerun Failed Tests] to automatically retry flaky tests.